Security and trust boundary
Public verifiability and robustness are different axes. This stack is publicly verifiable: anyone can check the winner was the minimum and the settlement conserved value. It sits on rung 1 of the accountability ladder in the deployed engine: a deviation is detected and the protocol stops. Saying both halves is the point of this page.
source: zkpi/ACCOUNTABILITY.md, qomm/BINDING.md, oclob/docs/THREAT_MODEL.md, defmi/ZKPI_WIRE.md, defmi/REVIEW.md
Adversaries
- An operator or ordering node that reads an order and reorders around it.
- An MPC node that steals shares, computes the wrong thing, or halts only when the result is unfavourable.
- A participant that spends the same reservation twice, refuses to settle after seeing the result, or replays.
- A holder that moves a DeKYX credential to another market or period.
- A submitter that sends DeFMI a stale root, another market's asset or an altered instruction.
- An outside observer with the public book, the fills, traffic volume and timing.
- A party holding a commitment long enough to break the discrete log.
Committee parameters
The accountability ladder
Take a protocol where one of the seven nodes deviates. What can the rest of the world end up knowing?
| rung | what it gives | needs |
|---|---|---|
| 1. security with abort | the output is right, or there is no output | dishonest majority is fine |
| 2. identifiable abort | …and the honest parties learn who | dishonest majority is fine |
| 3. publicly identifiable abort | …and so does anybody reading the transcript | a bulletin board |
| 4. public accountability | …and a judge reaches a verdict from the transcript alone | a bulletin board |
| 5. robustness | there is no abort; honest parties get the output regardless | honest majority |
Where each mechanism sits, honestly separated because the repositories once called all of them "attribution":
- The dealt share: rung 4, at the boundary only. The maker signs each dealt share, so a node that later claims a different share can be shown to have done so by anyone. Scope is one message, not the protocol.
- What the node feeds the engine: rung 0 in the transport, now checkable in the circuit. The per-party input check names the node that fed a value other than the one it was dealt, for one extra round. An earlier version derived its coefficients from commitments a node could read first, and writing the proof found that a node could choose an error in their kernel; the challenge is now drawn after the input phase. A verdict is not a repair.
- The MPC itself: rung 1. MP-SPDZ's malicious security means deviation is at least detected. Detected, not attributed, not survived.
- Robust reconstruction: rung 5, built and run at nine nodes. At n ≥ 4t+1 the shares are a Reed–Solomon code whose degree-2t product is directly correctable, so a Berlekamp–Welch decoder replaces segmenting, checkpoints and player elimination. Measured on two machines with two independent builds: the correct answer with the culprits named under one and two liars, without stopping, at 18.2 elements per party per multiplication against the 64.2 the deployed engine spends. What is not robust: the preprocessing, the double sharings, the output opening and the input phase. The input phase is the one that matters, and it costs two more institutions.
- The quote proof is on the other axis. If it fails you know the answer was wrong. You do not know which node made it wrong, and you do not have an answer.
The accountability page has the full argument: the Reed–Solomon decoder in the engine, rung 5 at nine nodes, what dishonest majority would cost, and the taker as a misbehaving party.
What validators verify, and do not
The product transaction carries the complete submitted evidence. Every Avalanche validator independently checks: the 3-of-7 Ed25519 approval, the typed zkPI, the complete quote proof, both jointly assembled range proofs, the taker's price limit, the asset link, the DvP relation, chain and rail domains, deadline, sequence, previous state root and nullifier, before applying the transition atomically.
Anonymity is other people's traffic
Two measurements say the same thing from different sides. A note ring with no other settlements around it names its note with certainty at every ring size, because the newest note is the one being spent and no decoy can be newer. An adaptor-signature PvP with one swap in flight names its partner leg with certainty. Both constructions hide you in other people's traffic and neither does anything without it. What differs is the exchange rate: how much traffic each needs to buy a given amount of doubt. The recency-matched decoy rule reaches the nominal 1/R at sixteen settlements of traffic; the per-venue handle reaches 1/k at k swaps in flight. And the PvP observer was given no timing; a real one watching prepares arrive does better.
The commitment that must open many times
A maker's policy commitment is not opened once. It sits for the life of the policy and is opened against every quote, and the mechanism is an auction. Rivinius et al. point out that computational binding decays over the life of a commitment: a party who eventually breaks the discrete log can shift another party's input undetectably, and "in an auction, this could be used to reduce other parties' bids". That is this stack's exact shape and it is the strongest argument in the literature for a post-quantum commitment here specifically: it does not need a quantum computer, only enough time.
The measured alternatives: VOLE-in-the-Head commitments rest on a random oracle only but are one-time (Δ is public after the first opening), and an RFQ cannot queue openings because the coefficients depend on a request that has not arrived; lattice (BDLOP) commitments reopen freely at kilobytes each. The open question, stated on the prior-art page, is a random-oracle-only commitment over F_p that opens many times.
The signature and key-exchange half of that question has a migration under way: hybrid Ed25519 + ML-DSA-65 and X25519 + ML-KEM-768 across all eight repositories, accepted on one host and merged to main in all eight repositories on 2026-09-07. The post-quantum page has the status, the sizes and what stays classical.
What is deliberately not in the trust boundary
Trusted execution environments. The CPU manufacturer's attestation key, the enclave implementation and microarchitectural side channels are not added to the boundary. OCLOB's threat model says so explicitly against Tesseract-style designs; the same stance holds across the stack.
Not defended
- Three or more colluding MPC nodes reconstructing secrets.
- A compromised participant terminal.
- Inference from the public per-level book: a level with one participant leaks that participant's size through deltas.
- Inference from published fills: a large order's existence can be guessed.
- Network-level metadata: IP addresses, connection times, resend intervals, packet counts. No anonymity network is included; the fixed cadence and relay hops hide whether a slot was real, not who is connected.
- Market manipulation, spoofing, or off-market price manipulation. Cryptography does not adjudicate those.
- Guaranteed liveness under total node failure or partition. The design fails closed: no plaintext fallback, requests wait in an encrypted durable queue.
- The sender knowing what it sent, and linkage from timing, candidate sets, venue and reservation metadata.
- An in-memory rate limiter that resets on restart and does not compose across instances, recorded in the review beside the sentence that called it the only defence.