Verification Methods
These methods describe the supported checks for each game. Use the rules recorded for the completed round and its original pre-wager receipt. Each game has its own calculation.
Inputs and scope
DonutRoyal publishes these methods and the source downloads below. Anyone can inspect the source and reproduce the calculations. This is not an independent third-party audit.
What results mean · Saved receipts · Dice method · Keno method · Mines method · Live games · Card games · Originals · Cases · Arrow · Source downloads
Dice, Keno and Mines use proof version 1; the other listed games use version 2 and standard real-game play using DonutSMP in-game money. Administrator sandbox and demo rounds are excluded. Active seeds, hidden boards and future cards are not disclosed.
What the result means
The checker shows one verdict. Passed (a complete verification) means the saved receipt, result and payout calculation match. Can't fully confirm (incomplete) means evidence is missing; the checker names the reason. Failed means a check found a mismatch.
This checks the round data. It does not confirm payment or certify the whole platform. Demo and administrator sandbox rounds are excluded. Refunds and canceled rounds are not completed payout proofs.
Saved receipts and older rounds
Before a supported wager is sent, your browser attempts to save the round's commitment, rules and wager inputs. After play, the verifier compares that original receipt with the completed proof. A matching seed and hash alone do not establish that the commitment was received before your wager.
This browser keeps receipts for up to 100 rounds per game per account, subject to storage and size limits. Rounds with multiple bets or decisions keep multiple original entries. Export a proof to keep a copy before older receipts are removed. Clearing browser storage can remove receipts; gameplay can continue without one. Downloading a completed proof later cannot recreate a missing original receipt.
Local receipts can be edited and are not independently timestamped. Older rounds may also lack recorded rules. Missing receipts or rules leave verification incomplete. Server proof history has no promised retention period.
Mines checks the final revealed tile set. It does not reconstruct click timing or independently prove the order in which actions reached the server.
Dice inputs
A complete settlement check needs the round identifier, original commitment, revealed server seed, client seed, direction, integer target, wager, recorded roll, recorded payout and supported rules metadata. A round's receipt also binds the wager inputs your browser recorded before sending the wager.
This method uses proof version 1, algorithm version dice-hmac-sha256-v1 and rules version dice-threshold-floor-v1. It applies to standard real-game Dice rounds using DonutSMP in-game money. Administrator sandbox and demo rounds are excluded.
Amounts are whole DonutSMP currency units. Rolls and targets use integers from a 10,000-value scale: a roll of 4,321 displays as 43.21. Avoid floating-point currency arithmetic when reproducing the calculation.
Open the Dice checker. If inputs are missing, the tool reports which checks remain incomplete.
Dice: check the seed commitment
The server seed is represented as a hexadecimal string. Calculate SHA-256 over the UTF-8 bytes of that string, then express the digest as hexadecimal. Compare it with the commitment recorded before the wager.
For this commitment step, hash the hexadecimal text itself. Do not decode it into binary seed bytes first. This is different from the HMAC key encoding in the next step.
If only the completed bundle supplies the commitment, a matching hash shows internal consistency. It does not establish the earlier commitment. A local pre-wager receipt provides an earlier browser record, but is not an independently timestamped certificate.
Dice: reproduce the roll
- Decode the revealed hexadecimal server seed into bytes. Those bytes are the HMAC-SHA-256 key.
- Start the integer counter at zero. The message is the UTF-8 text
clientSeed:0:counter, substituting the exact client seed and the counter's decimal digits. The middle zero is literal. - Read the resulting 32-byte digest in order as eight unsigned 32-bit big-endian integers, at byte offsets 0, 4, 8, 12, 16, 20, 24 and 28.
- Accept the first value strictly below
4294960000. Reject values at or above that threshold. The roll is the accepted value modulo10000. - If all eight values are rejected, increase the counter by one, compute the next HMAC digest and continue in the same order. Counters 0 through 999 are permitted. If no value is accepted, the calculation fails instead of substituting a roll.
The threshold is the largest multiple of 10,000 below 2 to the power of 32. Rejecting the remaining values avoids giving some rolls more accepted inputs than others. The resulting roll is an integer from 0 through 9,999.
The Dice v1 HMAC message does not include the round identifier. The identifier associates the proof with a recorded wager; it must still match the receipt being checked. Client-seed spelling and case must be preserved.
Dice: apply the win condition
For UNDER, the wager wins when roll < target. A roll equal to the target loses. The chance numerator is target.
For OVER, the wager wins when roll >= target. A roll equal to the target wins. The chance numerator is 10000 - target.
The chance is that numerator divided by 10,000. Supported targets run from 200 through 9,800, giving a win chance between 2% and 98%.
Dice: recalculate the payout
Use the house edge recorded for the round. The current standard setting is 300 basis points, or 3%; the rules version supports a recorded edge from 0 through 500 basis points. For a winning wager, the total returned amount is:
floor(wager × (10000 - recordedHouseEdgeBps) ÷ chanceNumerator)
At the standard 300 basis points, this becomes floor(wager × 9700 ÷ chanceNumerator). A rules version alone is not a substitute for the round's recorded edge.
Use integer arithmetic and round down once to whole currency units. This amount includes the original wager. Profit is the returned amount minus the wager. A losing wager returns zero.
This check compares the reported payout with the calculated amount. It does not prove that a wallet credit occurred or that a withdrawal was paid; those require the corresponding transaction records.
For example, with a recorded 300-basis-point edge, UNDER 5,000 and a 100,000 wager has a 50% chance. A roll of 4,321 wins and returns 194,000 in total, giving 94,000 profit. A roll of 5,000 loses. With OVER 5,000 at the same edge, the same roll of 5,000 wins and returns 194,000.
At the standard 3% edge, the 97% theoretical return is a mathematical long-run value before whole-unit rounding. It is not a prediction or promise for any player, round or session.
Keno: draw, matches and payout
The checker reproduces ten distinct numbers from 1 to 40, counts their overlap with the player's selection, then applies the recorded paytable. The current game accepts one to five selections. Full checking also compares the original receipt.
Exact Keno calculation
Algorithm keno-classic-40-hmac-sha256-v1, draw version classic-40-v1, rules keno-hypergeometric-97-floor-v1. Prepared rounds record the pool size, draw count, selection limit, 9700-basis-point target return and the complete integer paytable.
- Hash the UTF-8 hexadecimal server-seed text with SHA-256 and compare the commitment. For Keno HMAC, use that same UTF-8 text as the key; do not decode it to bytes.
- Start with the ascending pool 1 through 40 and counter zero. HMAC-SHA-256 the UTF-8 message
classic-40-v1:gameId:clientSeed:counter, substituting the exact values. - Read only the digest's first unsigned 32-bit big-endian integer. Accept values below
floor(2^32 / remainingPoolSize) × remainingPoolSize. Increase the counter for every attempt, including rejections. - Remove the item at the accepted value modulo the remaining pool size and append it to the draw. Repeat until ten numbers have been drawn; preserve the draw order.
Count matches with the sorted, unique selected numbers. The table stores total-return multipliers in hundredths. Payout is floor(wager × recordedPaytable[selectionCount][hits] / 100), using integer arithmetic.
For selection count n and hit count k, the rules derive each paytable entry from fixed weights w as floor(w[k] × 97 × C(40,n) / sum(w[j] × C(10,j) × C(30,n-j))). C denotes combinations. The published source contains the weights; the checker compares the recorded table with this exact version before accepting a complete verification. Rounding the table down means the actual theoretical return can be below 97%.
Mines: completed board and payout
The checker rebuilds the committed 25-tile board after the round ends, compares the saved revealed tile set, and recalculates a loss or cashout. Active rounds and refunds cannot receive a complete settlement check.
Exact Mines calculation
Algorithm mines-hmac-sha256-fisher-yates-v1, rules mines-combinations-97-floor-v1. Prepared rounds record board size 25 and house edge 300 basis points. Hash the UTF-8 server-seed hexadecimal text with SHA-256 to check the commitment; decode that hexadecimal seed into bytes for the HMAC key.
- Initialize a tile list containing 0 through 24. For each end index from 24 down to 1, begin the attempt counter at
24 - end. - HMAC-SHA-256 the exact UTF-8 message
clientSeed:gameId:end:attempt. - Scan the digest's eight unsigned 32-bit big-endian words in order. Accept the first below
floor(2^32 / (end + 1)) × (end + 1). If all words are rejected, increase the attempt counter and try again, for at most 10,000 attempts at that end index. - Swap the tile at end with the tile at the accepted value modulo
end + 1. The first mineCount tiles of the completed permutation are the mines; sort their indices for comparison with the proof.
A lost round must contain exactly one revealed mine and fewer than all safe tiles, and pays zero. Revealing all safe tiles automatically cashes out. A cashout must contain at least one safe reveal and no revealed mine. For m mines and k safe reveals, total payout is floor(wager × 97 × C(25,k) / (100 × C(25-m,k))). Use integer arithmetic; winning payouts include the original wager.
The saved revealed indices are a sorted set, not an action timeline. This verifies the final board, tile classifications and payout calculation, not click order, cashout timing or delivery of wallet credits.
Roulette, Royal Wheel and Crash
These games commit a server seed before betting closes. The checker reproduces the outcome, compares each of your retained bet receipts and recalculates each return under the recorded rules.
Live-game calculations and limits
Roulette hashes the UTF-8 text roulette:serverSeed with SHA-256, reads the first unsigned 32-bit big-endian word and takes its remainder modulo 38. Pockets 0 and 37 are green. Red and black return 2 times the winning stake; green returns 14 times. This existing modulo mapping has a small bias. The nominal return is approximately 94.74% on red or black and 73.68% on green; there is no single site-wide return rate.
Royal Wheel uses its version 2 HMAC-SHA-256 draw with rejection sampling. Its 25 nonzero segments have weight 47 each and the zero segment has weight 25, giving total weight 1,200. Winning selections 1, 3, 5, 10 and 20 return 2, 4, 6, 12 and 24 times the stake respectively. Each has 94% theoretical total return before currency rounding. The source specifies the segment order and exact HMAC messages.
Crash hashes crash:serverSeed with SHA-256. Let U be the first 52 bits and E be 2 to the power of 52. The crash point in hundredths is max(100, floor(97 × E / (E - U))). The checker also compares the recorded growth rate, flight duration and cashout rules. An automatic cashout must precede the crash. Manual cashout checks use the recorded time; they cannot independently establish when the player clicked or when the server received it.
Shared-round exports include only the owner's wagers. Missing, unmatched or oversized wager evidence remains incomplete. Matching calculations do not independently authenticate the server clock.
Blackjack, Hi-Lo, Baccarat and Coin flip
The checker reconstructs cards or the winning side from the revealed seed, then follows the retained decisions and payout rules. No future cards are exposed while they remain playable.
Card-game calculations and limits
Blackjack preserves its eight-deck HMAC shuffle and modulo selection algorithm. It is not rejection sampling. The checker deals the initial hands and replays HIT, STAND, DOUBLE and SPLIT, including the dealer hitting soft 17, a natural returning 2.5 times the stake, two hands at most, and the recorded split-aces rule.
Hi-Lo uses HMAC with rejection sampling for ranks and suits. The proof retains the full supported skip and guess sequence, even when the game displays only recent actions. Each successful guess multiplies the exact return ratio by 1261 / (100 × winningRankCount); payouts round down to whole units. A carried face-up starting card is compared with the original receipt rather than represented as newly derived from the current seed.
New Baccarat shoes use a committed eight-deck shuffle, burn and cut rules. The checker replays the shoe at the position observed before betting and applies the third-card rules. Player returns 2 times the stake, banker 1.95 times and tie 9 times; non-tie bets push on a tie. Undo requests must match retained original entries. The seed is revealed only when the shoe retires, so a settled hand can remain incomplete until then. This does not independently prove the chronology of every other hand in the shoe or delivery of a refund.
Coin flip uses a committed HMAC draw over two sides. The host and joining player can each retain the same original commitment; the winner's total return is floor(stake × 19 / 10). A fixed domain string separates the draw; this game does not claim a player-selected randomness contribution.
Limbo, Plinko and Towers
New rounds commit their seed before your browser chooses a client seed and submits the wager. The checker reconstructs the outcome using HMAC-SHA-256 and rejection sampling, then checks the saved rule snapshot.
Original-game calculations
Algorithm originals-hmac-sha256-rejection-v2 uses decoded seed bytes as its HMAC key and the exact UTF-8 message game:gameId:clientSeed:label:counter. Each draw reads the first unsigned 32-bit big-endian word and rejects values outside the largest multiple of its range below 2 to the power of 32. The source publishes each label and counter rule.
Limbo draws an integer R from 1 through 1,000,000,000. Its result in hundredths is max(100, floor(97000000000 / R)). Reaching the requested target pays floor(stake × targetCents / 100); otherwise the payout is zero.
Plinko derives one left-or-right bit per row, sums the path into the final slot, and applies the recorded risk and row table. Multipliers are integer millionths; payout is floor(stake × multiplierUnits / 1000000).
Towers derives all eight rows before the first decision. Its hidden board is revealed only after a loss or cashout. The checker compares each saved tile request and any cashout with the resulting transcript. With C columns, S safe tiles and k completed rows, a successful cashout returns floor(stake × 97 × C^k / (100 × S^k)). A loss returns zero.
Cases and Case Battles
Proofs retain the item catalog and weights used for the round, so later catalog edits cannot silently replace the original calculation.
Draw and settlement checks
New prepared case openings use case-sha256-client-mod10000-v2. Hash the UTF-8 text serverSeed:itemId:clientSeed with SHA-256, read the digest as an unsigned integer and take its remainder modulo 10,000. Compare the roll with the cumulative recorded item weights. This modulo mapping is preserved explicitly; the checker does not call it rejection sampling. Each opened item has its own proof ID and receipt.
Case Battles replay the seeded item draws for each anonymous seat against the saved catalogs, then calculate totals, mode rules, ties, teams, crazy or terminal options and borrowed-stake adjustments. The owner's receipt must match the settings seen before creating or joining the room. Matching item values does not establish that a wallet credit was delivered.
Arrow Game: recorded-event checks
Arrow uses physical server events rather than a seeded draw. Its checker compares the round and arrow identifiers, launch and hit records, recorded wager-lock hash, event hash and your wager returns. Green returns twice the stake; red returns zero.
These consistency checks cannot independently authenticate the event source, establish that a physical collision happened, or prove board probabilities. Even matching records leave full verification incomplete. An event hash is not a substitute for independent observation.
Verifier source and examples
Standalone verifier for all listed games
Dice example · Keno example · Mines example
Examples are synthetic test data, not player wagers or evidence of historical results. The source performs calculations independently of the game server.
The standalone module includes every listed checker and makes no network calls. Use its verifyAllGameProof(proof, originalReceipt) export in a JavaScript environment with Web Crypto. File size and transcript limits keep malformed inputs bounded.
Rules versions and evidence limits
A rules version identifies the calculation used for a round. New supported records capture metadata when the commitment is prepared. An older record without supported rules metadata cannot receive a complete settlement verification by substituting the current rules.
A complete computational match means the supplied inputs reproduce the recorded result under the supported method. An original receipt adds comparison against what the browser recorded before the wager. Neither is an external audit, a guarantee of future results or proof that every possible operational issue is excluded.
Retrieving a private round's proof requires its owner to sign in. Anyone with a saved proof can use the public paste verifier. Keep proof data you intend to share separate from account sessions or other private account information.
Verification scope and limits · Report a disputed result · Responsible play