ACE21 / BEHIND THE CARDS
SHOW THE HAND.KEEP THE RECEIPTS.
A recorded hand should be checkable. Follow how live on-chain play commits to a shoe, reveals the seeds, and leaves a game log you can replay.
- COMMITRecord the fingerprint
- PLAYKeep the event log
- REVEALRebuild and compare
A HAND. A LOG. A CHECK.
A trail you can check.
A commitment is a fingerprint of the hand’s inputs. After the server reveals its seed, those inputs can be used to rebuild the shoe and compare the recorded result.
Commit before the deal
The live contract records a hash tied to the server seed, client seed, hand ID, rules version, and shoe hash before play.
Rebuild the shoe
The same revealed seeds and hand ID produce the same six-deck order. The recorded cards can be compared with that order.
Follow the events
The transcript records deals and actions. Linked state hashes and a Merkle root help check that the published event log matches its recorded fingerprint.
Recalculate the result
Replay the hand under its recorded rules, then compare the computed payout with the contract’s settlement data.
The free practice table runs in your browser with virtual credits. It does not create a chain transaction or a public proof. Demo-mode records also do not establish a live on-chain settlement.
From deal to receipt.
Here is the intended flow for a live on-chain hand.
Prepare the commitment
The server generates a secret seed and derives the shoe using that seed, your client seed, and the hand ID. It commits to those inputs, the rules version, and the shoe hash.
Record the wager
The live contract records the commitment and locks the wager before cards are shown. This recorded commitment is the reference for the later reveal.
Play the hand
The off-chain engine deals from that shoe and records deals and moves as events. Live wagers, including added split and double wagers, use wallet-authorized transactions.
Reveal and settle
The operator submits the server seed, shoe hash, result, payout, event-log root, and transcript reference. The contract checks the commitment and payout bounds before transferring any payout.
Replay and compare
With the transcript and chain record, a verifier can derive the shoe again, compare cards and event hashes, replay the rules, and check the payout.
Check the receipts.
A full check needs both the game transcript and the matching live-chain record. A result label alone is not verification.
Match the hand
Use the same hand ID, player, chain, and contract address for the transcript and settlement record.
Check the commitment
Recompute the hash of the revealed seeds, hand ID, rules version, and shoe hash. Compare it with the commitment recorded at the start.
Rebuild the cards
Derive the shoe from the revealed server seed, client seed, and hand ID. Compare the ordered cards and the positions consumed by each deal.
Compare the log
Check the linked state hashes and rebuild the Merkle root from the events. Compare the root with the settlement record.
Replay the outcome
Replay the game under the recorded rules. Compare the resulting payout with the actual on-chain payout.
The bank page shows the current mode and available contract information. Contract balance and fee totals describe the bank; they do not verify an individual hand.
Open the cabinet.
Expand a component for the technical details behind the flow.
01 / Seeds and the shuffle
The engine uses a deterministic Fisher–Yates shuffle. Its master seed is derived from the server seed, client seed, and hand ID.
keccak256(serverSeed ‖ clientSeed ‖ handId)The commitment also includes the rules version and the hash of the complete shoe.
02 / Randomness inputs
Server-seed generation mixes local randomness with a drand beacon response when available. If the beacon cannot be reached, the implementation falls back to local entropy.
That input alone does not prove the operator could not choose among seeds before committing. Commitment checks address consistency with the recorded hand, not every possible source of bias.
03 / The engine and contract
The off-chain engine runs blackjack. The contract records the commitment, checks its reveal, enforces payout bounds, and stores settlement references. It does not replay every blackjack action during settlement.
Independent replay is needed to compare the reported payout with the game rules. The current operator remains responsible for submitting the result.
04 / Transcripts and storage
The transcript contains seeds, rules, shoe order, events, and the result. When IPFS publishing succeeds, the settlement reference can be used to retrieve it.
If publishing is unavailable or fails, the current implementation can produce a placeholder reference. A placeholder is not a retrievable IPFS proof, and the complete transcript is still needed for independent replay.
What a proof can tell you.
The recorded hand
Whether the revealed inputs match the commitment, the cards match the derived shoe, the event log matches its root, and the replayed payout matches settlement.
Every other risk
A winning outcome, future bankroll availability, absence of pre-commit seed selection, or freedom from software and operator errors. Verification is not a guarantee of profit or a security audit.
Read the table rules and responsible play guidance before choosing USDC play.