> ## Documentation Index
> Fetch the complete documentation index at: https://aceup.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 fairness screen: three numbered steps with the commitment, the revealed seed, and the three green checks.](https://mintcdn.com/aceup/9Or0tHJTM0oGeA8-/images/screens/fairness.webp?fit=max\&auto=format\&n=9Or0tHJTM0oGeA8-\&q=85\&s=3ef5c02f6ecec846c025210fe788f438)

## 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.

> [!NOTE]
>
> 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](https://aceup.mintlify.site/play/rules.md). Nor does it stop
you losing. A fair shuffle is still a shuffle.

## Related

> [card] [Verify a round](https://aceup.mintlify.site/fair/verify-a-round.md)
>
> Step by step, on a hand you actually played.

> [card] [Your client seed](https://aceup.mintlify.site/fair/client-seed.md)
>
> The part of the shuffle that is yours.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.