How it works

Nonce ledger

The ledger issues one-use nonces and spends them before twin validation. Ordering is the mitigation, not the burn alone.

A nonce_uuid is reserved when an envelope is prepared. At the gate, the nonce is burned before validate-proof. If the nonce was already spent, the request rejects at the nonce stage. If twin validation later fails, the nonce is still spent, an attacker cannot use failed validation as a free probe, and concurrent duplicates cannot race between check and validate.

That is why a captured envelope is a fossil: possession of the bytes does not authorize a second spend of the same nonce. Fresh authority requires a new reserve and a new proof.

Ordering (conceptual)

// Gate path (simplified)
assert request_hash matches recomputed binding
assert endpoint_id / policy_hash / anchor / freshness
burn(nonce_uuid) // BEFORE validate
validate_proof(twin) // expensive check second
apply application policy
perform side effect

Production deployments earn the absolute replay claim under a durable ledger, see the reference architecture. Demo packs may use in-process burn sets for teaching; that is an ops difference, not a change to the envelope contract.

Mechanism claims

The nonce is burned before twin validation, so a failed or replayed submission cannot be spent twice.ShippingGate order spends nonce_uuid prior to validate-proof; spent nonces reject at the nonce stage.Holds under the reference architecture

Authority expires at the end of the request (a captured envelope is a fossil, not a reusable credential).ShippingOne-shot nonce plus request binding; capture does not authorize a second call.Holds under the reference architecture