Social LiveDocumentationPLATFORM DOCS

PK Battle Economy

Scoring, winner bonuses, the seasonal ladder, and collusion controls for PK battles.

Last updated Thu Jul 16 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

TL;DR -A proposed money layer on top of the PK battles that already exist: two hosts race their audiences to out-gift each other, gifts stay completely normal, and the winner gets a small platform-funded bonus plus points on a seasonal ladder. Nobody's gift ever gets redirected to the other host.

Who this is for -Business & Product: scoring, the winner bonus, and the ladder. Design: leagues, badges, and matchmaking. Engineering: the scoring rules, bonus formula, and anti-collusion controls.

Status: PROPOSED DESIGN -see the Creator Program overview for the shared principles and margin math. PK battle mechanics (state machine, broadcast) already exist -see Live Rooms. This page designs the money layer on top.

In plain terms

A PK battle is the highest-energy format in live streaming: two hosts go head-to-head with a countdown clock while their audiences race to send more gifts than the other side. The battle mechanics -matchmaking, the timer, the live scoreboard -already ship today. What's missing is a reward for winning.

This page adds that reward. The single most important rule: during a battle, gifts behave exactly like normal gifts. A gift you send your favorite host goes to your host, in full, forever -the battle never redistributes it to the opponent. The winner's prize is a separate bonus the platform pays out of its own pocket, layered on top. That keeps the ledger honest and stops losing-side gifters from feeling robbed.

Two hosts, a countdown, and both audiences racing to out-gift each other. PkBattle rows and status broadcasting are already shipped; what's missing is a reason to win.

What happens to gifts during a battle -nothing special

This is the core design decision, stated once more in technical terms: the battle layer only reads gifts, it never moves them.

The single most important design decision: gifts sent during a PK battle are completely normal gifts. Full standard credit to the recipient (tier multiplier, agency split, 72h hold -everything as in Gifting). The battle layer only reads them.

Industry platforms sometimes redistribute the round's gift pool (winner takes up to 70% of the combined pool). We deliberately don't: pool redistribution means a viewer's gift to host A can end up paying host B, which breaks ledger legibility, creates clawback nightmares on refunds, and enrages losing-side gifters. Instead the winner's upside is a platform-funded bonus on top.

Scoring

Score is just the paid coins each side received during the battle window. Bonus-coin gifts still light up the screen, but they don't count -same paid-coin-only rule as the rest of the program.

  • Score = paid coins gifted to each side inside the battle window (bonus-coin spend animates and counts for the room hype meter, but adds 0 score -program principle #6).
  • Attribution: recipient host or their stage guests during the battle count for that host's side.
  • Recorded per-battle in a new PkBattleResult row (both scores, gross paid coins, winner, timestamps) written when the battle ends — score-relevant ledger rows already carry roomId, so the result is recomputable from the ledger for audit.

Winner bonus

The winner earns a bonus worth 5% of the combined paid-coin gross of the battle, paid as pending diamonds. It's floored to kill tiny farm battles and capped per day to bound the platform's liability.

bonus diamonds = 5% × (combined battle paid-coin gross) × diamondMicrosPerPaidCoin
  • Paid to the winner as pending diamonds (PK_BONUS ledger row, standard 72h hold). Tie → split 50/50.
  • Qualification floor: combined battle gross ≥ 1,000 paid coins ($10). Below the floor: no bonus, ladder points still accrue. Kills micro-battle bonus farming.
  • Daily bonus cap per host: 20,000 bonus diamonds/day ($100) — bounded liability while the format tunes.
  • The 5% is on combined gross, so even in the extreme where all platform gifting happens inside battles, the program adds at most 5 points of payout -already counted in the worst-case margin math.

The seasonal ladder

Bonuses reward a single win; the ladder rewards a season of them. Hosts earn points per battle, get bucketed into leagues, and the top of each league wins visibility and (for the very top) a fixed prize pool.

Bonuses pay the winner; the ladder makes winning compound:

  • Seasons: 4 weeks, aligned to tier months.
  • Points: win = 3, tie = 1, loss = 1 (showing up matters), ×2 when the opponent's ladder rank is higher (upset multiplier). Points also require the 1,000-coin combined floor.
  • Leagues: hosts are bucketed weekly (Bronze/Silver/Gold/Star league by points percentile). League determines matchmaking suggestions and a ladder badge.
  • Season rewards: top of each league gets visibility rewards (featured-row slots, profile trophies) and a modest diamond prize pool for the top league only -prize pool is a fixed seasonal constant (e.g. 500,000 diamonds = $2,500 split across the top 20), so it is a marketing budget line, not an open-ended liability.
  • Ladder standings are public in-app; industry experience is that the ladder page itself drives battle volume more than the money does.

Matchmaking

Hosts either take a random ladder-adjacent opponent ("battle roulette") or challenge someone directly. Repeated challenges to the same opponent are allowed but pay less each time (see decay below).

  • Hosts opt in to "battle roulette" (random ladder-adjacent opponent) or send direct challenges -direct challenges to the same opponent are always allowed but decay in reward (below).
  • Only live hosts can battle (existing rule); league proximity guides roulette pairing so a Rising host isn't fed to a Legend's audience.

Anti-collusion

Two friendly hosts could trade wins to farm the bonus. It's already a losing proposition (someone has to buy the coins at full price), but these controls make it pointless rather than just expensive -the payout decays to zero after a few daily rematches, and the 72h hold means refunded funding gets clawed back.

Two friendly hosts alternating wins can farm the 5% bonus. The cycle is already negative-sum (someone must buy the coins at full price to generate gross), but the controls make farming pointless rather than merely expensive:

  • Same-pair decay: the winner bonus for a given host pair pays 100% / 50% / 25% / 0% for the 1st/2nd/3rd/4th+ battle between them per UTC day. Ladder points hit 0 after the 3rd daily pairing too.
  • Same-agency battles earn 0 ladder points and 0 rebate contribution (see Agencies); the winner bonus still pays (real audience spend is real) but flags for review above $50/day per pair.
  • Bonus is hold-gated: because PK_BONUS diamonds ride the standard 72h pending hold, a battle funded by a purchase that later refunds is clawed back by the existing refund machinery before it's withdrawable.
  • Self-battles are structurally impossible (one live room per host, and self-gifting is blocked everywhere).

Constants (proposed creatorProgramConfig excerpt)

The exact tunable numbers -bonus rate, qualifying floor, daily cap, the per-pair decay schedule, and season settings -in one config block.

pk: {
  winnerBonusBps: 500,              // 5% of combined battle paid gross
  qualifyingGrossCoins: 1_000,      // $10 combined floor
  dailyBonusCapDiamonds: 20_000,    // $100/day/host
  samePairDailyPayoutSchedule: [10000, 5000, 2500, 0], // bps of full bonus
  season: { weeks: 4, topLeaguePrizeDiamonds: 500_000, prizeWinners: 20 },
},