Security overview

A proof is one control. Safe withdrawal also requires the browser, proving files, public inputs, verifier, pool, RPC state, recovery material, and submission path to agree on one runtime.

Read current status first

State	What it means	Read
Published runtime	Nullark publishes its chain, contracts, fee, and proving-file settings as one set	Current deployment
Separate development work	Additional formal, circuit, and contract work follows its own evidence path	Formal verification
Deployment approval pending	Approval requires the complete published evidence set	Published status

Treat every recovery export as spend authority. Lost secrets, disclosed recovery material, and an approved wrong recipient are irreversible.

Start with the boundary you care about

See what remains public before making a privacy claim.
Protect recovery authority as bearer spend authority.
Audit the trust chain from runtime selection through settlement.
Read the audit report for the reviewed snapshot, findings, and limits.
Read what the proof checks before relying on Groth16 acceptance.
Report a vulnerability without publishing recovery material, witnesses, or a live exploit.

Assets at risk

Asset	What can go wrong	Primary safeguard
ETH held by the pool	Unauthorized exit, insolvency, or stuck value	Exact verifier, unique nullifiers, and contract accounting
Recovery material	Anyone holding it may be able to spend the note	Local handling, strict import validation, and offline backup
Private witness	Note ownership or Merkle-path data can leak	Local proving and a trusted browser origin
Runtime identity	Proof or transaction can target the wrong chain or pool	Matching chain, pool, verifier, codehash, and proof context
Proving artifacts	A substituted relation can produce misleading proofs	Independent manifest pin plus record and artifact hashes
Future relayer authority and funds	Unauthorized calls, changed policy, or unavailable submission	Selector allowlist, zero-value policy, bounded request, and operational controls

Who the system relies on

Actor	Role	Responsibility boundary
User	Preserve recovery authority and approve the public destination	Copied-note secrecy stays with the user
Browser app	Build witnesses, prove locally, and validate runtime state	Frontend authenticity depends on release and origin controls
Wallet	Sign or submit public transactions	Recovery material stays outside wallet prompts
RPC	Report blocks, logs, code, roots, fees, and receipts	Finality and correctness need reconciled state
Future relayer	Submit bounded withdrawal calldata and pay gas after a protocol is reviewed	Recipient and proof-bound fields stay fixed
Pool and verifiers	Enforce the accepted relation and accounting	Deployment identity comes from runtime checks
Operator	Maintain deployment, relayer, and incident controls	Private operational evidence needs independent review

Critical invariants

No withdrawal succeeds without a valid proof for the selected chain, pool, verifier, and positional public statement.
A nullifier is accepted at most once.
Deposits, private outputs, public exits, and fees preserve pool solvency.
Recovery material reconstructs only the commitment and runtime it actually binds.
Artifact trust starts from an independent pin outside the fetched manifest, setup record, WASM, and zkey set.
Future relayer authority stays limited to the proof-bound call.
Private witness material stays inside the trusted client boundary.

Control layers

Every layer must pass in order. A receipt confirms transaction execution; frontend authenticity comes from release provenance.

Read evidence narrowly

Evidence	Direct result	Next evidence
Focused test	Reviewed behavior passed under stated inputs	Broader coverage and release approval
Formal theorem	The modeled property follows under listed assumptions	Source and constraint refinement
SHA-256 or codehash	Bytes match an expected identity	Review of those bytes
Runtime record	Chain, contract, fee, and relayer values are published together	Key custody, service health, and origin integrity
Deployment evidence	A specific action and result were recorded	Separate privacy, readiness, and availability evidence

Verification

Reporting

Security overview

Read current status first

Start with the boundary you care about

Assets at risk

Who the system relies on

Critical invariants

Control layers

Read evidence narrowly

​Read current status first

​Start with the boundary you care about

​Assets at risk

​Who the system relies on

​Critical invariants

​Control layers

​Read evidence narrowly

Read current status first

Start with the boundary you care about

Assets at risk

Who the system relies on

Critical invariants

Control layers

Read evidence narrowly