> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nullark.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security overview

See what is live, what Nullark protects, and which evidence supports each security boundary.

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.

## Start here

| Read | Use it for |
| --- | --- |
| [Current runtime](/reference/current-runtime.md) | Chain ID, contracts, fee, proving files, and exact identities |
| [Security status](/security/status.md) | What is live, reviewed, and public today |
| [Formal verification](/security/formal-verification.md) | Completed artifact-bound fund-safety claim and assumptions |

**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](/security/privacy-boundaries.md) before making a privacy claim.
- [Protect recovery authority](/security/recovery-note-safety.md) as bearer spend authority.
- [Audit the trust chain](/security/trust-model.md) from runtime selection through settlement.
- [Read the audit report](/security/audit-report.md) for the reviewed snapshot, findings, and limits.
- [Read what the proof checks](/security/proof-system.md) before relying on Groth16 acceptance.
- [Prepare a security report](/security/reporting.md) 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

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

## Control layers

```mermaid
flowchart TB
  subgraph Custody["Client custody"]
    R["Recovery authority"] -->|restore note locally| W["Private witness"]
  end

  subgraph Proof["Authenticated proof context"]
    A["Runtime + independent artifact pin"] -->|select exact relation| P["Pinned proving relation"]
    W -->|private inputs| Z["Groth16 proof"]
    P -->|define constraints and public order| Z
  end

  subgraph Chain["Onchain enforcement"]
    Z -->|proof + bound public inputs| V{"Proof, nullifier, and accounting checks pass?"}
    V -->|yes| S["Atomic pool settlement"]
    V -->|no| X["Revert: state unchanged"]
    S -->|receipt + events + nullifier read| C["Client reconciliation"]
  end
```

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 |