[marek-chmielowski-blurify]

Summary

• The daily streak can be switched on and off; disabling ends every run and re-enabling starts everyone from zero.
• Milestone days run 1-35 with no reset; past the last day the count keeps growing.
• Each milestone can unlock a streak rakeback rate: a rate on theoretical GGR for a player with no rank, or a multiplicative uplift on rank instant rakeback.
• Fixed milestone rewards unlock once per player, keep the terms captured at unlock, and are claimed as a bonus with rollover in the player's active currency.
• Unclaimed rewards expire after a per-milestone claim window, settled by a new hourly promo-streak-expire job with one audit row each.

Why

The streak paid a mix of cash, random gift drops, a time-limited additive rakeback boost and bonuses, reset at a fixed day, and re-paid milestones on every new run. Operators need a simpler, cost-controlled model: a persistent rakeback rate while the streak holds, one-time fixed rewards, and a claim window, all configurable without a deploy.

Diagram

sequenceDiagram
  participant W as Wallet bet
  participant R as RakebackService
  participant S as StreakService
  participant P as StreakPayoutService
  W->>R: settled real-money stake
  R->>R: active rate = highest milestone <= current (streak live, enabled)
  R-->>R: ranked: base x rate x (1 + uplift) / no rank: GGR x rate
  W->>S: recordWager (after rakeback)
  S->>S: day reaches target -> current + 1
  S->>S: day in fixedRewards -> grant row (amount, rollover, expiry captured)
  Note over P: player claims before expires_at -> bonus in active currency
  Note over P: hourly promo-streak-expire -> unclaimed rows settle as expired

Loading

Alternatives considered

• Keep the additive boost and add a multiplier beside it: two rakeback adjustments would interact and double-pay; replaced instead.
• Drop the retired columns in this release: a rolling deploy would break old pods writing bets, so the migration is expand-only.

Risks

• Breaking contract change (StreakConfigSchema, PlayerStreakSchema, accrual admin row); consumers must adapt before bumping.
• The conversion migration switches any existing streak config off, maps bonus rewards to fixed rewards, and settles waiting grants with no matching reward as expired without audit rows (SQL migrations cannot write them). Check for waiting grants before deploying.
• Retired columns (promo_streak_config.milestones, reset_after_day, promo_player_rank.rakeback_boost_*) stay unread; a follow-up release drops them.