AZENYX

ZERO-KNOWLEDGE

Proof System

Role of zero-knowledge proofs

Every state-changing action on a private note is authorized by a zero-knowledge proof. A proof has public inputs, which the verifier and everyone can see, and a private witness, which never leaves the party that creates the proof. On-chain verifier contracts check proofs before the pool changes state; the matcher checks the eligibility proof against the same on-chain verifier before admitting an order.

Proof families

  • Custody: deposit, spend and withdraw of shielded notes (membership in a known root, nullifier derivation).
  • Escrow opening: moving a note into escrow for an order.
  • Eligibility (ELIGIBILITY_V2): admission of an order to the matcher.
  • Settlement: batch settlement of matched orders.
  • Terminal and recovery paths: cancel intent, reclaim and emergency escrow exit.

ELIGIBILITY_V2

  1. Client proves eligibility and builds the protected order payload
  2. ↓ Matcher verifies the proof and its public inputs, then admits
  3. ↓ Private prover later opens the protected private section

The proof binds the order to a ring root of the pool, to the registered market configuration and policy versions, to the current epoch and its registered public key, and to a hash of the encrypted payload. A payload that does not match the proof-bound hash is rejected.

Protected order section (CS-4)

The private section of an order is protected by a protocol-specific verifiable-encryption construction with explicit integrity and context binding; it is not a standard AEAD:

  1. Grumpkin ECDH with the registered epoch public key
  2. ↓ Domain-separated Poseidon2 key derivation
  3. ↓ Poseidon2 field keystream encryption
  4. ↓ Explicit integrity tag and context binding (chain, pool, epoch, order)

Because the construction is expressed over the proof field, the eligibility proof can attest that the payload is well-formed for the registered epoch key. Security rests on the published construction and its keys, not on secrecy of the design. The construction is custom and is part of the external cryptographic review required before real user funds.

Concepts

  • Domain separation: every hash use has its own domain tag.
  • Context binding: ciphertexts and proofs are bound to chainId, pool, epoch and order identity.
  • Ring and root membership: normal paths accept only recent ordinary roots.
  • Nullifiers: each note and each escrow can be consumed once.