Order & Settlement

Order lifecycle

1. Client opens escrow from a shielded note and prepares the order
2. ↓ Client produces the eligibility proof and encrypted payload
3. ↓ Matcher admission (proof, market, policy, epoch and root checks)
4. ↓ Durable admission + prover hand-off
5. ↓ Prover opens the private section → OPENED
6. ↓ Matching and batch settlement, or a terminal exit

Admission checks

• The eligibility proof verifies against the frozen on-chain verifier.
• The Merkle root is a recent ordinary (ring) root of the pool.
• The market configuration hash and the fee and scale policy versions are registered.
• The epoch is the current epoch and its public key matches the registry.
• The order has not expired.
• The orderTag has not been admitted before (duplicate protection).

Snapshot and canonicality

1. Capture one block snapshot (number and hash)
2. ↓ Perform every admission read at that same block
3. ↓ Re-check that the block is still canonical
4. ↓ Commit admission + prover hand-off

If the chain reorganizes the snapshot block, an RPC read fails or the database is unavailable, admission fails closed and nothing is committed. A newer block is never mixed into an attempt; a new submission takes a new snapshot.

Settlement and terminal consumption

Matched orders settle in batches verified on-chain. Settlement, cancel-reclaim, expiry-reclaim and emergency exit each consume the escrow’s terminal nullifier, so an escrow ends exactly once.

Retries

Hand-off to the prover is retried on transient failures with the same orderTag; deterministic rejections are final; an admitted order is never admitted twice.