Security Model

Protocol guarantees (design)

• Zero-knowledge verification of every state change; nullifiers prevent double spending and double termination.
• Admission reads are pinned to one block and re-checked for canonicality before commit.
• Admission and the prover hand-off record are committed atomically; failures fail closed.
• Matcher and prover are separate: the matcher cannot read prover keys or decrypted private order sections.
• Recovery paths remain available under pause; the guardian cannot seize funds.

Prover keys

• Each epoch has its own key, looked up by its exact epoch ID. There is no latest, current, nearest or try-all fallback.
• A missing epoch key is a terminal rejection; a temporarily unavailable key store is retried and never treated as a missing key.
• Before opening, the prover checks that the secret key corresponds to the public key registered for that epoch.
• Keys of earlier epochs are retained for as long as the protocol lifecycle needs them, including after an early rotation.
• Prover secret storage is isolated from matcher access. In the initial release the epoch keys are stored in the prover database and loaded by the prover process; there is no hardware security module, so compromise of that database or its backups would expose epoch keys.

Verification status

The initial-release candidate has passed its internal release-candidate regression, including a production-shaped end-to-end run from a genuine eligibility proof to an opened order. This is internal engineering verification, not an independent audit.

Before real user funds

• An external cryptographic and security review is required.
• Target-network measurement and recalibration of protocol parameters are required.
• Deployment and operations (hosting, database roles, backups, key handling) are part of the security model and must be verified at deployment.