ZKP Commitment Guarantees
The buy flow binds zero-knowledge custody proofs to contract issuance, ensuring that every contract is cryptographically tied to a specific buyer, seller, and witness state from the moment it is created.
Bound Proof Tuple
When a buyer issues a contract, three cryptographic fields are submitted together:
| Field | Description |
|---|---|
witness_proof |
Public commitment that binds custody to the specific contract ID |
encrypted_witness_secret |
The custody secret, encrypted specifically for the seller's public key |
witness_zkp |
A signed commitment hash that proves the buyer's identity is bound to the proof |
These three fields form an immutable tuple recorded at contract creation. They cannot be altered after submission.
Verification Goals
The proof tuple enables four verification checks:
Contract ID consistency
The witness_proof is bound to the contract ID. Any attempt to reuse the proof for a different contract will fail verification.
Commitment hash integrity
The witness_zkp contains a hash over the proof and secret. Tampering with either value invalidates the hash.
Signer binding to buyer identity
The ZKP signature proves that the buyer's registered identity created the commitment. A third party cannot forge a valid proof without the buyer's private key.
Seller-targeted secret integrity
The encrypted_witness_secret is encrypted with the seller's public key. Only the designated seller can decrypt it, preventing unauthorized custody claims.
Non-Repudiation Checkpoints
The contract lifecycle records four immutable checkpoints that prevent any party from denying their actions:
| Checkpoint | Action | What is recorded |
|---|---|---|
| Buy | POST /api/arbitration/contracts/buy |
Immutable witness commitment with buyer signature |
| Accept | POST /api/arbitration/contracts/{id}/accept |
Seller acceptance with cryptographic signature proof |
| Replace | POST /api/witness/replace |
Witness state transfer proving ownership handoff |
| Deliver | POST /api/arbitration/contracts/{id}/deliver |
Delivery proof requiring currently valid seller-held witness secret |
Together, these checkpoints make it impossible for either party to deny acceptance, custody transfer, or delivery after the fact.
Security Properties
- Forward secrecy of custody -- each custody rotation produces a fresh secret, invalidating the previous one
- Bilateral binding -- both buyer and seller identities are cryptographically linked to the contract
- Tamper evidence -- any modification to the proof tuple is detectable via hash verification
Related
- Bid Lifecycle -- the contract state machine these proofs protect
- End-to-End: Raw API -- how to construct proof fields in HTTP calls
- End-to-End: Wallet CLI -- the CLI generates proofs automatically
- Error Semantics -- error responses for invalid proofs