What the system guarantees
No forged eligibility
You cannot produce a valid proof without a genuine credential secret whose commitment is in the approved root. Enforced by the circuit; verified on-chain.
No replay
The nullifier and
action_id are consumed on-chain. The same proof cannot authorize a second action.No action substitution
The proof binds to
context_hash; the contract recomputes it from the submitted action. Change the recipient, amount, asset, contract, or network and the proof no longer matches.No stale access
Rotating the approved root and version rejects proofs bound to an old root. Disabled and expired policies reject all execution.
Trust boundaries
What Nullis does NOT protect against
Stating these limits is deliberate. A privacy claim you can’t bound is a privacy claim you can’t trust.The claim-safety invariant
The core security invariant is the circuit/contract split: privacy-critical statements are proven in zero knowledge; public policy parameters are enforced in the clear. Nullis never attributes a contract check to the circuit or vice versa — in code, docs, or UI. That mismatch is the single easiest thing for a reviewer to reject, so the boundary is held everywhere.Roadmap hardening
- In-circuit sparse-Merkle non-membership revocation (removes the witness-refresh cost).
- Multi-issuer governance (removes the single-issuer trust assumption).
- Mainnet deployment and a formal security audit.
None of the roadmap items are claimed as shipped. See the honesty table for the exact real-vs-roadmap line.