Provably fair

How Ace Up commits to a shuffle before it deals, and why that is checkable.

“Provably fair” means one specific thing: the shuffle is fixed before any card is dealt, in a way that can be proved afterwards, and the proof does not require trusting Ace Up.

The three steps

1. Commit — before the deal

   The server generates a random 32-byte server seed and publishes SHA-256(serverSeed). That hash is the commitment, and you can see it while the round is still live.

   A hash cannot be worked backwards, so the commitment tells you nothing about the shuffle. But the server can no longer change the seed without the hash failing to match.

2. Deal

   The shoe is derived from three inputs:

   • the server seed (secret until the round ends)
   • your client seed (yours, and visible to you the whole time)
   • the round’s nonce (a counter)

   Those three drive an HMAC-SHA256 keystream, which drives an unbiased Fisher–Yates shuffle of a fresh 312-card six-deck shoe. Same inputs, same shoe, every time.

   The shoe is never stored. It is re-derived when needed, which is why there is nothing to tamper with between the deal and the settlement.

3. Reveal — after settlement

   The server seed is published. Now anyone can:

   1. hash it and check it equals the commitment from step 1
   2. re-run the derivation and check it produces the exact cards that were dealt

What you actually see

On a verified round you get three checks:

HASH ✓ · SHOE ✓ · 312 CARDS MATCH ✓

• HASH — the revealed seed hashes to the commitment that was published before the deal.
• SHOE — the derivation reproduces the shoe.
• CARDS MATCH — every one of the 312 cards is in the position the round dealt from.

The check runs in your browser

This is the part that matters. The verification is not the server telling you it was fair — the Mini App and the public verify page carry their own implementation of the shuffle, in WebCrypto, and re-derive the shoe locally.

The server is never asked to vouch for itself.

The browser implementation and the server implementation are tested against each other on every build: they must reproduce the same 312 cards on unlike seed sets and produce the same commitment hash. If they ever diverged, the build would fail.

What this does and does not prove

It proves the cards dealt in a round came from a shoe fixed before the deal, and that nobody changed them mid-hand to your disadvantage.

It does not prove the house edge is what we say it is — that is a property of the rules, measured by simulation and printed. Nor does it stop you losing. A fair shuffle is still a shuffle.

Related

Verify a round

Step by step, on a hand you actually played.

Your client seed

The part of the shuffle that is yours.