Security model

Security assumptions across the Core program, circuits, SDK, prover, NoteStore, RPC and relayer boundaries.

The release's security boundary spans on-chain state validation, proof verification and user-side custody. A successful proof is necessary, but it does not eliminate setup, deployment, storage or metadata trust.

Cryptographic and on-chain controls

Groth16 circuits over BN254 prove note authorization, Merkle membership, nullifier derivation and swap/withdrawal constraints.
Poseidon hashing binds note, owner and nullifier fields and builds the Merkle tree.
Core recomputes public inputs, checks live root sequence/generation, derives canonical PDAs, verifies the proof and initializes a one-time spent-nullifier account.
Classic SPL Token account/mint identities and public pool/custody account bindings are checked before settlement.

Trust boundaries

Boundary	What is trusted / protected
Trusted setup	Single-party toxic-waste non-retention/non-compromise assumption.
Wallet and NoteStore	Seed, spend secret, randomness, journal and backups remain confidential and available.
Prover binary/PK	Exact authenticated release artifacts and local environment are trusted.
RPC provider	Availability and privacy metadata; Core remains the state-transition authority.
Relayer	Public transaction handling and fee-payer key operations; it receives no note witness by design.
Upgrade/deployment operations	Upgrade authority and operational controls remain external trust boundaries.

The controlled Devnet release gate records zero known unresolved critical, high or medium findings in that gate's scope. This is not an independent external audit or a Mainnet safety certification. The relayer has not been independently audited.

See Trusted setup, Relayer security, Note security and Known limitations.

Source baseline: frozen Core v0.1.0 / SDK v0.1.1.