# Reveal Fairness

Pack reveal fairness is ensured through a transparent commit-reveal protocol with Merkle inclusion proofs. This is a verifiable commitment system, not a zero-knowledge proof.

## Protocol

```mermaid
sequenceDiagram
  participant Server as Numex Server
  participant Buyer
  participant Chain as Base Registry

  Note over Server: Before sale
  Server->>Server: Generate serverSeed
  Server->>Server: Build Merkle tree from pool items
  Server->>Chain: Commit poolId + Merkle root + seedCommitment
  Note over Server,Chain: Pool is now committed

  Note over Buyer: At purchase
  Buyer->>Server: Buy pack, provide buyerNonce
  Server->>Server: revealSeed = SHA-256(serverSeed:buyerNonce:packId)
  Server->>Server: selectedIndex = hash(revealSeed) mod poolSize
  Server->>Server: selectedItem = sortedPool[selectedIndex]
  Server->>Server: Generate Merkle inclusion proof for selectedItem
  Server->>Buyer: Return proof + reveal serverSeed

  Note over Buyer: Verification
  Buyer->>Buyer: Verify seedCommitment matches SHA-256(serverSeed)
  Buyer->>Buyer: Recompute revealSeed and selectedIndex
  Buyer->>Buyer: Verify Merkle inclusion of selectedItem in committed root
  Server->>Chain: Record openingId + revealHash + outcomeHash
```

## What Each Check Proves

| Check                   | What It Proves                                                          |
| ----------------------- | ----------------------------------------------------------------------- |
| Seed commitment         | Server committed to the seed before seeing the buyer nonce              |
| Deterministic selection | The selected index follows deterministically from seed + nonce + packId |
| Merkle inclusion        | The selected coin was a member of the committed pool                    |
| Chain anchor            | The commitment and outcome are recorded immutably                       |

## What This Does Not Prove

* **Pool completeness:** The verifier trusts that the committed Merkle root represents the actual pool. If the server builds a tree with different items, the root would differ, but the verifier needs the expected root to compare against.
* **Pool fairness:** The odds distribution within the pool is a product decision, not a cryptographic guarantee. The Merkle tree proves membership, not probability.
* **Server seed entropy:** The commitment proves the seed was fixed before reveal, not that it was generated with sufficient randomness.

## Hash Functions

All reveal fairness operations use SHA-256:

* `commitServerSeed(seed) = SHA-256(seed)`
* `computeRevealSeed(seed, nonce, packId) = SHA-256(seed:nonce:packId)`
* `computeSelectedIndex(revealSeed, poolSize) = BigUInt64BE(SHA-256(revealSeed)) mod poolSize`
* Merkle leaf: `SHA-256(itemId)`
* Merkle internal: `SHA-256(sortedPair(left, right))`

See [Hash Conventions](/numex-docs/technology/hash-conventions.md) for why this differs from on-chain keccak256.

## Adversarial Coverage

The verification script (`npm run verify:reveal-proofs`) runs 19 tests including:

* Wrong server seed, buyer nonce, pack ID, and selected item all fail.
* Tampered Merkle paths and roots fail.
* Replay attacks against different packs fail.
* Empty pools are rejected.
* Duplicate pool items produce consistent (documented) behavior.

## Current Limitations

* **Off-chain only:** Merkle verification happens in TypeScript. The contracts anchor the root and outcome as opaque `bytes32` values but do not re-verify paths on-chain.
* **Not ZK:** All inputs are visible to the verifier. See [ZK Roadmap](/numex-docs/zero-knowledge-proofs/zk-roadmap.md) for planned privacy features.
* **Demo odds are static:** Pull probabilities are not dynamically rewritten when coins are removed from a pool. This is a product decision documented in pack configuration.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://numex-greenfield.gitbook.io/numex-docs/technology/reveal-fairness.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.