The Poker Payout Curve

Fixed prize ranks require you to know your field size. "1st takes 50%, 2nd 30%, 3rd 20%" is a good split over twelve entrants and an absurd one over five hundred, where it pays 0.6% of the room and gives everyone below third no reason to place another trade.

Percentage-of-field buckets solve that by naming slices instead of ranks: the top 10% share 60% of the pool, the rest of the top half share 40%. The winner count resolves against whatever field turns up, and inside each slice payouts decay down the ranks on a poker-tournament curve rather than splitting flat. This post is the arithmetic, exactly.

Step 1: how many people get paid

Buckets are stored as {topPercent, percentage} pairs and processed in ascending topPercent. Each bucket resolves to a cumulative winner count over the final eligible field size N:

## cum = the last rank this bucket pays
cum = min(N, max(1, floor(N * topPercent / 100), prevCum))

The bucket then covers ranks prevCum + 1 through cum.

Three guards are doing work in that one line. floor — you cannot pay a fraction of a person. max(1, …) — a top 10% bucket over a 4-person field floors to zero, and a competition that crowns nobody is broken, so the leader always gets paid. max(…, prevCum) and min(N, …) — counts never go backwards and never exceed the field.

Worked, for [{10%, 60}, {50%, 40}] — the top-heavy preset:

N is the final eligible field, not the number of people who registered. Settlement counts entries that paid, were not refunded or rejected, actually started scoring, and cleared the minimum-volume floor. A challenge where half the room never went flat resolves against the half that did.

One edge case has an explicit rule. If a later bucket resolves to the same cumulative count as the one before it — which happens in small fields, where top 10% and top 25% both floor to the same number — that bucket has no members of its own. Its share does not go unpaid: it folds into the winners above it, proportionally to what they already hold. In a field that small those are the only people the bucket could have named, and the pool must still sum to what the page advertised.

Step 2: the curve inside a bucket

Within a bucket, the share is not split equally. Position p — the global rank, not the position within the bucket — carries weight:

## alpha = 0.8
weight(p) = p ^ -0.8

Those weights are normalized across the bucket's positions and scaled to the bucket's stated share:

payout(p) = bucketShare * weight(p) / sum(weight(q) for q in bucket)

Using the global rank is deliberate. If each bucket restarted its decay at 1, the first seat of a wide lower bucket would get a top-of-curve payout, and the curve would sawtooth at every boundary.

Why 0.8. It is the poker-standard shape, chosen for two properties multi-table-tournament payout tables are tuned for at once:

• Top-heavy at the head. 1st pays 2^0.8 = 1.7411 times 2nd — call it 1.74×. Over the top ten, 1st pays 10^0.8 = 6.31 times 10th.
• A long paying tail. The decay is sub-linear, so the last paid seat still receives a visible cheque rather than dust. Across a hundred ranks the raw weight ratio is 100^0.8 = 39.8 — steep, but nothing like a flat-then-nothing structure.

Chase the top; min-cashing still feels like winning. A flat split inside a bucket fails the first property — 8th gets the same cheque as 1st, so there is no reason to keep fighting once you are safely inside. Paying only the head fails the second.

Step 3: the flattening pass

Per-bucket normalization alone can produce an ugly artefact: the first seat of a big later bucket out-paying the last seat of the bucket above it.

The real example, [{10%, 60}, {50%, 40}] at N = 500, before smoothing:

Rank 51 out-pays rank 50, and ranks 48–50 too. That is indefensible: a lower rank must never pay more than a higher one.

So a final isotonic pass — pool-adjacent-violators — runs over the resolved list. Any run where a later rank pays more than an earlier one is merged and averaged into an equal-payout flat band:

Monotonic again. Averaging within merged blocks preserves the total to float precision, so the pool still sums to 100%. Flat bands deep in the tail are authentic tournament structure — real MTT tables pay bands, not unique amounts, once you are far from the final table.

One consequence creators need to know: where the pass flattens a boundary, a bucket's actual cut moves away from its stated share. At N = 500 above, the stated 60/40 resolves to 60.007/39.993 — negligible. But a "spread it wide" config of [{10%, 20}, {50%, 80}] at 1,000 entrants pays its top bucket about 29%, not the 20% written in the config, because the deep, richly-funded second bucket forces a long flat band at the boundary. Any surface showing per-bucket shares next to a live field reads the resolved number, not the stored config — a page must not say 20% while settlement pays 29%.

What the curve looks like in practice

[{10%, 60}, {50%, 40}] on a $1,000 pool:

Read the columns as one config meeting three turnouts. At 20 entrants it is a concentrated contest with ten cheques; at 500 it pays half the room, with a top prize still 79 times the last one.

Very small fields behave differently again. At N = 12, top 10% floors to a single seat, so rank 1 takes the whole 60% and ranks 2–6 divide the other 40%: the leader gets $600 of a $1,000 pool. Small fields are automatically winner-heavy, which is right — with twelve entrants, paying six is already generous.

Why a curve beats fixed ranks

Fixed ranks are the right choice when you know the field: a 1v1 duel, a private room of twenty, a challenge with a hard seat cap you expect to fill.

Buckets are the right default whenever you do not, which is most of the time:

• One config covers every turnout. Twelve people or five hundred, the split stays sensible. No mid-flight edits, no promise you have to revise.
• The cash rate is stated, not implied. "Top half gets paid" is a claim an entrant can evaluate before paying a ticket. "50/30/20" tells them nothing until they know how many showed up.
• It fails gracefully in both directions. A fixed 5-rank split over 400 entrants pays 1.25% of the room; over 3 entrants it strands a tier. Buckets do neither.

Two rules to keep in mind when configuring them. Bucket shares must total exactly 100%, and the validator enforces it: buckets resolve their winner count from the final field, so a shortfall has no position to attach to and strands that slice of the pool. Fixed ranks do not redistribute either — an unfilled rank simply goes unpaid — but that shortfall is at least predictable in advance. And percentage-of-field buckets are a challenge feature: other competition types use fixed positional tiers.

One last practical detail: at settlement, any resolved share below half a cent is dropped rather than written as a 0.00 row. On a large field with a small pool, the deep tail can round to nothing — which is a real argument for not spreading a $50 pool across half of a 300-person room.

The short version

Winner count is min(N, max(1, floor(N × topPercent / 100), prevCum)) per bucket, cumulative. Inside a bucket, rank p gets weight p^-0.8 on its global rank, normalized to the bucket's share — 1st pays 1.74× 2nd, 6.31× 10th. An isotonic pass then flattens any boundary where a lower rank would out-pay a higher one, preserving the total. The result is a top-heavy curve with a long paying tail that works at any field size.

More on how the live page projects it in how projected rewards are calculated, or create a challenge and try the presets against a field size you expect.