Host Tiers
Monthly ranking system -payout multipliers, visibility boosts, evaluation rules.
Last updated Thu Jul 16 2026 00:00:00 GMT+0000 (Coordinated Universal Time)
TL;DR -A proposed monthly rank (Rising → Bronze → Silver → Gold → Star → Legend) earned from real gift earnings. The higher your rank, the bigger a slice of each gift you keep (25% up to 35%) and the more the app shows off your room.
Who this is for -Business & Product: the tier table and visibility rules. Design: badges and discovery placement. Engineering: the multiplier math, evaluation cron, and anti-abuse.
Status: PROPOSED DESIGN -see the Creator Program overview for the shared principles and margin math.
In plain terms
Tiers are the progression spine of the program -the "level up" system for hosts. Once a month the platform looks at how much real money viewers spent on each host's gifts, sorts hosts into six ranks, and gives higher ranks two rewards: a bigger cut of every future gift, and more prominence in the app's discovery feed.
Two fairness rules matter most. You can only be sold down one rank per month, no matter how far your earnings dropped -so a single slow month (a vacation, an illness) never erases a year of climbing. And there is no way to buy a tier; the only path up is real earnings from real viewers.
Industry analogues: Bigo host ranks, Poppo's host levels, Tango's "Rocket Host" style tiers. This monthly rank is computed from real paid-gift earnings and scales the host's payout multiplier and feed visibility.
The tier table
The threshold column is measured in settled diamonds earned during the month -meaning the diamonds a host actually banked from paid-coin gifts, before any tier bonus is applied. The "≈ gross gifted" column translates that back into roughly how many dollars viewers spent, just to build intuition.
Thresholds are settled diamonds earned in the evaluation month (paid-coin gifts only, before any multiplier -so the threshold measures what viewers actually spent, ≈ gross × 25%).
| Tier | Monthly diamonds | ≈ gross gifted | Multiplier | Effective payout | Visibility |
|---|---|---|---|---|---|
| Rising (default) | 0 | - | ×1.00 | 25.0% | baseline |
| Bronze | 10,000 | $400 | ×1.05 | 26.25% | baseline |
| Silver | 40,000 | $1,600 | ×1.10 | 27.5% | + discovery boost |
| Gold | 120,000 | $4,800 | ×1.15 | 28.75% | + discovery boost, tier badge |
| Star | 400,000 | $16,000 | ×1.25 | 31.25% | + featured row eligibility |
| Legend | 1,200,000 | $48,000 | ×1.40 | 35.0% | + featured row, launch spotlight |
- "≈ gross gifted" = diamonds ÷ 25% payout ÷ $0.005. Shown for intuition; the system only ever compares diamond micros.
- Multipliers are expressed internally as basis points
(
multiplierBps: 10500etc.) increatorProgramConfig.
How the multiplier applies
Here's the technical layer. The multiplier isn't applied in a monthly lump-sum sweep -it's applied the instant a gift is received, using whatever tier the host holds at that moment.
The multiplier scales the diamond credit at gift time, not a retroactive monthly adjustment:
credited micros = paidCoins × diamondMicrosPerPaidCoin × multiplierBps / 10000
- Applied inside the existing gift
$transaction, using the host's current tier row -one extra indexed read. - The
DIAMOND_EARNINGledger row's metadata gainstierAtCreditandmultiplierBps(rate-snapshot pattern), so historical rows are self-explanatory forever. - BigInt micros math stays exact: multiplier basis points divide after the micros multiplication, floored. Rounding always favors the platform (floor), consistent with the rest of the economy.
- Pending-diamond and settlement mechanics are unchanged -a multiplied credit is still a normal pending diamond with a 72h hold.
Evaluation cycle
A single scheduled job re-ranks every host at the start of each month. The diagram traces what that job does: sum last month's earnings, compute the raw tier, apply the one-step demotion grace, save the new tier, and notify the host.
Rendering diagram…
- Calendar-month window, UTC.
monthKeyformat2026-07. - One-step demotion grace: a host can only drop one tier per month regardless of how far their earnings fell. Prevents a vacation from erasing a year of progression (industry platforms do the same to reduce burnout churn).
- Promotion is instant at evaluation, never mid-month. Mid-month upgrades create last-day gift-recycling incentives; a fixed monthly cadence keeps the target legible.
- New hosts start at Rising. There is no paid path to a tier.
Visibility mechanics
Beyond pay, a higher tier makes the app promote your room more. It's a nudge, not a guarantee -the ranker weighs tier as one bounded input among many, so a famous host with an empty room never buries a genuinely hot newcomer.
Tier feeds the discovery ranker as a bounded feature, not a raw sort key:
- Silver+ receives a discovery-score bonus term (capped so a Legend host with zero live viewers never outranks an organically hot Rising room).
- Star/Legend become eligible for the curated featured row in the mobile home feed; curation stays editorial/algorithmic, eligibility is the tier gate.
- Tier badge renders next to the host name in room headers, profiles, and
leaderboards (client reads it from the existing profile payload —
one new field,
hostTier).
Anti-abuse
Because a higher tier means real money, people will try to game it. The defenses lean on the economy's built-in loss: pumping a tier means buying coins at full price and gifting them at a steep loss, so cheating is expensive by construction.
- Paid coins only. Bonus-coin gift value contributes zero tier progress (program principle #6).
- Refund clawback demotes. When an IAP refund claws back diamonds (see Refunds), the clawed-back micros are subtracted from the month's tier progress; if a completed month's rank was refund-inflated past a threshold, the next evaluation corrects it (no retroactive multiplier reversal -the snapshot rule -but the fraud team gets an alert when clawbacks exceed 10% of a host's monthly progress).
- Collusion pairs (two accounts cycling purchases → gifts to pump each other's tiers) are bounded by the one-way lossy conversion: pumping a tier costs real money at ≥65% loss per cycle. Detection: flag host pairs where >50% of monthly diamonds come from a single funding card cluster.
Constants (proposed creatorProgramConfig excerpt)
These are the exact numbers the design would ship with -the tier thresholds and multipliers, expressed in basis points, all in one config file.
hostTiers: [
{ tier: 'RISING', minMonthlyDiamonds: 0, multiplierBps: 10000 },
{ tier: 'BRONZE', minMonthlyDiamonds: 10_000, multiplierBps: 10500 },
{ tier: 'SILVER', minMonthlyDiamonds: 40_000, multiplierBps: 11000 },
{ tier: 'GOLD', minMonthlyDiamonds: 120_000, multiplierBps: 11500 },
{ tier: 'STAR', minMonthlyDiamonds: 400_000, multiplierBps: 12500 },
{ tier: 'LEGEND', minMonthlyDiamonds: 1_200_000, multiplierBps: 14000 },
],
tierDemotionMaxStepsPerMonth: 1,
Related pages
- Creator Program overview -shared principles and the margin ceiling.
- Quotas & Bonuses -the schedule layer that stacks on top of tiers.
- Agencies -how tier progress interacts with an agency split.
- Refunds -the clawback mechanism that demotes refund-inflated ranks.
- Data Model & Rollout -the
HostTierStateschema and the monthly job.