DEV Community: Betkyo Research

Dice, priced exactly: the true win chance and return behind every target

Betkyo Research — Mon, 28 Sep 2026 03:42:46 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

A dice screen shows two numbers, a win chance and a multiplier, and multiplying them gives 99% — at some targets. The roll has 9,999 possible results, not 10,000, and the multiplier is cut to two decimals, so the real return moves between 98.03% and 99.00% depending on where the target sits. Here is the exact price of every setting, and the one habit that avoids nearly all of the difference.

Quick answer: Each roll is one of 9,999 equally likely results, 0.01 to 99.99. Roll under 50 wins on 4,999 of them, so the true chance is 49.995%, not 50%, and a result of exactly 50.00 loses both Under and Over. The multiplier is 0.99 ÷ the shown chance floored to two decimals. Where that division lands exactly, as at 50 (×1.98), 25 (×3.96) or 10 (×9.90), the true return is 98.91–99.00%; where it does not, the floor adds cost — target 80 pays ×1.23 and returns 98.40%, and 97.06 pays ×1.01 and returns 98.03%, the worst setting on the slider. Across all 9,601 slider positions from 2.00 to 98.00 the average return is 98.72%. Typing the multiplier instead of dragging the slider picks the target that prices cleanly: ×2 returns 98.99%, ×10 98.91%, ×49.5 98.51%.

One roll, 9,999 results

Dice is the simplest game on the site: choose a target, choose Under or Over, and the roll either lands on your side of it or does not. The screen quotes a win chance and a multiplier for every target, and the two look like they multiply to exactly 99% — the stake back, less a 1% house edge. The engine is a little more particular than the screen, in two ways that both cost the player, and this article prices them exactly.

Verified in the engine: OriginalBaseDiceService.kt: getResult() draws nextIntBelow(9999) + 1 and divides by 100, so the result is one of the 9,999 values 0.01 to 99.99 — 0.00 excluded, 99.99 included. getWinChance() is target ÷ 100 for Under and (100 − target) ÷ 100 for Over. checkAndGetMultiplier() is (1 − house edge) ÷ win chance, floored to two decimals. getEarned() compares strictly: Under wins when the result is below the target, Over when it is above. The random number is the first 13 hex digits of HMAC-SHA256 over “clientSeed-nonce-0”, keyed by the server seed, divided by 2⁵²; the client mirror is payoutMultiplier() in dice/diceApi.ts, and diceGame.tsx limits the slider to targets 2.00–98.00.

The house service carries its own test of this arithmetic, DiceHouseEdgeTest, which checks that no target ever returns more than 99% and that the floor never takes more than one rounding step. Both hold. What the test does not print is how much each target actually returns, and that is the table a player needs.

The shown chance and the true chance

The win chance on screen is computed as if the roll were a continuous number from 0 to 100. It is not: it is one of 9,999 steps. Roll under a target T wins on the results 0.01 up to T − 0.01, which is 100 × T − 1 of them, so the true chance is (100T − 1) ÷ 9,999. At most targets the difference is invisible; at the smallest ones it is not.

Roll under a target: winning results, shown chance and true chance

TARGET (UNDER)	WINNING RESULTS OF 9,999	SHOWN CHANCE	TRUE CHANCE
2.00	199	2.00%	1.9902%
5.00	499	5.00%	4.9905%
10.00	999	10.00%	9.9910%
25.00	2,499	25.00%	24.9925%
50.00	4,999	50.00%	49.9950%
75.00	7,499	75.00%	74.9975%
90.00	8,999	90.00%	89.9990%
98.00	9,799	98.00%	97.9998%

True chance = (100 × target − 1) ÷ 9,999. Roll over a target T wins on 9,999 − 100T results, so Over T is priced exactly like Under (100 − T): Over 50 also wins on 4,999 results.

The gap is always one result. At a 50% target it costs 0.005 percentage points of chance, a hundredth of a percent of return; at the 2% target, the tightest the slider allows, one result out of 200 is about half a percent of the win chance, and the return drops from 99.00% to 98.51% for that reason alone. The same fact explains a small curiosity: a roll of exactly 50.00 loses Under 50 and Over 50 alike, because neither comparison includes the target. It happens once in 9,999 rolls.

The two-decimal floor

The second cost is the multiplier. The engine divides 0.99 by the win chance and keeps two decimals, always rounding down. When the division comes out exact — 0.99 ÷ 0.50 = 1.98, 0.99 ÷ 0.25 = 3.96 — nothing is lost. When it does not, the player is paid the truncated figure: 0.99 ÷ 0.80 = 1.2375, paid as ×1.23. At a high win chance the multiplier is close to 1, the hundredth that gets dropped is a large share of the profit, and the return falls much further than at the low end.

What a roll-under target pays and returns, 1% house edge

TARGET (UNDER)	PAYS	SHOWN CHANCE × PAYS	TRUE RETURN
2.00	×49.50	99.00%	98.51%
5.00	×19.80	99.00%	98.81%
7.00	×14.14	98.98%	98.85%
10.00	×9.90	99.00%	98.91%
13.00	×7.61	98.93%	98.86%
25.00	×3.96	99.00%	98.97%
40.00	×2.47	98.80%	98.79%
50.00	×1.98	99.00%	98.99%
70.00	×1.41	98.70%	98.70%
80.00	×1.23	98.40%	98.40%
90.00	×1.10	99.00%	99.00%
95.00	×1.04	98.80%	98.80%
97.06	×1.01	98.03%	98.03%
98.00	×1.01	98.98%	98.98%

True return = multiplier × (100 × target − 1) ÷ 9,999. At 90.00 it is 98.999%, the highest on the slider; at 97.06 it is 98.030%, the lowest. Over targets mirror these rows: Over T returns what Under (100 − T) returns.

Read the two right-hand columns together and the two costs separate cleanly. At low targets the multiplier usually divides exactly and the whole shortfall is the missing result; at high targets the missing result is negligible and the shortfall is almost all floor. Target 80 is the clearest case: 0.99 ÷ 0.8 needs ×1.2375, the table pays ×1.23, and the return is 98.40% — a house edge of 1.6%, not 1%. Every target between 97.06 and 98.00 pays the same ×1.01, so the chance you give up by moving to 97.06 buys nothing.

Over the whole slider — every target from 2.00 to 98.00 in steps of 0.01, 9,601 settings — the true return averages 98.72%. Only 585 of those settings, 6.1%, return 98.95% or more; 1,453, 15.1%, return less than 98.50%.

Type the multiplier, not the percentage

The game has a second way to set a bet: type the multiplier you want, and it works out the target. It chooses the target whose floored payout is at least what you typed, so a typed multiplier always lands on a setting where 0.99 ÷ chance divides cleanly. That removes the floor cost entirely; only the one-result gap remains.

Typed multipliers and the targets they resolve to

TYPED	TARGET (UNDER)	TRUE CHANCE	TRUE RETURN
×1.10	90.00	89.9990%	99.00%
×1.20	82.50	82.4982%	99.00%
×1.50	66.00	65.9966%	98.99%
×2	49.50	49.4949%	98.99%
×3	33.00	32.9933%	98.98%
×5	19.80	19.7920%	98.96%
×10	9.90	9.8910%	98.91%
×20	4.95	4.9405%	98.81%
×49.50	2.00	1.9902%	98.51%

targetForMultiplier() in dice/diceApi.ts floors the Under target (or ceils the Over target) so the chance never rises above the one the typed multiplier implies. Returns rounded to two decimals; ×1.10 is 98.999% and ×1.20 98.998%.

The practical rule is short. If you care about the last half-point, set the multiplier rather than the percentage, and prefer round multipliers at the low end of the payout range. A target chosen because it looks round as a percentage — 80, 70, 40 — is often a worse price than the target one tick away. None of this changes the long-run direction: every setting returns less than the stake, and the martingale, priced and risk of ruin explain why no sequence of bets fixes that.

Limbo avoids the floor by construction: the player names the payout directly and the drawn number is compared against that same figure, so there is no second rounding to pay for. Dice quotes a chance and derives the payout from it, and that derivation is where the floor enters.

Checking a roll yourself

Before you play, the fairness panel shows the SHA-256 fingerprint of the server seed. Rotate your seed pair afterwards to reveal the seed and confirm the fingerprint.
Compute HMAC-SHA256 with the server seed as the key and “clientSeed-nonce-0” as the message; a roll uses cursor 0 only.
Read the first 13 hex digits of the digest as an integer and divide by 2⁵² to get u. The result is (floor(u × 9,999) + 1) ÷ 100. Compare it with your target, strictly, and the multiplier on your ticket with 0.99 ÷ chance floored to two decimals.

If the result matches, it was fixed before you chose a target — which, as what a hash commitment proves explains, is what the commitment guarantees and all it guarantees. The price of the target is not in the hash. It is in the two lines of arithmetic above, which is why this article exists.

FAQ

What are the real odds in a dice game that rolls 0 to 100?

Here the roll is one of 9,999 results from 0.01 to 99.99. Roll under T wins on 100 × T − 1 of them, so roll under 50 is 49.995%, roll under 10 is 9.991% and roll under 2 is 1.990%.

What is the house edge on dice?

The stated edge is 1%, but the true return depends on the target: from 99.00% at a target of 90 to 98.03% at 97.06. Averaged over every slider setting from 2.00 to 98.00 it is 98.72%, an effective edge of 1.28%.

Why does my dice multiplier look rounded down?

The engine pays 0.99 ÷ win chance floored to two decimals. At an 80% target that is 1.2375, paid as ×1.23, which returns 98.40% instead of 99%.

What is the best target to pick in dice?

Any target where 0.99 ÷ chance divides exactly, such as 50 (×1.98), 25 (×3.96), 90 (×1.10) or 66 (×1.50). Typing the multiplier instead of the percentage finds one automatically. No target returns more than 99%.

What happens if the dice roll lands exactly on my target?

It loses. Under wins only below the target and Over only above it, so a roll of exactly 50.00 loses both Under 50 and Over 50. It happens once in 9,999 rolls.

Can I verify a dice roll?

Yes. HMAC-SHA256 of “clientSeed-nonce-0” keyed by the revealed server seed; the first 13 hex digits over 2⁵² give u, and (floor(u × 9,999) + 1) ÷ 100 is the result.

Sources

Betkyo engine source, house service: OriginalBaseDiceService.kt — getResult() (nextIntBelow(9999) + 1, over 100), getWinChance() (4-decimal floor), checkAndGetMultiplier() ((1 − house edge) ÷ win chance, 2-decimal floor), getEarned() (strict comparison); SeedPairRandom and PfHashUtils.normalize() (first 13 hex digits ÷ 2⁵²); DiceHouseEdgeTest.kt
Betkyo engine source, client mirror: payoutMultiplier() and targetForMultiplier() in dice/diceApi.ts; the 2.00–98.00 slider bounds in diceGame.tsx
Exact calculation written for this article: (100T − 1) ÷ 9,999 win chances and floored multipliers for all 9,601 slider targets, their true returns and distribution; cross-checked by replaying 400,000 rolls of the HMAC stream through the result derivation (roll under 50: 49.88% simulated vs 49.995% exact; results spanned 0.01 to 99.99)

Roulette hit rates, priced: how long a number takes and what a streak is worth

Betkyo Research — Wed, 23 Sep 2026 02:35:36 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

Every bet on this single-zero wheel costs the same 2.7%, so the interesting questions are the ones the price does not answer: how many spins a number usually takes, how often a colour runs eight deep, how long zero can stay away, and how far a session can drift from its expected loss. Here are the answers, computed from the engine’s 37 pockets.

Quick answer: On this engine’s European roulette every pocket lands 1 in 37 per spin. A straight-up number takes 37 spins on average but only 26 to have a 50% chance of appearing; it is absent from 100 spins 6.5% of the time and from 200 spins 0.4%. Red comes up five times in a row 2.7% of the time and ten times in a row 0.07%; an even-money bet loses eight in a row 0.48%, roughly once every 207 spins. Zero has landed at least once in 37 spins 63.7% of the time — so it is absent from a full wheel’s worth of spins more than a third of the time. Every bet returns 97.30%, but the swing is not the same: over 100 one-unit spins the expected loss is 2.7 units on every bet, while the standard deviation is about 10 units on red, 14 on a dozen and 58 on a straight-up number.

One spin, thirty-seven pockets

Roulette on this site is a single-zero wheel, and the whole of its arithmetic rests on one fact: each spin lands on one of 37 pockets with equal chance. A roulette bet is a string walked through the consequence for price — every bet returns 36 ÷ 37 = 97.30%. This article is about everything the price leaves out: how long things take, how often they cluster, and how much a session can wander.

Verified in the engine: deriveRouletteSpin() in roulette/derive.ts: the pocket is floor(u × 37) from cursor 0 of the round’s HMAC, u = hi ÷ 2³² + lo ÷ 2⁶⁴ (u64()); the server port RouletteEngine.derivePocket() uses U64SeedStream(...).intBelow(37). Settlement pays stake × multiplier per covering key (×36 straight, ×18 split, ×12 street, ×9 corner and first four, ×6 six line, ×3 dozen and column, ×2 even chances); the multipliers are whole numbers, so nothing is lost to rounding. One nonce settles the whole table in one spin.

Two things follow from the derivation. Each spin is a fresh HMAC of a fresh nonce, so spins are independent: the wheel has no memory, and every figure below is a plain power or a binomial count. And the 37 pockets are equally likely to within one part in 2⁶⁴, so the physical wheel-bias stories from Jaggers and Garcia-Pelayo have no counterpart here: there is no worn fret to find.

How long a number takes

A straight-up number wins 1 in 37 per spin, so the average wait between hits is 37 spins. Averages mislead on waiting times, because the distribution is lopsided: most gaps are shorter than 37 and a few are very long. The useful figures are the chances of seeing the number within a given stretch, which is 1 − (36 ÷ 37)ᴺ.

Chance that a chosen number lands at least once, betting it every spin

SPINS	AT LEAST ONE HIT	NO HIT AT ALL
10	23.97%	76.03%
26	50.95%	49.05%
37	63.71%	36.29%
50	74.59%	25.41%
100	93.54%	6.46%
150	98.36%	1.64%
200	99.58%	0.42%
300	99.97%	0.03%

No hit in N spins = (36 ÷ 37)ᴺ. The median wait is 26 spins, the first N at which the chance of a hit passes one half; the mean is 37. In 37 spins the number lands exactly once 37.3% of the time and two or more times 26.4%.

The row that surprises people is the third one: play your number for a full wheel’s worth of spins, 37 of them, and more than a third of the time it never comes. That is not bad luck; it is the ordinary shape of a 1-in-37 event. A hundred spins leaves a 6.5% chance of an empty run, one session in fifteen, and each of those sessions costs 100 units for nothing back.

The same table describes zero, which is just another pocket. Zero lands at least once in 37 spins 63.7% of the time, in 74 spins 86.8%, in 10 spins 24.0%. A table that has not shown zero for fifty spins is not “due” — the next spin is 1 ÷ 37 exactly as it was — and a table that showed it twice in ten is not “hot”. The gambler’s fallacy is the belief that the wheel keeps a ledger; the hash does not.

What a streak is worth

Colour runs are the streaks players remember, and on a single-zero wheel they are less rare than they feel. Red wins 18 ÷ 37 of spins; the chance of k reds in a row is (18 ÷ 37)ᵏ. The losing side of an even-money bet is 19 ÷ 37, because zero counts against it, so losing runs are slightly likelier than winning ones of the same length.

Runs on an even-money bet, single-zero wheel

RUN LENGTH	SAME COLOUR (WIN) RUN	LOSING RUN (INCL. ZERO)	A LOSING RUN THIS LONG STARTS ABOUT ONCE IN
3	11.51%	13.54%	15 spins
5	2.72%	3.57%	58 spins
8	0.31%	0.48%	425 spins
10	0.074%	0.128%	1,610 spins
13	0.009%	0.017%	12,000 spins
15	0.002%	0.005%	45,000 spins

Win run = (18 ÷ 37)ᵏ, losing run = (19 ÷ 37)ᵏ. The last column is 1 ÷ ((19 ÷ 37)ᵏ × (18 ÷ 37)), the average spacing between the starts of losing runs of at least k. A dozen or column misses five times in a row 14.1% of the time and ten times 1.98%.

Eight losses in a row is the number that matters to anyone doubling up, because it is where a martingale started at one unit needs a 256-unit stake and 255 units already on the table. It arrives about once every 425 spins — an evening, at a live pace, or twenty minutes at the pace of a demo table. The martingale, priced works through what that costs; the short version is that the streak is not the risk, the table limit is.

Streaks are also worth nothing as information. A run of eight reds changes the next spin’s red chance from 18 ÷ 37 to 18 ÷ 37. The reason streaks feel meaningful is that a 0.48% event is rare enough to remember and common enough to see, and memory keeps the streaks and discards the thousands of unremarkable spins between them.

The same price, different swings

Because tiles × multiplier equals 36 for every kind of bet, every bet on this wheel returns 97.30% and costs 2.7 units per 100 units staked. What differs, and differs enormously, is the swing — how far a session of a given length can end from that expected loss.

Every bet kind, priced and measured for swing

BET	POCKETS	WIN CHANCE	PAYS	RETURN	SWING PER SPIN	SWING OVER 100 SPINS
Straight	1	2.70%	×36	97.30%	5.84	58
Split	2	5.41%	×18	97.30%	4.07	41
Street	3	8.11%	×12	97.30%	3.28	33
Corner / first four	4	10.81%	×9	97.30%	2.79	28
Six line	6	16.22%	×6	97.30%	2.21	22
Dozen / column	12	32.43%	×3	97.30%	1.40	14
Red, black, odd, even, low, high	18	48.65%	×2	97.30%	1.00	10

Swing per spin is the standard deviation of one spin’s result per unit staked, √(payout² × chance − 0.973²); over N spins it grows as √N. Expected loss over 100 one-unit spins is 2.7 units on every row.

Read the last two columns together. A hundred one-unit spins on red lose 2.7 units on average with a standard deviation of 10, so ending anywhere between about 20 down and 15 up is unremarkable and the expected loss is a quarter of the noise. The same hundred spins on a single number lose the same 2.7 units on average with a standard deviation of 58: the typical outcome is either a loss of most of the hundred or one or two 36-unit hits that leave the session well ahead. The price is identical; the experience is not. Risk of ruin turns this into how long a given bankroll lasts on each bet.

Roulette here is a solo table with no server clock — you spin when you press Spin — so “per hour” depends entirely on the player. At a spin every ten seconds, 100 spins is under twenty minutes; the table above is the honest unit.

Checking a spin yourself

Before you play, the fairness panel shows the SHA-256 fingerprint of the server seed. Rotate your seed pair afterwards to reveal the seed and confirm the fingerprint.
Compute HMAC-SHA256 with the server seed as the key and “clientSeed-nonce-0” as the message; a spin uses cursor 0 only.
Take the first eight bytes of the digest as hi ÷ 2³² + lo ÷ 2⁶⁴ to get u, then floor(u × 37). That is the pocket, and every bet on the table settles from it.

The open-source verifier does the three steps in one command, betkyo-verify roulette <serverSeed> <clientSeed> <nonce>, and prints the pocket. If it matches the spin you were paid on, the pocket was fixed before you placed a chip — which, as what a hash commitment proves explains, is what the commitment guarantees and all it guarantees. The 1-in-37 is guaranteed by the published derivation, not by the hash.

FAQ

What are the odds of hitting a single number in roulette?

1 in 37 per spin on this single-zero wheel, 2.70%. The number lands at least once in 37 spins 63.7% of the time and in 100 spins 93.5% of the time; the median wait is 26 spins and the mean is 37.

How many spins does it take for a number to come up?

On average 37, but half of all waits are 26 spins or fewer and a few are very long: no hit in 100 spins happens 6.5% of the time, no hit in 200 spins 0.4%.

What are the odds of red coming up 10 times in a row?

(18 ÷ 37)¹⁰ = 0.074%, about 1 in 1,350. A losing run of ten on an even-money bet, which includes zero, is 0.128%, about 1 in 780. Neither changes the next spin, which is 18 ÷ 37 red regardless.

How often does zero come up in roulette?

Once in 37 spins on average. Zero appears at least once in 37 spins 63.7% of the time and in 74 spins 86.8%; it is absent from a full 37-spin cycle more than a third of the time.

Is a straight-up bet worse than red?

Not in price: both return 97.30% on this wheel. A straight-up bet is far more volatile — a standard deviation of 5.84 stakes a spin against 1.00 for red — so it produces long dry runs and occasional ×36 wins rather than a steady drift.

Can I verify a roulette spin?

Yes. HMAC-SHA256 of “clientSeed-nonce-0” keyed by the revealed server seed, first eight bytes as a fraction of 2⁶⁴, times 37 and floored, gives the pocket; the verifier’s roulette command does it in one step.

Sources

Betkyo engine source: deriveRouletteSpin(), rouletteNumbersOf() and rouletteMultOf() in roulette/derive.ts (pocket = floor(u × 37) at cursor 0; integer total-return multipliers ×36 … ×2); demoRouletteSpin() in _shared/demoLocal.ts; RouletteEngine.derivePocket() and settle() in the house service (U64SeedStream intBelow(37); stake × multiplier per covering key)
Exact calculations written for this article: (36 ÷ 37)ᴺ waiting times and the binomial counts for 37 spins, (18 ÷ 37)ᵏ and (19 ÷ 37)ᵏ run probabilities and their mean spacing, per-spin standard deviation for every bet kind and its √N growth
Betkyo provably-fair verifier (GitHub, MIT): the roulette command reproduces the pocket from serverSeed, clientSeed and nonce

Crash odds, priced: the chance of every cash-out target

Betkyo Research — Tue, 22 Sep 2026 02:41:09 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

A crash round is one hidden number and a curve that climbs toward it. The number is drawn by a formula that is four lines long, and the curve is a clock, so every question a player asks — how often does ×2 pay, how often does it bust at once, how long is a ride to ×10 — has an exact answer. We priced all of them from the engine, including the one-hundredth gap between a multiplier you see and a multiplier you are paid.

Quick answer: On this engine a crash bet with an auto cash-out at target x is paid when the round busts strictly above x, and the chance of that is exactly 0.99 ÷ x: 90.00% at ×1.10, 49.50% at ×2, 9.90% at ×10, 0.99% at ×100 and 0.0099%, one in 10,101, at ×9,999.99, the highest target that can ever pay. Multiply by the payout and every target returns 99.00% — a flat 1% house edge, the same as limbo. The bust itself lands on ×1.00 in exactly 1% of rounds, between ×1.01 and ×1.99 in 49.25%, at ×10 or higher in 9.90%, and on the ×10,000 cap once in 10,101. The curve doubles every ten seconds, so ×2 arrives at 10.0 s, ×10 at 33.2 s and ×100 at 66.4 s; the median round ends just under ten seconds in.

The number and the clock

Crash looks like a race against a rocket, and mechanically it is two much simpler things. Before the round starts the engine draws one hidden number, the bust point, from a committed hash. Then a clock starts and a multiplier climbs along a fixed curve; when the curve reaches the bust point the round is over, and everyone still riding loses their stake. A cash-out — manual, or an auto target set before the round — locks the multiplier at that moment and pays stake times multiplier. Nothing about the flight is random: the only random thing in the round is the number drawn before it.

Verified in the engine: CrashDerivation.crashPoint100() in the house service (crash/CrashEngine.kt), mirrored by bust100() in the client’s _shared/rng.ts: h is the top 52 bits of HMAC-SHA256(chain link, salt); with e = 2⁵² and n = 100 the bust point in hundredths is floor((n·e − h) ÷ (e − h)), clamped to the range 100 to 1,000,000. That is the bustabit formula, computed in integers so that the client verifier and the server agree bit for bit. The 1% edge is the n: n = 101 − 100 × house edge, so 100 at 1%.

Verified in the engine: multiplier100() in the same file and crashMultiplier() in the client’s crash/api.ts: the live multiplier after t seconds is floor(100 × e^(0.069314718 t)) hundredths, never below 100. The growth constant is ln 2 ÷ 10, so the multiplier doubles every ten seconds; msToReach() inverts it to schedule the bust.

Write the random part as a fraction u = h ÷ 2⁵², spread evenly between 0 and 1, and the bust formula becomes floor((100 − u) ÷ (1 − u)) hundredths. At u = 0 that is exactly 100, a bust at ×1.00 before the curve has moved; as u approaches 1 it runs away, and the clamp stops it at 1,000,000 hundredths, ×10,000. Everything below follows from that one line and the strict rule for what counts as a win.

Strictly above: the rule that sets the price

Verified in the engine: settleCrash() and applyAutoCashouts() in crash/CrashEngine.kt: an auto target pays only when target < bust point (“auto < crashPoint100”); a target equal to the bust point busts. Mid-flight the reachable multiplier is capped at bust point − 1, so an auto target fires the instant the live curve reaches it and never above the bust. cashout(): a manual cash-out at live multiplier m is refused when m ≥ bust point. The payout is stake × multiplier ÷ 100 floored to the coin’s raw unit (mult(), RoundingMode.FLOOR).

This is the detail the odds hinge on. A target of T hundredths does not win when the bust point equals T; it wins only when the bust point is at least T + 1. From the formula, the chance that the bust point is at least K hundredths is 99 ÷ (K − 1) for any K from 101 up, so the chance that it is at least T + 1 is 99 ÷ T. For a target of ×2, that is 99 ÷ 200 = 49.50%. Multiply by the ×2 payout and the return is 0.99 — and the T cancels the same way at every target.

Win chance, odds and volatility at common auto cash-out targets

TARGET	WIN CHANCE	ONE WIN IN	RETURN	HOUSE EDGE	SWING PER UNIT STAKED	REACHED AT
×1.01	98.02%	1.02 rounds	99.00%	1.00%	0.14	0.14 s
×1.10	90.00%	1.11	99.00%	1.00%	0.33	1.4 s
×1.20	82.50%	1.21	99.00%	1.00%	0.46	2.6 s
×1.50	66.00%	1.52	99.00%	1.00%	0.71	5.8 s
×1.98	50.00%	2.00	99.00%	1.00%	0.99	9.9 s
×2.00	49.50%	2.02	99.00%	1.00%	1.00	10.0 s
×3.00	33.00%	3.03	99.00%	1.00%	1.41	15.8 s
×5.00	19.80%	5.05	99.00%	1.00%	1.99	23.2 s
×10	9.90%	10.1	99.00%	1.00%	2.99	33.2 s
×20	4.95%	20.2	99.00%	1.00%	4.34	43.2 s
×50	1.98%	50.5	99.00%	1.00%	6.97	56.4 s
×100	0.99%	101	99.00%	1.00%	9.90	66.4 s
×1,000	0.099%	1,010	99.00%	1.00%	31.4	99.7 s
×9,999.99	0.0099%	10,101	99.00%	1.00%	99.5	132.9 s

Win chance = 99 ÷ T with T the target in hundredths, exact under the strict rule. Return = target × win chance = 0.99 at every row. Swing is the standard deviation of one round’s result per unit staked, √(0.99 × target − 0.9801). “Reached at” is 10 × log₂(target) seconds on the doubling curve. The lowest target the bet form accepts is ×1.01; ×10,000.00 is the bust cap itself and a target there can never be strictly below the bust, so ×9,999.99 is the top of the table.

The two middle columns do not move. Crash under this rule is priced exactly like limbo: 1% of every unit staked, whatever target you pick, whether you cash out by hand at ×1.37 or set an auto target at ×500. What the target changes is the shape of the result — a stream of small wins at ×1.10, a drought broken by a windfall at ×1,000 — and the last two columns measure that. At ×2 a round swings by about one stake; at ×1,000, by thirty-one stakes. The ride to ×1,000 also takes a hundred seconds, which is a different kind of cost.

One row deserves a second look. ×1.98 wins exactly half the time, which makes it the median bust point: half of all rounds bust above ×1.98 and half at or below it. The round number ×2.00 is a coin flip with a half-point handicap, 49.50%, and that half point is where the 1% lives at that target.

Seen versus paid: the one-hundredth gap

There are two questions that sound the same and are not. How often does the curve show ×2.00? And how often does a ×2.00 target get paid? The first is the chance that the bust point is at least 200 hundredths, 99 ÷ 199 = 49.75%. The second is the chance that it is at least 201, 99 ÷ 200 = 49.50%. The difference, one round in 402, is the round that busts on exactly ×2.00: the screen reaches the number and the ticket loses.

How often the curve reaches a multiplier versus how often a target there is paid

MULTIPLIER	CURVE REACHES IT	TARGET IS PAID	BUSTS ON IT EXACTLY
×1.01	99.00%	98.02%	0.98%, 1 in 102
×1.10	90.83%	90.00%	0.83%, 1 in 121
×1.50	66.44%	66.00%	0.44%, 1 in 226
×2.00	49.75%	49.50%	0.25%, 1 in 402
×3.00	33.11%	33.00%	0.11%, 1 in 906
×5.00	19.84%	19.80%	0.040%, 1 in 2,520
×10	9.910%	9.900%	0.0099%, 1 in 10,091
×100	0.9901%	0.9900%	1 in 1,010,000

Reaches = 99 ÷ (T − 1); paid = 99 ÷ T; the difference is 99 ÷ (T (T − 1)), the probability mass on the single hundredth T. The gap matters at low targets and vanishes at high ones.

This gap is the reason the engine draws the bust point as an integer number of hundredths rather than as a decimal that is rounded afterwards. With an integer draw, the strict rule hands exactly one hundredth of the distribution to the house at every target, and that one hundredth is what makes the return come out at 0.99 rather than a little above it. Our earlier comparison of limbo and crash priced crash from the “reaches it” column, 99x ÷ (100x − 1), and concluded that short rides were fractionally cheaper than 99%. That was the wrong column: under the engine’s strict settlement the price is 99.00% at every target, and the article now carries a correction.

Where the bust lands when nobody is aiming

The same formula describes the round itself, regardless of what anyone bets. The chance that the bust point is at least K hundredths is 99 ÷ (K − 1), and that gives the whole distribution of what the history bar shows.

Where the bust point lands

RANGE	SHARE OF ROUNDS	ABOUT	HOW LONG THE ROUND LASTS
×1.00 (instant bust)	1.00%	1 in 100	0 s
×1.01 to ×1.99	49.25%	1 in 2.0	0.1 to 9.9 s
×2.00 to ×9.99	39.84%	1 in 2.5	10 to 33 s
×10 to ×99.99	8.92%	1 in 11.2	33 to 66 s
×100 to ×999.99	0.891%	1 in 112	66 to 100 s
×1,000 to ×9,999.99	0.0891%	1 in 1,122	100 to 133 s
×10,000.00 (the cap)	0.0099%	1 in 10,101	133 s

Each row is 99 ÷ (lower − 1) minus 99 ÷ upper, in hundredths. The first row is the chance that (100 − u) ÷ (1 − u) falls below 101, u < 1 ÷ 100. The last row is every draw the clamp pins to 1,000,000 hundredths. Rows sum to 100%. Durations are 10 × log₂(multiplier) seconds.

Two rows explain most of what a crash session feels like. Exactly one round in a hundred busts at ×1.00, before the curve has moved a single hundredth, and no target — not even ×1.01 — is paid on it. And about one round in ten reaches ×10, which is often enough to be seen several times an hour and to make a high target feel reachable. It is reachable; the table says how often, and “often enough to remember” is a different number from often. The median round busts at ×1.98, just under ten seconds in, and the average round lasts 14.3 seconds because the rare long flights pull the mean up.

The rounds you sat out are drawn from this same distribution, and every one of them is a fresh HMAC of a fresh chain link. A ×500 in the history bar makes the next ×500 exactly as likely as it was before, 0.198%. That is the gambler’s fallacy in its purest form — here independence is not a statistical assumption but a property of the hash.

What chasing a big multiplier costs

Because the edge is the same everywhere, the choice of target is a choice about variance, and variance has a price that is easy to state: how many rounds you should expect to wait, and how likely a long wait is. With win chance p per round, the chance of at least one win in N rounds is 1 − (1 − p)ᴺ.

Chance of at least one win when betting the same target every round

TARGET	ROUNDS	AT LEAST ONE WIN	NO WIN AT ALL	TIME AT THE TABLE
×2	10	99.89%	0.11%	about 4 min
×10	20	87.57%	12.43%	about 8 min
×10	50	99.46%	0.54%	about 20 min
×100	100	63.03%	36.97%	about 41 min
×100	300	94.95%	5.05%	about 2 h
×1,000	1,000	62.86%	37.14%	about 7 h
×1,000	3,000	94.88%	5.12%	about 20 h

1 − (1 − 99 ÷ T)ᴺ, identical to limbo because the win chance is the same. Time assumes the average flight of 14.3 s plus the ten-second betting window, 24.3 s per round; a session at ×1,000 is dominated by the wait, not by the flight.

Put a stake on it and the arithmetic turns cold. A hundred one-unit bets at ×100 cost 100 units to place and return 99 on average — the 1% again — but the average is made of a 63% chance of getting back roughly 100 and a 37% chance of getting back nothing. Nothing about the target changes the 1% you pay per unit. Everything about it changes how the results are distributed among players, and in crash it also changes how long you sit watching a curve.

The low-target version of the same trap is the martingale: cash out at ×2, double after each loss, and collect one unit per win. The win chance at ×2 is 49.50%, a losing run of ten happens 0.11% of the time, and the eleventh bet is 1,024 units. The martingale, priced works that through on a roulette wheel; the crash figures are within a tenth of a point of it. Risk of ruin gives the general formula for how long any fixed-stake plan lasts against a 1% edge.

Cashing out by hand

A manual cash-out is paid at whatever hundredth the live multiplier shows when the server receives it, provided that hundredth is still strictly below the bust point. The curve does not tick evenly: floor(100 × e^(0.0693 t)) advances by one hundredth every 143 ms near ×1.01, every 72 ms around ×2, every 14 ms around ×10, and every 1.4 ms around ×100. A hand on the button at ×10 is choosing a number to within a few hundredths, at ×100 to within a few tenths, and the hundredth that finally lands is decided by network latency as much as by intent. None of that changes the price — each hundredth is paid at exactly 99% in expectation — but it does mean a manual target above ×10 is a looser instrument than an auto target, which fires at exactly the number you typed.

Verified in the engine: crashGame.tsx: the client shows an auto target as cashed the instant floor(live multiplier × 100) reaches it, matching the server’s applyAutoCashouts(), which locks the ticket at exactly the target and refuses a later manual cash-out on it. bet(): an auto target below 101 hundredths (×1.01) is rejected.

One practical detail from the settlement: the payout is stake × multiplier ÷ 100 floored to the coin’s smallest unit, so a stake of 0.37 at ×1.23 pays 0.45, not 0.4551. On round stakes at a two-decimal multiplier the product is exact and nothing is lost; on small odd stakes the fraction of a unit is.

Checking a round yourself

Before the round, the panel shows the commit hash of the chain and the salt. After the round it reveals the chain link for that round; hashing the link must give the previous round’s link, which is how the chain proves the order was fixed in advance.
Compute HMAC-SHA256 with the revealed link as the key and the salt as the message. Take the first 52 bits of the digest — the first thirteen hex characters — as h.
Compute floor((100 × 2⁵² − h) ÷ (2⁵² − h)) in integer arithmetic and clamp it to 100–1,000,000. That is the bust point in hundredths, and it should match the number the round crashed on.

Any HMAC-SHA256 tool and a big-integer calculator will do; the open-source verifier’s shared HMAC helper is the same primitive. The integer division is not optional: a floating-point version disagrees with the server at the floor boundaries, which is exactly the hundredth the strict rule is about. One rounding, not many explains why the verifier reproduces the server’s arithmetic rather than approximating it.

FAQ

What are the odds of winning at ×2 in crash?

49.50% on this engine. A target pays only when the round busts strictly above it, and the chance the bust point is at least 201 hundredths is 99 ÷ 200. The curve reaches ×2.00 slightly more often, 49.75%; the difference is the one round in 402 that busts on exactly ×2.00.

What is the house edge in crash?

1.00% at every cash-out target, manual or auto. The win chance is 99 ÷ target in hundredths and the payout is the target, so every bet returns 99.00% of the stake on average — the same price as limbo on this engine.

How often does crash bust at 1.00?

Exactly 1% of rounds, one in a hundred. The bust point is floor((100 − u) ÷ (1 − u)) hundredths, which is 100 whenever u is below 1 ÷ 100. No target, not even ×1.01, is paid on those rounds.

What is the best cash-out multiplier for crash?

None in expectation: every target costs 1% per unit staked. Low targets pay small amounts often and keep the swing near one stake; high targets pay rarely and swing by tens of stakes. ×1.98 is the exact 50/50 point and the median bust.

How long does a crash round last?

The multiplier doubles every ten seconds, so ×2 arrives at 10.0 s, ×10 at 33.2 s, ×100 at 66.4 s and the ×10,000 cap at 132.9 s. The median round busts just under ten seconds in; the average round lasts 14.3 seconds.

Can a ×10,000 auto target ever pay?

No. ×10,000.00 is the bust cap, and a target must be strictly below the bust to pay, so the highest target that can ever be paid is ×9,999.99, once in 10,101 rounds.

Is crash cheaper than limbo for short rides?

Not on this engine. An earlier article priced crash from the chance the curve reaches a multiplier and found 99.99% at ×1.01; under the strict settlement the chance that counts is one hundredth lower, and the return is exactly 99.00% at every target, as in limbo.

Sources

Betkyo engine source, house service: CrashDerivation.crashPoint100(), multiplier100(), msToReach(), applyAutoCashouts(), settleCrash(), mult() and cashout() in crash/CrashEngine.kt (bustabit integer bust point, strict “target < bust point” settlement, floor-to-unit payout, ×1.01 minimum auto target)
Betkyo engine source, client: bust100() and h52() in _shared/rng.ts (the same integer formula, BigInt); CRASH_GROWTH_R and crashMultiplier() in crash/api.ts; the auto-cashout display rule in crash/crashGame.tsx
Exact calculations written for this article: P(bust ≥ K) = 99 ÷ (K − 1) for K ≥ 101 from the integer formula, the strict-rule win chance 99 ÷ T, the reached-versus-paid gap 99 ÷ (T (T − 1)), the bust distribution by range, flight times 10 × log₂(x), the mean flight of 14.3 s summed over all 999,900 bust values, and at-least-one-win probabilities

Limbo odds, priced: the win chance behind every target multiplier

Betkyo Research — Sat, 19 Sep 2026 03:43:20 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

Limbo asks one question: will the number be at least as high as your target? The engine answers it with a single line of arithmetic, and that line can be priced exactly for every target the box accepts. Here is the win chance at every multiplier, why the house edge is the same 1% everywhere, how often the number stops below ×1.01, and what chasing ×100 or ×1,000 actually costs in patience.

Quick answer: On this engine’s limbo the win chance at any target is 99 divided by the target: 90.00% at ×1.10, 49.50% at ×2, 9.90% at ×10, 0.99% at ×100 and 0.0099%, one in 10,101, at the ×10,000 cap. Because the target is also the payout, every target returns exactly 99.00% of the stake and the house edge is 1.00% at every multiplier, from ×1.01 to ×10,000 — no target is better value than another, only more volatile. The rounding in the engine’s formula changes the number you see, not the odds you get. The number lands below ×1.01, where nothing can win, 1.98% of the time; its median is ×1.98; it reaches ×10 or more once in ten rounds and ×100 or more once in a hundred. Chasing ×100 at one bet a round, you have a 63% chance of at least one hit in 100 rounds and a 5% chance of none in 300.

One line of arithmetic

Limbo has no board, no cards and no wheel. You type a target multiplier, the engine draws a number, and you win if the number is at least your target — in which case you are paid your target times your stake. That is the entire game, and it makes limbo the easiest casino game there is to price, because the number comes from one formula with one random input.

Verified in the engine: curve100() in _shared/rng.ts: the outcome in hundredths is floor((0.99 ÷ (1 − u)) × 100), clamped to the range 100 to 1,000,000, where u is the uniform number in [0, 1) read from the round’s HMAC — the first eight bytes of the digest as hi ÷ 2³² + lo ÷ 2⁶⁴ (u64()). demoLimboBet() in _shared/demoLocal.ts draws u at cursor 0, sets win = outcome100 ≥ target100 and pays stake × target100 ÷ 100 floored to the cent. limboGame.tsx accepts targets from 101 to 1,000,000 hundredths (×1.01 to ×10,000.00) and shows the win chance as 99 ÷ target.

Read the formula from the inside out. The random number u is spread evenly between 0 and 1. Dividing 0.99 by 1 − u turns that even spread into a curve: u near 0 gives a number near ×0.99, u near 1 gives a number that runs away towards infinity. The ×100 and the floor turn it into a figure with two decimals, and the clamp pins it between ×1.00 and ×10,000.00. The 0.99 is the house edge, and it is the only place the edge lives.

The win chance at every target

You win at target T when floor(99 ÷ (1 − u)) is at least T, written in hundredths. Because T is a whole number of hundredths, the floor makes no difference to that comparison: a value of 199.7 floors to 199 and misses a target of 200, exactly as 199.7 itself would. So the condition is simply 99 ÷ (1 − u) ≥ T, which rearranges to u ≥ 1 − 99 ÷ T. The chance of a uniform number landing there is 99 ÷ T, and that is the whole answer.

Win chance, odds and volatility at common targets

TARGET	WIN CHANCE	ONE WIN IN	RETURN	HOUSE EDGE	SWING PER UNIT STAKED
×1.01	98.02%	1.02 rounds	99.00%	1.00%	0.14
×1.10	90.00%	1.11	99.00%	1.00%	0.33
×1.20	82.50%	1.21	99.00%	1.00%	0.46
×1.50	66.00%	1.52	99.00%	1.00%	0.71
×1.98	50.00%	2.00	99.00%	1.00%	0.99
×2.00	49.50%	2.02	99.00%	1.00%	1.00
×3.00	33.00%	3.03	99.00%	1.00%	1.41
×5.00	19.80%	5.05	99.00%	1.00%	1.99
×10	9.90%	10.1	99.00%	1.00%	2.99
×20	4.95%	20.2	99.00%	1.00%	4.34
×50	1.98%	50.5	99.00%	1.00%	6.97
×100	0.99%	101	99.00%	1.00%	9.90
×1,000	0.099%	1,010	99.00%	1.00%	31.4
×10,000	0.0099%	10,101	99.00%	1.00%	99.5

Win chance = 99 ÷ target, exact. Return = target × win chance = 0.99 at every row. Swing is the standard deviation of one round’s result per unit staked, √(0.99 × target − 0.9801); it is the number that grows, not the price.

The middle two columns are the point of the table, and they do not move. The target is both the hurdle and the payout, so raising it lowers the win chance in exactly the proportion that raises the prize, and the product stays at 0.99. A player who sits at ×1.10 and a player who fires at ×1,000 are paying the same 1% for every unit they stake; one of them is paying it in a steady trickle and the other in long droughts broken by a windfall. The last column measures the difference. At ×2 a round’s result swings by about one stake; at ×1,000, by thirty-one stakes; at the cap, by a hundred.

One row is worth a second look. At ×1.98 the win chance is exactly 50%, which makes ×1.98 the median outcome: half of all rounds end above it and half below. The round-number ×2.00 is a coin flip with a 0.5-point handicap, 49.50%, and that half point is where the 1% edge sits at that target. Every other target hides the same edge in the same way — a fair game would pay ×2.0202 for a 49.5% chance, and the engine pays ×2.

This is the part of limbo that differs from a dice game with a two-decimal multiplier. There, the payout is derived from the chosen chance and rounded, and the rounding can cost the player a few hundredths of a point at some settings. In limbo the player names the payout directly, in hundredths, and the formula compares the drawn number against that same figure; there is no second rounding to pay for. The floor in the formula decides only which two decimals appear on screen. The verifier article explains why that single floor has to be reproduced exactly when you check a round.

Where the number lands when nobody is aiming

The same formula describes the drawn number itself, regardless of any target. The chance that it reaches at least ×x is 0.99 ÷ x, for any x from ×1.01 upwards, and that gives the whole distribution of what the screen shows.

Where the drawn multiplier lands

RANGE	SHARE OF ROUNDS	ABOUT
×1.00 (below every target)	1.98%	1 in 50.5
×1.01 to ×1.49	32.02%	1 in 3.1
×1.50 to ×1.99	16.50%	1 in 6.1
×2.00 to ×2.99	16.50%	1 in 6.1
×3.00 to ×4.99	13.20%	1 in 7.6
×5.00 to ×9.99	9.90%	1 in 10.1
×10 to ×99.99	8.91%	1 in 11.2
×100 to ×999.99	0.891%	1 in 112
×1,000 to ×9,999.99	0.0891%	1 in 1,122
×10,000.00 (the cap)	0.0099%	1 in 10,101

Each row is 0.99 ÷ (lower bound) minus 0.99 ÷ (upper bound). The first row is the chance that 99 ÷ (1 − u) falls below 101 hundredths, u < 2 ÷ 101. The last row is every draw that the clamp pins to 1,000,000 hundredths. Rows sum to 100%.

Two of these rows explain most of what a limbo session feels like. About one round in fifty shows ×1.00, a number no target can beat: the 0.99 in the formula means the curve starts below ×1.01, and the lowest 1.98% of draws never clear it. And about one round in eleven shows ×10 or more, which is frequent enough to be seen several times an hour and to make a high target feel reachable. It is reachable — one round in a hundred and one clears ×100 — but the table says how often, and “often enough to remember” is not the same as often.

The rounds you are not betting on are drawn from this same distribution, which is why a screen full of recent results carries no information about the next one. Every round is a fresh HMAC of a fresh nonce; a ×500 in the history makes the next ×500 exactly as likely as it was before, 0.198%. That is the gambler’s fallacy in its purest form, because here the independence is not a statistical assumption but a property of the hash.

What chasing a big multiplier costs

Chance of at least one win when betting the same target every round

TARGET	ROUNDS	AT LEAST ONE WIN	NO WIN AT ALL
×2	10	99.89%	0.11%
×10	20	87.57%	12.43%
×10	50	99.46%	0.54%
×100	100	63.03%	36.97%
×100	300	94.95%	5.05%
×1,000	1,000	62.86%	37.14%
×1,000	3,000	94.88%	5.12%

1 − (1 − 99 ÷ T)ᴺ. The pattern repeats at every scale: betting the target’s own number of rounds (100 rounds at ×100, 1,000 at ×1,000) gives about a 63% chance of one hit, and three times that many gives about 95%.

Put a stake on it and the arithmetic turns cold. A hundred one-unit bets at ×100 cost 100 units to place and return 99 on average — the 1% again — but the average is made of a 63% chance of getting back roughly 100 and a 37% chance of getting back nothing. The player who does hit once in those hundred rounds is not ahead by much; the player who hits twice is up a lot, and the one who hits zero times has lost the whole hundred. Nothing about the target changes the 1% you pay per unit. Everything about it changes how the results are distributed among players.

The low-target version of the same trap is the martingale: bet ×2, double after each loss, and collect one unit per win. The win chance at ×2 is 49.50%, a losing run of ten in a row happens 0.11% of the time, and the eleventh bet is 1,024 units. The martingale, priced works that through on a roulette wheel; the limbo figures are within a tenth of a point of it. Risk of ruin gives the general formula for how long any fixed-stake plan lasts against a 1% edge.

One practical detail from the demo settlement: the payout is stake × target floored to the cent, so a stake of 0.37 at ×1.23 pays 0.45, not 0.4551. On whole-unit stakes with a two-decimal target the product is already exact and nothing is lost; on small odd stakes the fraction of a cent is. Real-money rounds settle in the coin’s own precision.

Checking a round yourself

Before you play, the fairness panel shows the SHA-256 fingerprint of the server seed. Rotate your seed pair afterwards to reveal the seed itself and confirm the fingerprint.
Compute HMAC-SHA256 with the server seed as the key and “clientSeed-nonce-0” as the message; the limbo round uses cursor 0.
Take the first eight bytes of the digest as hi ÷ 2³² + lo ÷ 2⁶⁴ to get u, then floor(0.99 ÷ (1 − u) × 100), clamped to 100–1,000,000. That is the outcome in hundredths, and it should match the round to the last digit.

The open-source verifier does the three steps in one command, betkyo-verify limbo <serverSeed> <clientSeed> <nonce>, and prints the outcome in hundredths. If it matches the round you were paid on, the number was fixed before you typed your target — which is what a commitment proves, and all it proves; what a hash commitment proves draws that line carefully.

FAQ

What are the odds of winning in limbo?

On this engine, 99 divided by your target: 49.50% at ×2, 9.90% at ×10, 0.99% at ×100 and 0.0099% (one in 10,101) at the ×10,000 cap. The formula is exact because the drawn number is floor(99 ÷ (1 − u)) and the target is a whole number of hundredths.

What is the house edge in limbo?

1.00% at every target. The win chance is 99 ÷ target and the payout is the target, so every bet returns 99.00% of the stake on average. No target multiplier is better value than another; a higher target only makes the results swing more.

What is the best target multiplier for limbo?

There is no better target in expectation — all of them cost 1% per unit staked. Low targets like ×1.10 or ×1.50 pay small amounts often; high targets pay rarely and big. Choose by how much variance you want, not by value, and remember that at ×100 you have a 37% chance of no win at all in 100 rounds.

How often does limbo crash at 1.00?

1.98% of rounds, about one in fifty. The formula starts at 0.99 ÷ (1 − u), so the lowest 1.98% of draws produce a number below ×1.01, and no target can win on those rounds.

Is ×2 in limbo a 50/50 bet?

Not quite: 49.50%. The exact 50% point is ×1.98, which is the median outcome. The half-point gap between ×1.98 and ×2.00 is the house edge at that target.

Does the rounding in the formula cost the player anything?

No. The floor in floor(99 ÷ (1 − u)) only decides the two decimals shown; because targets are whole hundredths, floor(x) ≥ T exactly when x ≥ T, so the win chance is 99 ÷ target without any rounding loss. The demo payout is floored to the cent, which matters only on small odd stakes.

Sources

Betkyo engine source: curve100() and u64() in _shared/rng.ts (outcome = floor(0.99 ÷ (1 − u) × 100) clamped to 100–1,000,000; u from the first eight digest bytes); demoLimboBet() in _shared/demoLocal.ts (cursor 0, win = outcome100 ≥ target100, payout floored to cents); target range and the 99 ÷ target win-chance display in limbo/limboGame.tsx
Exact calculations written for this article: win chance 99 ÷ T for every target, the outcome distribution 0.99 ÷ x, per-round standard deviation and at-least-one-win probabilities; cross-checked by replaying 400,000 rounds of the engine’s HMAC stream through curve100() (×10: 9.86% simulated vs 9.90% exact; below ×1.01: 1.97% vs 1.98%)
Betkyo provably-fair verifier (GitHub, MIT): the limbo command reproduces the outcome from serverSeed, clientSeed and nonce

Keno odds, priced: the chance of every hit count from one pick to ten

Betkyo Research — Fri, 18 Sep 2026 02:17:14 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

Forty numbers, ten drawn, up to ten marked. That is the whole of keno’s probability, and it can be computed to the last digit for every ticket you can buy. We priced all fifty-five hit counts from the engine’s draw loop and its forty payout tables: how many hits to expect, how rare a clean sweep is, and what the ×1,000 cell is actually worth.

Quick answer: On this engine’s keno — 40 numbers, 10 drawn without replacement, up to 10 picks — the chance of any hit count depends only on how many numbers you mark, never on which ones or which risk level. You hit one quarter of your picks on average: a ten-pick ticket averages 2.5 hits and lands on exactly two 31.07% of the time. Missing everything runs from 75.00% with one pick to 3.54% with ten. Hitting every number you marked is 1 in 4 for one pick, 1 in 2,611 for five, 1 in 18,278 for six and 1 in 847,660,528 for ten. The ×1,000 top cell on a ten-pick ticket is therefore worth 0.00012% of the stake — about one ten-thousandth of one percent — and the other 99% of the return is paid out of the ordinary hit counts. All forty payout tables return between 98.65% and 99.07%; the risk level moves how often a ticket beats its stake (from 1.21% to 79.58%), not the odds of hitting.

The board, the draw, and the one formula

Keno is a lottery with the ticket price and the prize table printed on the same screen. The board has forty numbers. You mark between one and ten of them. The game draws ten balls, none of them twice, and pays according to how many of your marks were drawn. There is no decision after the draw begins and no card to hold, which means the whole game reduces to one question with an exact answer: given k marks, how likely is each number of hits?

Verified in the engine: keno/kenoGame.tsx: BALLS = 40 and MAX_PICKS = 10; the board renders numbers 1 to 40 and refuses an eleventh pick. kenoDraws() in _shared/demoLocal.ts builds a pool of 40, then ten times in a row hashes the chain link, takes floor(norm × last), capped at last − 1, for the shrinking pool size last = 40 − i, pushes that ball and swaps it out of the pool — ten balls, no repeats. demoKenoBet() counts hits as the picks contained in the draw set and looks the multiplier up as KENO_PAYTABLE[level][picks.length][hits.length].

Ten balls from forty without replacement is the hypergeometric distribution, the same arithmetic as a lottery draw. With k numbers marked, the chance of exactly h hits is C(k, h) × C(40 − k, 10 − h) ÷ C(40, 10). The denominator is the number of distinct ten-ball draws, 847,660,528, and every one of them is equally likely. Nothing in that formula mentions the risk level, and nothing in it mentions which numbers you chose. Every table below is that formula evaluated for every ticket the board allows, then cross-checked by replaying the engine’s own draw loop two million times.

The chart: every hit count for every pick count

Chance of exactly h hits with k picks — 40 numbers, 10 drawn

PICKS	0 HITS	1	2	3	4	5	6	7	8	9	10
1	75.00%	25.00%	—	—	—	—	—	—	—	—	—
2	55.77%	38.46%	5.77%	—	—	—	—	—	—	—	—
3	41.09%	44.03%	13.66%	1.21%	—	—	—	—	—	—	—
4	29.99%	44.42%	21.42%	3.94%	0.23%	—	—	—	—	—	—
5	21.66%	41.65%	27.77%	7.93%	0.96%	0.038%	—	—	—	—	—
6	15.47%	37.13%	32.13%	12.69%	2.38%	0.20%	0.0055%	—	—	—	—
7	10.92%	31.85%	34.40%	17.64%	4.57%	0.59%	0.034%	0.00064%	—	—	—
8	7.61%	26.47%	34.74%	22.24%	7.48%	1.33%	0.12%	0.0047%	1 in 1,708,993	—	—
9	5.23%	21.40%	33.50%	26.06%	10.94%	2.53%	0.31%	0.019%	0.00049%	1 in 27,343,888	—
10	3.54%	16.88%	31.07%	28.82%	14.71%	4.24%	0.68%	0.057%	0.0023%	1 in 2,825,535	1 in 847,660,528

Exact hypergeometric probabilities; each cell is an integer count of draws divided by C(40, 10) = 847,660,528. Cells below one in a million are shown as odds. Rows sum to 100%.

Read down any column and the shape is the same story told ten times. Marking more numbers shifts the weight to the right — more hits on average — but the top of every row thins out faster than the row lengthens. Two hits is the most likely result for anyone marking seven or more; one hit for three to six; and with one or two picks the most likely outcome is nothing at all.

The number worth memorising is the average. Ten of forty numbers are drawn, so each mark has exactly a one-in-four chance of being hit, and a k-pick ticket averages k ÷ 4 hits whatever else is true about it. Ten picks average 2.5 hits; four picks average one. The payout tables are all built around that average, and each one decides what to do with the ticket that lands on it.

What each pick count promises

The shape of a ticket by number of picks

PICKS	AVERAGE HITS	MOST LIKELY	NO HITS	AT LEAST ONE	EVERY PICK HITS
1	0.25	0 (75.00%)	75.00%	25.00%	1 in 4
2	0.50	0 (55.77%)	55.77%	44.23%	1 in 17.3
3	0.75	1 (44.03%)	41.09%	58.91%	1 in 82.3
4	1.00	1 (44.42%)	29.99%	70.01%	1 in 435
5	1.25	1 (41.65%)	21.66%	78.34%	1 in 2,611
6	1.50	1 (37.13%)	15.47%	84.53%	1 in 18,278
7	1.75	2 (34.40%)	10.92%	89.08%	1 in 155,363
8	2.00	2 (34.74%)	7.61%	92.39%	1 in 1,708,993
9	2.25	2 (33.50%)	5.23%	94.77%	1 in 27,343,888
10	2.50	2 (31.07%)	3.54%	96.46%	1 in 847,660,528

Average hits is exactly picks ÷ 4. “At least one” is the chance the ticket touches the draw at all, which is not the same as the chance it pays — that depends on the level, below.

A ten-pick ticket almost always hits something: only one in twenty-eight comes back with nothing. That feels like a generous game, and the payout tables are where the feeling is corrected. A ten-pick ticket pays nothing below two hits on Low, below three on Classic and Medium, and below four on High, and those unpaid hit counts are the ones the chart says are common. Hitting something and being paid for it are different events, and the gap between them is how a keno table is tuned.

The last column is the one people search for. A clean sweep — every marked number drawn — is a one-in-four event with a single pick and becomes astronomically rare by ten. Each extra pick multiplies the odds against by a growing factor: the fourth pick roughly quintuples them, the tenth multiplies them by thirty-one. Five for five happens once in 2,611 tickets; eight for eight once in 1.7 million; ten for ten once in 847,660,528. The draw does not know it is being asked for a sweep, so no choice of numbers, level or timing changes any of those figures.

Hitting them all, and what the engine pays for it

The all-hit cell: its true odds against its multiplier on each level

PICKS	ODDS OF ALL HITS	FAIR MULTIPLIER	CLASSIC PAYS	LOW	MEDIUM	HIGH
1	1 in 4	×4	×3.96	×1.85	×2.75	×3.96
2	1 in 17.3	×17.3	×4.50	×3.80	×5.10	×17.10
3	1 in 82.3	×82.3	×10.40	×26	×50	×81.50
4	1 in 435	×435	×22.50	×90	×100	×259
5	1 in 2,611	×2,611	×36	×300	×390	×450
6	1 in 18,278	×18,278	×40	×700	×710	×710
7	1 in 155,363	×155,363	×60	×700	×800	×800
8	1 in 1,708,993	×1,708,993	×70	×800	×900	×900
9	1 in 27,343,888	×27,343,888	×85	×1,000	×1,000	×1,000
10	1 in 847,660,528	×847,660,528	×100	×1,000	×1,000	×1,000

Fair multiplier is 1 ÷ probability — what the all-hit cell would pay if it carried the whole return by itself. The gap to the paid multiplier is not the house edge; it is the return that the table pays out on lower hit counts instead.

Verified in the engine: KENO_PAYTABLE in keno/paytable.ts, which mirrors the TB_KENO_PROB rows the server pays from: the top cell of each row is 3.96, 4.50, 10.40, 22.50, 36, 40, 60, 70, 85 and 100 on CLASSIC; 1.85, 3.80, 26, 90, 300, 700, 700, 800, 1000 and 1000 on LOW; 2.75, 5.10, 50, 100, 390, 710, 800, 900, 1000 and 1000 on MEDIUM; 3.96, 17.10, 81.50, 259, 450, 710, 800, 900, 1000 and 1000 on HIGH. The demo settlement multiplies the stake by that cell and floors the result to cents.

High with one, two or three picks is the cleanest reading of this table, because on those rows the all-hit cell is the only cell that pays. There the multiplier is the whole return: ×3.96 against a fair ×4 is 99.00%, ×17.10 against ×17.33 is 98.65%, ×81.50 against ×82.33 is 98.99%. That is the house edge, expressed as a discount on the one prize.

Every other row pays the sweep at a fraction of its fair price, and the fraction shrinks fast. Five for five is worth ×2,611 at fair odds and pays ×450 on High, because the three- and four-hit cells on that row are paid the rest. By ten picks the ×1,000 cell is paid at about one 850,000th of its fair value, and its contribution to the ticket’s return is 1,000 ÷ 847,660,528 — 0.00012% of the stake. On a one-dollar ticket the largest number on the keno screen is worth about a ten-thousandth of a cent. The other 99% of the return is in the cells the chart calls ordinary.

When a ticket beats its stake

Chance a ticket returns more than it cost, by picks and level

PICKS	CLASSIC	LOW	MEDIUM	HIGH
1	25.00%	25.00%	25.00%	25.00%
2	44.23%	44.23%	44.23%	5.77%
3	14.88%	58.91%	14.88%	1.21%
4	25.59%	25.59%	25.59%	4.17%
5	36.69%	36.69%	36.69%	8.93%
6	15.28%	47.40%	15.28%	2.58%
7	22.83%	57.23%	22.83%	5.20%
8	31.17%	65.92%	31.17%	8.94%
9	39.86%	39.86%	39.86%	13.80%
10	48.51%	79.58%	48.51%	19.69%

Counts only cells paying more than ×1. Cells that return part or all of the stake — Classic’s two ×1.00 cells (three picks with one hit, six picks with two), its ×0.80, ×0.25 and ×0.47 cells, Low’s ×0.70 and Medium’s ×0.40 with one pick and no hits — are excluded. Every figure is a hit-count probability from the chart above.

Expected return of each of the forty payout tables

PICKS	CLASSIC	LOW	MEDIUM	HIGH
1	99.00%	98.75%	98.75%	99.00%
2	99.04%	98.85%	98.65%	98.65%
3	99.02%	98.87%	98.99%	98.99%
4	98.96%	98.92%	98.78%	98.91%
5	98.99%	98.90%	98.94%	98.89%
6	98.97%	99.01%	98.83%	99.00%
7	98.98%	98.94%	98.96%	98.96%
8	99.02%	99.00%	98.92%	98.96%
9	98.98%	99.07%	98.94%	98.96%
10	99.04%	98.76%	98.97%	99.01%

Each cell of KENO_PAYTABLE multiplied by its hit-count probability and summed. Forty tables, all within 0.42 points: the lowest is 98.65% (Medium and High at two picks), the highest 99.07% (Low at nine).

The two tables together are the whole product. The first one moves by a factor of sixty-five — Low with ten picks beats its stake on four tickets in five, High with three picks on one in eighty-three — and the second barely moves at all. Nothing you can select on the keno screen changes what a ticket is worth by more than half a point. What the selections change is how that value arrives: as a stream of small returns or as a rare large one. What a keno risk level changes takes that trade-off apart in detail; the chart above is the fixed input every one of those tables is built on.

Every ticket is a fresh draw from the same 847,660,528 combinations. A number that has not come up for an hour is exactly as likely as one that came up three times in a row, and a ticket that just missed by one is no closer to hitting next time — see the gambler’s fallacy. The demo draw commits a hash chain and salt before the balls fall and reveals them afterwards, so any single draw can be recomputed from the ticket.

FAQ

What are the odds of hitting all 10 numbers in keno?

One in 847,660,528 on a 40-number board with 10 balls drawn — that is C(40, 10), the number of distinct draws, and exactly one of them matches a ten-pick ticket. On this engine that cell pays ×1,000 on Low, Medium and High and ×100 on Classic.

What are the odds of hitting 5 out of 5 in keno?

One in 2,611 (0.038%). Four of five hits happens 0.96% of the time and three of five 7.93%. The engine pays five for five at ×36 on Classic, ×300 on Low, ×390 on Medium and ×450 on High.

How many numbers should I pick in keno?

The return is within half a point across every pick count and level (98.65% to 99.07%), so no pick count is better value. More picks means more hits on average — exactly one quarter of the marks — but the table demands more hits before it pays. Fewer picks means a simpler ticket that either hits or does not.

How many numbers will I hit on average?

A quarter of the numbers you mark, because 10 of the 40 are drawn. Ten picks average 2.5 hits and land on exactly two 31.07% of the time; four picks average one hit. Missing everything runs from 75.00% with one pick down to 3.54% with ten.

Does picking the same numbers every game improve my odds?

No. Every ten-ball draw is equally likely and independent of the last, so no set of numbers is due or cold. The odds of any hit count depend only on how many numbers you mark, and those odds are the chart in this article.

Is the ×1,000 keno prize worth chasing?

It is worth 0.00012% of the stake on a ten-pick ticket — ×1,000 multiplied by a one-in-847,660,528 chance. Almost all of the ticket’s 99% return is paid on ordinary hit counts, and on High nothing below four hits pays at all.

Sources

Betkyo engine source: BALLS = 40 and MAX_PICKS = 10 in keno/kenoGame.tsx; kenoDraws() and demoKenoBet() in _shared/demoLocal.ts (ten balls from a forty-number pool without replacement, hits counted against the draw set, multiplier looked up by pick count and hit count, floored to cents)
Betkyo engine source: KENO_PAYTABLE in keno/paytable.ts — all forty payout tables, mirrored from the TB_KENO_PROB rows the server pays from
Exact calculations written for this article: the hypergeometric distribution C(k, h) × C(40 − k, 10 − h) ÷ C(40, 10) for every pick and hit count, per-table returns and beat-the-stake probabilities from those cells, and a two-million-ticket replay of the engine’s swap-pool draw as a cross-check

Uston v. Resorts: the 1982 ruling that a casino cannot bar a card counter

Betkyo Research — Thu, 17 Sep 2026 01:47:08 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every date and citation was checked against the sources listed at the end and approved by a human editor.

On 30 January 1979 Atlantic City’s only casino barred the best-known card counter in America from its blackjack tables. Three years and three courts later the New Jersey Supreme Court told it that the rules of the game belonged to the state, not the house, and that a player who followed them could not be shown the door for being good at them. The house did not lose the war. It got the rules changed instead.

Quick answer: In Uston v. Resorts International Hotel, Inc., 89 N.J. 163, decided 5 May 1982, the New Jersey Supreme Court held unanimously that an Atlantic City casino could not exclude Kenneth Uston for card counting. The Casino Control Act gave the state’s Casino Control Commission exclusive authority over the rules of every licensed game, and Uston had broken none of them; in the court’s words, the Commission “has promulgated the blackjack rules that give Uston a comparative advantage, and it has sole authority to change those rules.” The same man had already lost in Nevada, where federal courts in 1977 and 1978 found no legal duty on a private casino to let him play. New Jersey answered its own ruling within weeks: the Commission adopted regulations in June and August 1982 letting casinos shuffle after any round, use more decks and run continuous-shuffling shoes, and in 1991 let them change table limits at any time. A counter could no longer be barred in New Jersey; the shoe he was counting could be shuffled the moment it turned in his favour. On an infinite-shoe engine there is no shoe to shuffle: every blackjack card is an independent draw of floor(u × 52) from a committed seed, so counting has nothing to count and the house needs no countermeasure.

Losing in Nevada first

Kenneth Uston was not a professional gambler by training. Born in New York in 1935, he went to Yale at sixteen, took an MBA at Harvard and rose to senior vice-president of the Pacific Stock Exchange in San Francisco before blackjack took over. By the mid-1970s he was running counting teams in Las Vegas on the model Edward Thorp’s arithmetic had made possible, and in 1977 he described the method in The Big Player, written with Roger Rapoport. The casinos read the book too. Being recognised became the main occupational hazard of the job.

On 29 June 1975 he sat down at the Flamingo Hilton and was escorted out under Nevada’s trespass statute. He sued, in federal court, on the theory that a casino so thoroughly licensed and regulated by the state was acting for the state when it threw him out, and that the state could not treat one lawful player differently from another. The theory failed twice. In Uston v. Airport Casino, decided by the Ninth Circuit on 24 May 1977 over his exclusion from the Marina casino “solely because he is a competent blackjack player”, the court found no state action in the casino’s decision. In Uston v. Hilton Hotels Corp., decided by the federal district court in Nevada in 1978, Chief Judge Foley held that the state’s gaming statute imposed no obligation on Nevada to compel a casino to admit a person it believed to be a card counter.

That is still the law in Nevada and in most of the United States. A casino is private property open to the public, and the traditional American rule lets the owner of such a place exclude anyone for any reason short of the ones civil rights statutes forbid. Skill at the owner’s own game is not one of those reasons. What made New Jersey different was not a kinder view of card counters but a different statute, and a different idea about who owned the rules.

30 January 1979

Resorts International opened on the Atlantic City boardwalk on 26 May 1978, the first legal casino in the United States outside Nevada, and for more than a year it was the only one. Uston moved east and began playing there in November 1978. On 5 January 1979 a new Casino Control Commission rule for blackjack took effect; contemporary reporting described it as allowing the cards to be shuffled only once per shoe, which is exactly the condition a counter wants, since the count is worth most deep in a shoe that has not been reshuffled. On 30 January 1979 Resorts barred him from its blackjack tables. He was not accused of cheating, of using a device or of disturbing anyone. The stated reason was that his way of playing increased his chances of winning.

Uston complained to the Commission, which sided with the casino: Resorts, it held, had a common-law right to exclude any patron for any reason. In December 1979 the Commission and the casinos tried the alternative as an experiment, admitting counters to the tables for a trial period. According to the wire reports of the time the trial was cut short after teams of counters won about $1.4 million. The number did nothing to soften the casinos’ view, and the case went up on appeal.

The litigation, 1975–1982

DATE	COURT	WHAT HAPPENED
29 June 1975	Flamingo Hilton, Las Vegas	Uston escorted from the blackjack tables under the trespass statute
24 May 1977	US Court of Appeals, Ninth Circuit	Uston v. Airport Casino: no state action in a Nevada casino excluding a “competent blackjack player”
1978	US District Court, Nevada	Uston v. Hilton Hotels: Nevada law imposes no duty to admit a suspected counter
30 January 1979	Resorts International, Atlantic City	Uston barred from blackjack; the Casino Control Commission upholds the casino
December 1979	Casino Control Commission	Trial period admitting counters, ended after reported team wins of about $1.4 million
11 May 1981	NJ Superior Court, Appellate Division	Reverses the Commission: a casino “is not empowered to so blacklist and exclude a person”; stayed pending appeal
5 May 1982	New Jersey Supreme Court	Affirms, unanimously: only the Commission can change the rules Uston was playing by

The Appellate Division ruled on 11 May 1981, after argument on 9 March, that the power to blacklist a patron belonged to the Commission alone, and that Resorts had excluded Uston for his skill rather than for anything that made him an undesirable. The casino obtained a stay and took the case to the state’s highest court, which heard argument on 9 February 1982 and decided it on 5 May.

What the court actually decided

Justice Pashman’s opinion for a unanimous court rests on two legs, and the second is the one that mattered. The first is the common law. New Jersey had once followed the old English rule that a theatre could eject a ticket-holder for no reason at all, but the court had already moved away from it: in State v. Schmid, two years earlier, it had said that “the more private property is devoted to public use, the more it must accommodate the rights which inhere in individual members of the general public who use that property.” An owner who opens the doors to everyone keeps the right to remove the disorderly, the intoxicated and the dangerous. Uston, the court observed, “does not threaten the security of any casino occupant. Nor has he disrupted the functioning of any casino operations.”

The second leg is the Casino Control Act. Section 100(e) of the Act says that all gaming shall be conducted according to rules promulgated by the Commission, and the Commission had written blackjack down in detail: the decks, the shuffle, the cut, the wagers, when a player may double or split. Uston had followed every one of those rules. If a casino could add a further, private rule that the game must not be played too well, the court reasoned, the state’s control of the game would be a fiction. As the opinion put it, the Commission “has promulgated the blackjack rules that give Uston a comparative advantage, and it has sole authority to change those rules.” Absent a valid contrary rule from the Commission, Uston “possesses the usual right of reasonable access to Resorts International’s blackjack tables.”

Two things the court did not decide are as important as the one it did. It did not say that card counting was a right; it said the Commission had not exercised its authority on the question, and expressly left open whether a Commission rule excluding counters would be lawful. And it did not throw the tables open at once. A temporary order keeping Uston away from Resorts’ blackjack tables was continued for ninety days, which the court described as time for the Commission to act. Resorts’ spokesman told the wire services the casino was “disappointed but we believe there will be a fair resolution to the problem.” The resolution arrived on schedule.

The commission has promulgated the blackjack rules that give Uston a comparative advantage, and it has sole authority to change those rules.
— Uston v. Resorts International Hotel, Inc., 89 N.J. 163 (1982), Pashman, J.

The countermeasures

The Commission did not ban counters. It changed the game so that counting was worth less, which is what the court had all but invited it to do. Rule amendments published in the New Jersey Register on 7 June 1982 and adopted on 2 August 1982 rewrote the blackjack shuffle regulation, N.J.A.C. 19:47-2.5, so that the dealer shuffles “immediately prior to commencement of play, after any round of play as may be determined by the casino licensee and after each shoe of cards is dealt.” That phrase, “after any round of play as may be determined by the casino licensee”, is the shuffle-at-will rule. A pit boss who believes the shoe has turned rich in tens can order a shuffle before the next hand, and the count goes back to zero.

Countermeasures the Commission authorised after Uston

MEASURE	RULE	WHEN	WHAT IT DOES TO A COUNTER
Shuffle at will	N.J.A.C. 19:47-2.5(a)	1982 (14 N.J.R. 559, 841)	The casino may reshuffle after any round, so a favourable shoe can be erased before it is bet on
Bart Carter shuffle	N.J.A.C. 19:47-2.1	1982	About a deck is shuffled back after being dealt and kept in separate stacks, blurring what has left the shoe
Continuous shuffling shoe	N.J.A.C. 19:47-2.21	1982	A device reshuffles automatically; there is never a depleted shoe to track
More decks	N.J.A.C. 19:47-2.2	1982	A larger shoe dilutes the swing any run of low cards can produce
Limits changed at any time	N.J.A.C. 19:47-8.3(c)	1991 (23 N.J.R. 1784)	A table’s minimum and maximum may be changed without notice to the Commission, so a counter can be held to small bets

Rule citations and Register references as recited by the Third Circuit in Doug Grant, Inc. v. Greate Bay Casino Corp. (2000) and the New Jersey Supreme Court in Campione v. Adamar (1998). Section numbers are those in force at the time; the blackjack rules have since been recodified.

Each measure attacks the same thing, the memory of the shoe. Counting works only because cards dealt are cards gone, and a shoe short of low cards is a shoe rich in high ones. Shuffle earlier, shuffle more, or shuffle continuously, and the memory is shortened or removed. The extra decks work on the other side of the equation: the same run of small cards moves the composition of an eight-deck shoe far less than a single deck. None of it required the counter to leave. It required only that the thing he was counting stop being worth counting.

The rules did not end the argument, they moved it. In 1991 Anthony Campione, a counter identified by TropWorld’s in-house card-counting team, was held to a $100 maximum at a table where other players were allowed $1,000 and restricted to one hand while others played several; he sued, a jury awarded him $1,519,873, and on 22 July 1998 the New Jersey Supreme Court held that a patron may bring a common-law discrimination claim against a casino in the ordinary courts, while leaving to the Commission the first word on what its own countermeasure regulations permit. In Doug Grant, Inc. v. Greate Bay Casino Corp., decided on 2 November 2000, a group of counters challenged the countermeasures themselves and lost; the Third Circuit’s answer was that “the normal chance and random character of any casino game is necessarily defined and determined by the rules governing the conduct of the game”, and the rules were the Commission’s to write. Uston himself did not see most of this. He died in Paris on 19 September 1987, at fifty-two.

Uston remains a minority rule. Outside New Jersey, American casinos generally retain the property owner’s right to refuse a card counter, and Nevada’s courts have never departed from the position they took in Uston’s own cases. Counting with one’s own memory is not a crime anywhere in the United States; being asked to leave for it is, in most places, not a wrong either.

A shoe with no memory

It is worth being precise about why none of this, the ruling, the shuffle-at-will rule or the continuous shoe, has any bearing on an infinite-shoe blackjack engine, because the reason is structural rather than a matter of policy. The Commission’s countermeasures all shorten the memory of a physical shoe. An infinite-shoe engine deals from a shoe that has no memory to shorten.

Every card in a round is derived separately. The client code takes the round’s committed server seed as an HMAC-SHA256 key, signs the message clientSeed-nonce-cursor, reads the first eight bytes of the digest as a number u between 0 and 1, and deals card floor(u × 52). The cursor is the position in the deal order: the player’s first card, the dealer’s up card, the player’s second card, the dealer’s hole card, then each further draw. Because the cursor changes and nothing else does, each card is an independent draw from all fifty-two with replacement. The ten you were just dealt does not make the next ten any less likely. A running count of what has been dealt carries no information about what comes next, which is exactly the property a dealt shoe lacks and a counter lives on.

Verified in the engine: blackjack/derive.ts header: “Infinite shoe: card i = floor(u × 52) at cursor i, so every card of the round is a pure function of (seed pair, nonce, deal order).” deriveBjCard(serverSeed, clientSeed, nonce, cursor) returns Math.min(Math.floor(u × 52), 51) where u = u64(hmacSha256Utf8(serverSeed, ${clientSeed}-${nonce}-${cursor})). Deal order per the same header: player1, dealer-up, player2, dealer-hole, then every further draw in play order. _shared/rng.ts: u64 reads the first eight bytes of the digest as hi/2^32 + lo/2^64.

A dealt shoe has memory. Its composition drifts as cards leave it, the drift can be tracked, and the house’s defence is to shorten the memory: shuffle earlier, shuffle at will, shuffle continuously.
An infinite shoe has none. Each card is a fresh function of the seed pair and its cursor, so there is nothing to track and nothing for the house to reset. No shuffle-at-will rule exists here because no shuffle exists.
The rules are the code. In Atlantic City the rules of blackjack are a regulation that a player can read and the house cannot privately amend. In an open engine they are the derive module, published, with the basic strategy priced cell by cell against it.

Uston won the right to play a game whose rules were written down by someone other than the house, and the house answered by asking that someone to rewrite them. A game whose rules are code has the same property in a stronger form: the rule that decides each card is fixed before the round, committed to by hash, and reproducible afterwards by anyone who cares to check. It also means there is no edge in it for a counter, and it is better to say that plainly than let anyone spend an evening looking for one.

FAQ

What did Uston v. Resorts International decide?

On 5 May 1982 the New Jersey Supreme Court held that an Atlantic City casino could not exclude Kenneth Uston for card counting. The Casino Control Act gives the Casino Control Commission exclusive authority over the rules of licensed games, Uston had broken none of them, and only the Commission could change them. The court left open whether the Commission itself could adopt a rule excluding counters.

Why could Nevada casinos bar Uston but New Jersey casinos could not?

Uston’s Nevada suits, decided in 1977 and 1978, failed because a private casino excluding a player is not the state acting, and Nevada law imposes no duty to admit a suspected counter. New Jersey’s Casino Control Act places every rule of play under the Commission, so a casino cannot add a private rule of its own. New Jersey’s position remains a minority rule in the United States.

How did the Casino Control Commission respond to the ruling?

With rule changes rather than a ban. Amendments published in June 1982 and adopted in August 1982 let casinos shuffle after any round, use the Bart Carter shuffle, install continuous-shuffling shoes and use more decks. In 1991 a further rule let a casino change a table’s minimum and maximum wager at any time without notifying the Commission.

Is card counting illegal?

No. Counting with your own memory is not a crime anywhere in the United States. What differs is whether a casino may refuse to deal to you for it: in New Jersey it may not, but it may shuffle at will and adjust limits; in Nevada and most other states it may simply ask you to leave. Devices that count for you are a separate and criminal matter in many places.

Can you count cards in online blackjack?

Not on an infinite-shoe game. Each card is floor(u × 52) where u comes from HMAC-SHA256 of the committed server seed over clientSeed-nonce-cursor, so every card is an independent draw with replacement. Nothing depletes, so there is nothing to count and no countermeasure to apply. Live-dealer games with a physical shoe are the exception, which is why they shuffle early.

Sources

Uston v. Resorts International Hotel, Inc., 89 N.J. 163, 445 A.2d 370 (N.J. 1982), argued 9 February 1982, decided 5 May 1982
Uston v. Resorts International Hotel, Inc. — edited text of the opinion (Marquette University Law School reading assignment)
UPI, 5 May 1982 — “Atlantic City casinos do not have the right to…”
UPI, 11 May 1981 — “Court rules casinos cannot ban card counters”
Uston v. Resorts International Hotel, Inc., 179 N.J. Super. 223 (App. Div. 1981), argued 9 March 1981, decided 11 May 1981
Uston v. Airport Casino, Inc., 564 F.2d 1216 (9th Cir. 1977), decided 24 May 1977
Uston v. Hilton Hotels Corp., 448 F. Supp. 116 (D. Nev. 1978)
Campione v. Adamar of New Jersey, Inc., 155 N.J. 245, 714 A.2d 299 (N.J. 1998), decided 22 July 1998
Doug Grant, Inc. v. Greate Bay Casino Corp., 232 F.3d 173 (3d Cir. 2000), decided 2 November 2000
Wikipedia — Ken Uston
Wikipedia — Resorts Casino Hotel
Wikipedia — Caesars Atlantic City
Betkyo engine source: blackjack/derive.ts (infinite shoe, deriveBjCard, deal order), _shared/rng.ts (hmacSha256Utf8, u64)

Baccarat, priced: what Banker, Player, Tie and the pair bets cost

Betkyo Research — Wed, 16 Sep 2026 03:50:41 +0000

Originally published in the Betkyo Journal. Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

Baccarat has no decisions after the bet, which means every price in it can be computed to the last digit. We took the drawing rules and payouts straight from the engine, enumerated every deal, and priced the five spots on the table — including why Banker needs a commission at all.

Quick answer: On this engine’s baccarat — standard punto banco drawing rules, Player 1:1, Banker 0.95:1, Tie 8:1, either pair 11:1, ties returning Player and Banker stakes — the demo deal draws every card independently, and on that deal the exact odds are Banker 45.84%, Player 44.61%, Tie 9.54%. That makes the house edge 1.06% on Banker, 1.23% on Player, 14.12% on Tie and 7.69% on each pair bet. Banker wins more often because it draws its third card after seeing Player’s; paid even money it would return +1.23% to the player, so the 5% commission is what turns it into a house bet — any commission above 2.68% does. A standard eight-deck shoe moves the Banker and Player figures by less than a hundredth of a point but raises the pair bet’s edge to 10.36%. Banker is the cheapest spot on the table; every spot still costs money.

The rules, as written in the engine

Baccarat is a game with no choices after the chips go down. Two hands, Player and Banker, get two cards each. Cards count at face value, aces as one, tens and faces as zero, and only the last digit of the total matters. Whichever hand is closer to nine wins. A fixed table decides whether either hand takes a third card. Because nobody decides anything, the probability of every outcome is a finite sum — which makes baccarat one of the few casino games that can be priced exactly rather than estimated.

Verified in the engine: baccarat/baccaratApi.ts, SPOT_PAYOUT: { player: 1, banker: 0.95, tie: 8, playerPair: 11, bankerPair: 11 } (winnings to stake). The demo settlement returns stake × 2 on a Player win, × 1.95 on a Banker win, the Player and Banker stakes back on a tie, × 9 on Tie, and × 12 on a pair — a pair being the first two cards of that hand with the same rank.

Verified in the engine: baccarat/baccaratApi.ts, demoDeal() — “standard punto-banco third-card rules”: no third card if either two-card total is 8 or 9; Player draws on 0 to 5 and stands on 6 or 7; if Player stood, Banker draws on 0 to 5; if Player drew, Banker draws on 0 to 2, on 3 unless Player’s third card is an 8, on 4 against a third card of 2 to 7, on 5 against 4 to 7, on 6 against 6 or 7, and stands on 7. Each card is an independent draw: rank = floor(random × 13) + 1.

That last line matters. The demo deal draws every card with replacement, as if from an infinite deck: each rank is one in thirteen on every card, ten-valued cards four in thirteen. That is the deal priced below. The real-money deal is produced by the house service and verified from its ticket; the payouts are the same, and the last section shows how much the figures would move on a finite shoe.

Who wins, and how often

Every deal enumerated: 13⁶ = 4,826,809 equally likely rank sequences

OUTCOME	EXACT FRACTION	PROBABILITY	ABOUT
Banker wins	2,212,744 / 4,826,809	45.8428%	1 in 2.18
Player wins	2,153,464 / 4,826,809	44.6147%	1 in 2.24
Tie	460,601 / 4,826,809	9.5426%	1 in 10.48

Exact enumeration over up to six cards with the engine’s drawing rules, cross-checked against three million deals run through the demoDeal function itself. Excluding ties, Banker takes 50.68% of decided hands.

How often the drawing rules come into play

EVENT	PROBABILITY
A natural (either hand 8 or 9 on two cards)	34.28%
Player draws a third card	50.37%
Banker draws a third card	43.58%
Deal ends with 4 cards	37.87%
Deal ends with 5 cards	30.32%
Deal ends with 6 cards	31.81%

Banker wins more than Player for one reason: it acts second. Player’s rule looks only at Player’s own total. Banker’s rule looks at its own total and at the card Player just drew, and the table is built so Banker draws when that card makes drawing favourable and stands when it does not. The advantage is about 1.23 points of win probability, and it is all information.

Five spots, priced

House edge of each spot on the engine’s deal

SPOT	PAYS	WINS	HOUSE EDGE	EDGE PER DECIDED HAND	COST PER 100 BETS OF 10
Banker	0.95 : 1	45.84%	1.0640%	1.1762%	10.64
Player	1 : 1	44.61%	1.2281%	1.3577%	12.28
Tie	8 : 1	9.54%	14.1170%	—	141.17
Player pair	11 : 1	7.69% (1 in 13)	7.6923%	—	76.92
Banker pair	11 : 1	7.69% (1 in 13)	7.6923%	—	76.92

House edge is the expected loss as a share of the amount staked, counting a tie as a returned stake. The per-decided-hand column divides by the 90.46% of deals that are not ties, for readers comparing with tables that quote it that way. Cost is the expected loss in units.

The ordering is the whole strategy the game has. Banker is the cheapest bet on the table, Player close behind, and the gap between them is 0.16 points. Tie costs about thirteen times as much as Banker per unit staked. The pair bets sit in between, and they are the ones whose price depends most on how the cards are dealt.

Backing Player and Banker at the same time, with equal stakes, does not hedge anything. Whichever side wins, the other loses, the commission is taken on Banker’s wins, and a tie returns both. The combined position loses 1.15% of the total staked — the average of the two edges — and the combined position can never finish a hand ahead.

Why Banker pays 0.95

The Banker bet at different commissions, same deal

COMMISSION	BANKER PAYS	PLAYER’S EXPECTED RESULT PER UNIT
None	1 : 1	+1.2281%
2%	0.98 : 1	+0.3113%
2.5%	0.975 : 1	+0.0821%
3%	0.97 : 1	−0.1471%
4%	0.96 : 1	−0.6056%
5% (this engine)	0.95 : 1	−1.0640%

Break-even commission: 1 − P(Player) ÷ P(Banker) = 2.68%. Below it the Banker bet would favour the player.

Paid at even money, Banker would be a bet the player wins over time — the reverse of Player, and by exactly the same margin, because Banker’s win is Player’s loss. The commission exists to take that back and a little more. Anything above 2.68% makes Banker a house bet; the traditional 5% leaves it at 1.06%, still below Player’s 1.23%. The commission is not a tax on winning. It is the price of the information Banker’s drawing rule has and Player’s does not.

The Tie bet shows the same arithmetic from the other side. A tie comes up once in 10.48 deals, so a fair Tie bet would pay about 9.48 to 1. At 8 to 1 the edge is 14.12%. For comparison only, a table paying 9 to 1 on the same deal would charge 4.57%; this engine pays 8 to 1.

What a finite shoe would change

The engine’s rules and payouts on three decks, computed exactly

SPOT	INFINITE DECK (DEMO DEAL)	EIGHT-DECK SHOE	SIX-DECK SHOE
Banker	1.0640%	1.0579%	1.0558%
Player	1.2281%	1.2351%	1.2374%
Tie	14.1170%	14.3596%	14.4382%
Either pair	7.6923%	10.3614%	11.2540%

Shoe figures are exact enumerations of a freshly shuffled shoe with cards drawn without replacement, for comparison. They are not a statement about how the real-money deal is dealt.

For the three main spots, the number of decks barely matters: Banker and Player move by less than a hundredth of a point between an infinite deck and eight decks. The pair bets are different. A pair needs the second card to match the first card’s rank, and in a finite shoe the first card has already used up one of that rank. On an infinite deck the chance is exactly 1 in 13; in an eight-deck shoe it is 31 in 415, and at the same 11 to 1 payout the edge rises from 7.69% to 10.36%.

None of these figures changes with what happened on earlier hands of the demo, because each demo card is an independent draw. Patterns on a score road describe the past, not the next deal — see the gambler’s fallacy.

FAQ

What is the house edge on Banker in baccarat?

On this engine’s deal, with Banker paying 0.95 to 1, the house edge is 1.06% of the amount staked (1.18% if ties are excluded). On a standard eight-deck shoe the same rules give 1.058%.

Is it better to bet Banker or Player?

Banker costs less: 1.06% against 1.23% on Player, even after the 5% commission. Banker wins 45.84% of deals and Player 44.61%, because Banker’s drawing rule can react to Player’s third card.

Why does the Banker bet charge a commission?

Without it Banker would favour the player by 1.23%. Any commission above 2.68% turns it back into a house bet; the 5% commission leaves a 1.06% edge.

What are the odds of a tie in baccarat?

A tie comes up in 9.54% of deals, about once in 10.48. The Tie bet pays 8 to 1 here, which gives it a 14.12% house edge — the most expensive main bet on the table.

Are the pair side bets worth it?

They cost more than Banker or Player. A pair comes up 1 time in 13 on the engine’s demo deal and pays 11 to 1, an edge of 7.69%. On an eight-deck shoe the chance drops to 31 in 415 and the edge rises to 10.36%.

Sources

Betkyo engine source: SPOT_PAYOUT, demoDeal() and the demo settlement in baccarat/baccaratApi.ts (payouts, third-card rules, ties returning Player and Banker stakes, pairs by matching rank, independent card draws)
Exact calculations written for this article: full enumeration of the drawing rules on an infinite deck and on six- and eight-deck shoes without replacement, commission and tie-payout sweeps, and a three-million-deal run of demoDeal as a cross-check

Dealer bust odds by upcard: the exact table behind basic strategy (infinite shoe, S17)

Betkyo Research — Sun, 13 Sep 2026 04:20:24 +0000

Originally published on the Betkyo Journal, where every figure is read from the game engine's source.

Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

On this engine every blackjack card is drawn independently with each rank equally likely and tens four times as likely, an infinite shoe, and the dealer stands on all 17s. Under those rules the dealer’s chance of busting from each upcard is exact: about 35% from a 2, rising to 42% from a 6, then falling sharply to 26% from a 7, 21% from a 10 and 12% from an ace. Across all upcards the dealer busts on about 28% of hands. The cliff between 6 and 7 is the whole shape of basic strategy: against a 2 to 6 the dealer is likely to bust, so a player with a stiff hand stands and lets it happen; against a 7 or higher the dealer usually makes a hand, so the player must take a card even at the risk of busting. Those player risks are exact too: hitting a hard 16 busts 61.5% of the time, a hard 12 30.8%. Nothing in the table depends on what was dealt before, because an infinite shoe has no memory, which is also why counting has nothing to count here.

The shoe with no memory

A physical blackjack shoe is a finite thing: six or eight decks, and every card that comes out changes the mix of what is left. That is what makes card counting possible and what makes exact odds a moving target. The engine here does something simpler and, for the purposes of a table like this one, cleaner. Each card is derived from its own cursor of the round’s hash as floor(u × 52), so every draw is an independent pick from a full deck. Ranks two through nine and the ace each have probability 1 in 13; a ten-value card has 4 in 13.

Verified in source. blackjack/derive.ts header: “Infinite shoe: card i = floor(u × 52) at cursor i, so every card of the round is a pure function of (seed pair, nonce, deal order).” Rules: “dealer stands on all 17s (S17), blackjack pays 3:2, double on any first two cards (incl. after split), split once on equal VALUE (tens mix), split aces get one card each, dealer peeks under an ace or ten so a dealer blackjack never eats a double. No insurance, no surrender.”

With those two facts, independent draws and stand on all 17s, the dealer’s hand is a small Markov chain that can be solved exactly. Start from the upcard, draw until the total is 17 or more, counting a soft total as an ace plus ten while that keeps the hand under 22. The figures below are computed for this article by that recursion, not simulated and not copied from a strategy site.

The table

Dealer final result by upcard: infinite shoe, dealer stands on all 17s, percentages

UPCARD	BUST	17	18	19	20	21
2	35.4	14.0	13.5	13.0	12.4	11.8
3	37.4	13.5	13.0	12.6	12.0	11.5
4	39.4	13.0	12.6	12.1	11.6	11.1
5	41.6	12.2	12.2	11.8	11.3	10.8
6	42.3	16.5	10.6	10.6	10.2	9.7
7	26.2	36.9	13.8	7.9	7.9	7.4
8	24.5	12.9	35.9	12.9	6.9	6.9
9	22.8	12.0	12.0	35.1	12.0	6.1
10	21.2	11.1	11.1	11.1	34.2	11.1
A	11.5	13.1	13.1	13.1	13.1	36.2

The 21 column for a ten or an ace includes the dealer’s natural. Rows sum to 100 within rounding. Weighted by how often each upcard appears, the dealer busts on about 28.2% of hands.

Read down the bust column and the game’s structure appears. From a 2 the dealer must draw at least twice to reach 17 and busts about a third of the time; each higher low card makes the second draw more dangerous, and a 6 is the worst card the dealer can show, busting 42.3% of the time and, when it survives, most often stopping on a weak 17. Then the cliff: a 7 needs only a ten to make 17, and the dealer stands on 17 more than a third of the time from it. From a ten, the dealer makes 20 on a third of hands. From an ace, the dealer busts once in nine and makes 21 more than a third of the time.

Read across a row and you see why a player’s stiff hand is a different problem against different upcards. Against a 6, standing on 16 wins whenever the dealer busts, 42% of the time, and the dealer’s made hands are mostly 17s. Against a 10, standing on 16 wins only the 21% of the time the dealer busts, and the dealer’s made hands are mostly 20s. That asymmetry is the whole content of the top half of a basic strategy chart.

The player’s side

Chance of busting on one more card, from a hard total, infinite shoe

HARD TOTAL	CARDS THAT BUST	CHANCE OF BUSTING
12	any ten	30.8%
13	9 or ten	38.5%
14	8, 9 or ten	46.2%
15	7 through ten	53.8%
16	6 through ten	61.5%

Each row is the number of busting ranks over 13, with tens counted four times. A hard 16 is the worst hand in the game for exactly this reason: hitting it busts more often than not, and standing on it beats only a dealer bust.

Put the two tables together and the classic decisions fall out without any memorising. Hard 16 against a dealer 6: hitting busts 61.5% of the time, standing wins the 42.3% of the time the dealer busts, so stand. Hard 16 against a dealer 10: standing wins only 21.2% of the time, and hitting, though it busts more often than not, at least sometimes produces a hand that beats a 20, so hit. Hard 12 against a 4: hitting busts only 30.8% of the time while the dealer busts 39.4%, and the right answer is close enough that charts differ on the neighbouring cells.

The tables are exact for this engine and approximate for a real shoe. A finite shoe with cards removed shifts every figure slightly, which is the effect a counter tracks. Here there is no removal.
The dealer’s peek matters for one thing only. Because the dealer checks for a natural under a ten or an ace before you act, a dealer blackjack ends the hand before a double or split can lose extra; the bust odds above are for hands that continue.
None of this beats the edge. Basic strategy on these rules returns about 99.5%, the figure the engine header states; the tables explain the strategy, they do not improve on it.

Verified in source. The two tables were computed for this article by exact recursion over the infinite-shoe rank distribution (1/13 per rank, 4/13 for tens) with the dealer standing on all 17s, the rule blackjack/derive.ts states; the “about 99.5% RTP with basic play” figure is the engine header’s. The house service is the paying authority.

The table as open data (CC BY 4.0): https://betkyo.com/data/blackjack-dealer-outcomes.json — and the 60-line recursion that produces it, with a chart: https://github.com/betkyo-open-labs/odds-derivations

FAQ

How often does the dealer bust in blackjack?

On this engine’s infinite shoe with the dealer standing on all 17s, about 28% of hands overall: from 35% with a 2 showing up to 42% with a 6, then 26% with a 7, 21% with a ten and 12% with an ace.

Why is a dealer 6 the best card for the player?

It is the upcard from which the dealer busts most often, 42.3%, and when the dealer does not bust the most common result is a weak 17. A stiff player hand can stand and let the dealer bust.

Why is hard 16 the worst hand?

Hitting it busts 61.5% of the time, and standing on it wins only when the dealer busts. Against a 7 or higher the dealer usually makes a hand, so both options are bad and hitting is merely less bad.

Are these numbers the same in a real casino?

Close but not identical. A finite shoe with cards removed shifts every figure slightly, which is what card counting tracks. The infinite shoe here has no removal, so the figures are exact and never change.

Does knowing the table beat the house?

No. It explains basic strategy, which on these rules returns about 99.5% according to the engine header. The edge remains with the house.

Sources

Betkyo engine source: blackjack/derive.ts (infinite shoe, floor(u × 52), stand on all 17s, peek rule, 3:2 natural, about 99.5% with basic play)
Both tables computed for this article by exact recursion over the infinite-shoe rank distribution; no third-party strategy site was used

This article first appeared on the Betkyo Journal: https://betkyo.com/en/blog/dealer-bust-odds-by-upcard-on-an-infinite-shoe/?utm_source=devto&utm_medium=repost&utm_campaign=journal. 18+. Educational content, not betting advice.

One nonce, many numbers: how a provably-fair round draws every card (the cursor, explained)

Betkyo Research — Sat, 12 Sep 2026 07:20:10 +0000

Originally published on the Betkyo Journal, where every figure is read from the game engine's source.

Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

On this site a round’s randomness is HMAC-SHA256(server seed, “client seed-nonce-cursor”). The nonce counts rounds: it goes up by one each bet, across every original, so no two rounds share it. The cursor counts draws inside a round: it starts at 0 and goes up by one for each random number the game needs. A game that needs one number reads cursor 0 and stops. Roulette, Limbo and the lucky bag do that. Sic Bo reads cursors 0, 1 and 2 for its three dice. Bingo reads 0 to 24 to lay out the card and 25 to 62 for the 38 balls. Blackjack reads one cursor per card in deal order, for as many cards as the hand takes. Each cursor gives an independent uniform number, and each game’s published derivation turns those numbers into a pocket, a card or a symbol. Because the whole stream is fixed the moment the seed pair and nonce are, every card of a round already exists before the first one is turned, and after the server seed is revealed you can recompute all of them.

The fourth input

Every explanation of provably fair gaming, including ours, names three inputs: a server seed the house commits to in advance, a client seed you can set yourself, and a nonce that goes up by one with every bet. Feed them into a keyed hash and out comes the round’s randomness. That description is complete for a coin flip. It is incomplete for almost everything else, because a hash produces one number and most games need several.

The fourth input is the cursor. On this site the message that is hashed is not “client seed-nonce” but “client seed-nonce-cursor”, and the cursor is a counter inside the round: 0 for the first random number the game needs, 1 for the second, and so on. Each cursor value gives a fresh 256-bit digest, unrelated to its neighbours in any way you could exploit, and the engine reads the first eight bytes of each digest as a number between 0 and 1.

Verified in source. _shared/demoLocal.ts: uAt(pair, cursor) returns u64(HMAC-SHA256(serverSeed, ${clientSeed}-${nonce}-${cursor})), described as matching the server’s RandomUtils.generateHash(“clientSeed-nonce-cursor”). _shared/rng.ts: u64 reads the first eight bytes of the digest as hi/2^32 + lo/2^64, “the same single-rounding construction” as the server’s ULong→Double conversion. The nonce is one stream per seed pair across all games: each bet consumes the current nonce and stores nonce + 1.

So a round is not one random number but a numbered list of them, as long as the game needs, and every entry on the list is fixed the instant the seed pair and nonce are. The game does not draw as it goes. It reads down a list that already exists.

What each game reads

The interesting part is that the list is different for every game, and each derivation module states its layout in its header. Here is the cursor stream of every original that draws from the seed pair, taken from the engine source.

Cursor use per round, from each game’s derivation module

GAME	CURSORS READ	WHAT THEY BECOME
Limbo	0	One number through the 0.99 ÷ (1 − u) curve
Roulette	0	The pocket: floor(u × 37)
Fukubukuro	0	The item, against the bag’s weight table
Sic Bo	0, 1, 2	The three dice
Chinchiro	side × 9 + attempt × 3 + die	Up to 18: dealer then player, up to three throws of three dice each; a throw that makes a hand ends the side
Koban Flip	one per flip	Flip i reads cursor i; every face of the ride is fixed when the first coin is bought
Omikuji	0, then 1–3, then 4 onward	Fortune tier; the three winning cells on a win; filler glyphs for the rest
Pagoda	one per floor	The trap tile on each floor: floor(u × tiles)
Video Poker	5, plus one per replaced card	One without-replacement sequence over 52 cards; hold everything and no further cursor is read
Casino Hold’em	up to 9	player 1, player 2, dealer 1, dealer 2, flop 1–3, turn, river; the turn and river are only read on CALL
Blackjack	one per card	Infinite shoe, card = floor(u × 52), in deal order: player, dealer up, player, dealer hole, then every further draw
Andar Bahar	0–4, then one per raced card	Two boosted buckets, their magnitudes, the joker, then the race until the rank repeats
Hanabi	15 per spin	Cell = reel × 3 + row; free spin j reads 15 + 15j onward
Bingo	0–24, then 25–62	The card, five draws per column; then the 38 balls

Keno and Crash are the exceptions: their demo rounds use a per-ticket hash chain rather than the seed-pair nonce, described below. Mines and Plinko are settled by the house service; the mines API notes that the whole layout comes off one nonce.

Verified in source. Header comments in bingo/derive.ts (“Cursor stream: 0..24 — the card … 25..62 — the 38 balls”), hanabi/engine.ts (“base spin = cells 0..14 … free spin j = cells 15+15j .. 29+15j”), blackjack/derive.ts (“card i = floor(u × 52) at cursor i … Deal order (cursor): player1, dealer-up, player2, dealer-hole”), vpoker/derive.ts (“the first five are the deal, replacements continue the same sequence … Hold everything and no further cursor is read”), holdem/derive.ts (“player1, player2, dealer1, dealer2, flop1, flop2, flop3, turn, river. The turn/river cursors are only consumed on CALL”), andar/derive.ts (cursors 0–4 then “5.. one cursor per raced card”), koban/derive.ts (“flip i reads cursor i”), sicbo/derive.ts (“cursors 0/1/2 are the three dice”), roulette/derive.ts (“cursor 0 alone decides the pocket: floor(u × 37)”), fuku/derive.ts (“cursor 0 alone draws the item”), omikuji/derive.ts (cursor 0 tier, 1..3 winning cells, 4.. fillers); demoLocal.ts rollSide (chinchiro cursor = side*9 + attempt*3 + d), trapAt (pagoda: the floor number is the cursor), demoLimboBet (uAt(p, 0)); mines/minesApi.ts (“the whole mine layout comes off this one nonce”).

Three things stand out in that table. First, the games that deal cards read one cursor per card in a fixed order, which is why a blackjack hand can be replayed from its action list: your decision to hit does not create a card, it turns over the next one on a list that was complete before the deal. Second, several games stop reading early. A video poker hand where you hold all five cards never touches cursor 5; a Hold’em fold never reads the turn or river. The numbers were there; the game did not need them. Third, the two boosted buckets in Andar Bahar and the fortune tier in Omikuji are drawn before the cards and cells, at the head of the stream, so the round’s special features are fixed by the same commitment as its ordinary ones.

Drawing without replacement

A uniform number between 0 and 1 is easy to turn into a roulette pocket: multiply by 37 and round down. A deck is harder, because the second card must not be the first card again. The engine handles this with what its comments call a pool hop: keep a list of the cards still in the pool, use the cursor’s number to pick a position in it, and swap the chosen card to the end of the list so the next draw picks from one fewer. Video Poker, Casino Hold’em, Andar Bahar and the Bingo card all draw this way, so no card or number repeats within a round.

Blackjack is the deliberate exception. Its shoe is infinite: every card is floor(u × 52) from its own cursor, and the same card can appear twice in a hand. That is a design choice with a published cost, discussed in the blackjack payout article, and it is exactly the kind of thing the cursor layout tells you that a marketing page would not.

Verified in source. vpoker/derive.ts: “Cards come from ONE without-replacement sequence over the 52-card deck (pool-hop, cursor per draw)”. holdem/derive.ts: “ONE without-replacement pool-hop sequence (cursor per draw)”. bingo/derive.ts: “five pool-hop draws per column” and “the 38 balls, pool-hops over 1..75”. blackjack/derive.ts: “Infinite shoe: card i = floor(u × 52) at cursor i”.

The two exceptions

Keno and Crash do not read the seed-pair nonce at all in the demo engine. Keno uses a per-ticket scheme: the ticket gets its own random hash and a salt, and each of the ten balls is drawn by hashing the previous hash again, taking the leading bits as a number and picking from the shrinking pool of forty. The fairness panel verifies a keno ticket from those two strings rather than from the seed pair. Crash follows the bustabit convention, a chain of hashes where each round’s crash point is computed from its own link with exact integer arithmetic.

Verified in source. demoLocal.ts kenoDraws: “per-bet randomHash chain + salt (verifiable per ticket via the fairness modal) … Does not touch the seed-pair nonce”; the loop hashes HMAC-SHA256(salt, previous hash) ten times, reads the leading 52 bits and picks index floor(norm × remaining) from a 40-number pool with a swap to the end. rng.ts h52 and the crash comment: “bustabit crash point in hundredths: floor((n·e − h)/(e − h)), e = 2^52, n = 100 … Exact BigInt math to match the server”.

Neither exception is weaker than the cursor scheme; both are older and better known. What matters for a player is only that the panel shows which scheme a round used, and that each can be recomputed from the strings it shows.

What it means at the table

The round exists before you act. Every card, ball and reel symbol of a round is a function of the seed pair, the nonce and its cursor position. Hitting, calling or holding chooses which entries get read, not what they contain.
Your choices cannot change the list, and neither can the house. Once the server seed is committed and the nonce is fixed, no one on either side can alter entry 7 without altering the seed, which would break the fingerprint you were shown.
A verifier has to read the same list the same way. Recomputing a bingo round means deriving all 63 cursors in the published order; recomputing a Hold’em fold means deriving 7. The seed panel does this in your browser, and the layouts in the table above are what it follows.
A streak is a list, not a mood. Two rounds share nothing but the seed pair; their nonces differ and so every digest differs. This is the same point the hot hand article makes from the other direction.

Three inputs decide the round. The fourth decides how long the round is.

— the cursor, in one line

Note. The cursor layouts above are read from the client-side derivation modules that the browser verifier and the demo engine share. The house service is the paying authority; where a comment in the source says a module mirrors the server, that is quoted as written, not certified by us.

FAQ

What is the cursor in a provably fair round?

A counter inside the round. The message hashed with the server seed is “client seed-nonce-cursor”; cursor 0 gives the first random number the game needs, cursor 1 the second, and so on. A game that needs one number reads cursor 0 only.

How is the cursor different from the nonce?

The nonce counts rounds and goes up by one with each bet across every original. The cursor counts draws within one round and restarts at 0 each round. Together with the seed pair they identify every random number the site ever produces.

How many random numbers does a bingo round use?

Sixty-three: cursors 0 to 24 lay out the 25 cells of the card and cursors 25 to 62 draw the 38 balls, all without replacement within their pools.

Does hitting in blackjack change the next card?

No. Each card is derived from its own cursor in deal order, and the whole list exists once the seed pair and nonce are fixed. Hitting reads the next entry; standing leaves it unread.

Do all games use the cursor scheme?

Keno and Crash use hash chains instead: keno hashes a per-ticket random hash and salt ten times, and crash follows the bustabit chain with exact integer arithmetic. The fairness panel verifies each from the strings it shows.

Sources

Betkyo engine source: _shared/demoLocal.ts (uAt, rollSide, trapAt, kenoDraws), _shared/rng.ts (u64, h52, crash point), and the derivation modules for bingo, hanabi, blackjack, vpoker, holdem, andar, koban, sicbo, roulette, fuku and omikuji
RFC 2104 — HMAC: Keyed-Hashing for Message Authentication — https://www.rfc-editor.org/rfc/rfc2104
Bustabit provably fair scheme (the crash-point construction the engine mirrors)

This article first appeared on the Betkyo Journal: https://betkyo.com/en/blog/one-nonce-many-numbers-what-the-cursor-counts/?utm_source=devto&utm_medium=repost&utm_campaign=journal. 18+. Educational content, not betting advice.

One rounding, not many: why a provably-fair verifier must match the server bit for bit

Betkyo Research — Sat, 12 Sep 2026 07:15:24 +0000

Originally published on the Betkyo Journal, where every figure is read from the game engine's source.

Drafted with AI assistance; every figure was checked against the game engine source and approved by a human editor.

Every provably fair round on this site turns a 256-bit hash into a number between 0 and 1 and then into an outcome. The server does that in Kotlin; the browser verifier does it in JavaScript. Both languages hold numbers as 64-bit doubles with 53 bits of precision, and a hash has more bits than that, so somewhere a rounding must happen. If the server rounds once and the verifier rounds several times, the two numbers can differ in the last bit, and a game that multiplies by 37 and rounds down can land in a different pocket. The engine avoids this by constructing the number as two exact pieces added in one operation: the first four bytes divided by 2³², plus the next bytes divided by 2⁵⁶ or 2⁶⁴, so the only rounding is the single one that Kotlin’s conversion also performs. Crash goes further and never touches a double at all: its crash point is computed with exact integer arithmetic on the leading 52 bits, because a floating-point approximation “would disagree with integer division at floor boundaries and make the verifier reject good rounds”. The verifier is not an approximation of the server. It is the same arithmetic, and that is what makes a rejection mean something.

The trap

A hash is thirty-two bytes. A game needs a number between 0 and 1. The obvious way to get one is to read some of the bytes as an integer and divide by the largest possible value, and every provably fair explainer, including ours, describes it that way. The obvious way has a problem that only shows up when two different programs do it.

Both the server and the browser store ordinary numbers as IEEE 754 doubles: 64 bits, of which 53 carry precision. Seven bytes of hash are 56 bits, eight bytes are 64, and neither fits. So the conversion must lose bits, and the question is not whether it rounds but how many times. A loop that accumulates bytes one at a time, multiplying the running total by 256 and adding the next byte, rounds at every step once the total passes 2⁵³. Kotlin’s conversion of a 64-bit integer to a double rounds exactly once. Two roundings of the same value do not always land on the same double as one.

Most of the time nobody notices, because the difference is in the last bit of a number with sixteen significant digits. Then a game multiplies the number by 37, or 52, or 1,000,000, and rounds down to an integer, and the last bit is exactly the bit that decides whether 36.9999999999999 becomes 36 or 37. A verifier built the obvious way would reject a small fraction of perfectly honest rounds, and a player who saw a rejection would have no way to tell an honest rounding error from a dishonest server.

How the engine steps around it

The fix is to make the browser round exactly as often as the server does, which is once. The engine reads the first four bytes as an integer, which fits in a double exactly, and the next three or four bytes as another integer, which also fits exactly. Each is divided by a power of two, an operation that is exact for doubles. Then the two are added. That single addition is the only place precision is lost, and it loses it the same way Kotlin’s single conversion does.

Verified in source. _shared/rng.ts u56: “first 7 bytes → uniform [0,1), matching the server’s Long→Double rounding bit-for-bit: hi/2^32 and lo/2^56 are both exact dyadic doubles, so the one IEEE addition rounds the 56-bit value exactly once — the same single rounding Kotlin’s toDouble() performs. (A naive 56-bit accumulate in a double would round repeatedly past 2^53 and can differ at floor edges.)” u64 uses the same construction over eight bytes, “matching the server’s ULong→Double conversion in LimboService.outcome100”, and is the function every seed-pair original imports.

How the engine turns bytes into a number, and what each choice protects

FUNCTION	BYTES READ	CONSTRUCTION	MATCHES
u56	first 7	hi ÷ 2³² + lo ÷ 2⁵⁶, one addition	the server’s Long → Double conversion
u64	first 8	hi ÷ 2³² + lo ÷ 2⁶⁴, one addition	the server’s ULong → Double conversion (Limbo)
h52 / bust100	first 6.5 (13 hex digits)	exact BigInt integer arithmetic, no double at all	the server’s CrashDerivation.crashPoint100

Every seed-pair original (bingo, blackjack, hold’em, koban, omikuji, sic bo, video poker, hanabi, fukubukuro, roulette) imports u64 from rng.ts; the generator and the verifier are the same import.

Crash takes the argument to its conclusion. Its crash point follows the bustabit formula, floor((100 × 2⁵² − h) ÷ (2⁵² − h)) where h is the leading 52 bits of the hash, and that division sits on exactly the kind of boundary where a double can be off by one. So the engine does not use a double. It computes the formula with arbitrary-precision integers, in the browser, the way the server does, and the comment in the source says why in one line: a float approximation would disagree with integer division at floor boundaries and make the verifier reject good rounds.

Verified in source. _shared/rng.ts bust100: h = h52(digest), the first 13 hex characters as a BigInt; p = (100·2⁵² − h) ÷ (2⁵² − h) in BigInt division, clamped to [100, 1,000,000]; the comment reads “Exact BigInt math to match the server (NewWhiteBack CrashDerivation.crashPoint100) bit-for-bit — a float approximation would disagree with integer division at floor boundaries and make the verifier reject good rounds.” The BigInt values are built with BigInt() calls rather than literals so the file compiles under the project’s es5 target.

One implementation, two jobs

There is a second, quieter decision in the same file. The functions that turn a hash into a number are not written twice, once for the game and once for the checker. They are written once, in a module the header describes as shared by the generator and the verifier, and the demo engine that plays signed-out rounds in your browser produces its outcomes by calling the same functions the fairness panel calls to check them.

Verified in source. _shared/rng.ts header: “Crypto primitives shared by the provably-fair GENERATOR (demoLocal.ts, the per-game derive modules) and the VERIFIER (fairness.tsx). Extracted from fairness.tsx so a game’s derivation can be imported by both sides without a circular import.” hmacSha256Utf8 is described as consuming key and message “exactly as RandomUtils.generateHash consumes them on the server … one implementation, so the demo can never drift from what the verifier accepts.”

That design has a consequence that is easy to state and worth stating. When the verifier says a round checks out, it is not saying that its own approximation of the server agrees with the server to within some tolerance. It is saying that the same function, given the same inputs, produced the same output, and there is no tolerance because there is nothing to tolerate. When it says a round does not check out, that is not noise. It means the inputs differ, which is the one thing a verifier exists to detect.

A verifier that rounds differently from the server is a verifier that sometimes cries wolf. After the first false alarm, nobody listens to the real one.

— why the rounding matters

What to take from it

“Provably fair” is a claim about arithmetic, and arithmetic has edges. The commitment scheme is the headline; the bit-for-bit derivation is what makes the headline enforceable.
A mismatch should be rare enough to be alarming. On this engine an honest round cannot fail verification because of rounding, so a failure is information rather than an artefact.
You can read the function. The construction is a few lines, and the verification walkthrough shows where each one is used on a live round.

Note. This article describes the client derivation module and quotes its comments about the server it mirrors; the server itself is not in the public repository, and the house service is the paying authority. It is an engineering note, not a certification.

FAQ

Why would a verifier and a server disagree if they use the same hash?

Because turning a hash into a number between 0 and 1 requires rounding to 53 bits of precision, and rounding once does not always give the same result as rounding several times. A verifier that accumulates bytes in a loop can differ from a server that converts once, in the last bit.

Does one bit really matter?

When the number is multiplied by 37 or 52 or a million and rounded down, the last bit can decide which integer results. That is a different pocket, card or item.

How does the engine avoid it?

It builds the number from two exactly representable pieces, the first four bytes over 2³² and the next bytes over 2⁵⁶ or 2⁶⁴, and adds them once, matching the single rounding of the server’s integer-to-double conversion. Crash uses exact integer arithmetic and no doubles at all.

Is the verifier a separate program from the game?

No. The hash and number functions live in one shared module that both the demo engine and the fairness panel import, so the generator cannot drift from the verifier.

What does a failed verification mean here?

That the inputs differ from what the server used, because rounding cannot cause a false failure on this engine. It is the signal the verifier exists to give.

Sources

Betkyo engine source: _shared/rng.ts (u56, u64, h52, bust100, hmacSha256Utf8 and their comments)
IEEE 754-2019 — Standard for Floating-Point Arithmetic (binary64: 53 bits of significand precision)
Bustabit provably fair crash-point formula, the construction bust100 mirrors

This article first appeared on the Betkyo Journal: https://betkyo.com/en/blog/one-rounding-not-many-why-the-verifier-matches-the-server-bit-for-bit/?utm_source=devto&utm_medium=repost&utm_campaign=journal. 18+. Educational content, not betting advice.