> ## 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.

# Where Nullark trust begins

Trace what Nullark trusts across runtime configuration, proving files, the browser, wallet, RPC, relayer, contracts, and operator controls.

A checksum bundled with its own download is circular. A receipt confirms execution only. Nullark gives each dependency an independent trust check.

## Dependency map

| Dependency | Independent check | If compromised | What remains trusted |
| --- | --- | --- | --- |
| Bundled runtime configuration | Exact chain, pool, deployment block, verifier, selector, codehash, RPC, and artifact pin | An attacker can redefine the runtime the client expects | Reviewed bundle and deployment provenance are still required |
| Proving manifest | Raw bytes capped and checked against independently bundled SHA-256 before parsing | Wrong or missing pin blocks trusted loading | Full frontend compromise can replace manifest and pin together |
| Trusted setup record | Capped and hashed bytes; status, supersession, deployment, verifier, codehash, and input order checked | Invalid records stop artifact loading | Ceremony quality and approval provenance need separate review |
| WASM and zkey | Capped bytes and exact manifest-bound hashes | Substitution or oversized payload is rejected | Correct bytes can still encode an unsound or wrongly reviewed relation |
| Browser and dependencies | Local witness handling plus verifier self-check before submission | Secret material, recipient, or displayed state can be stolen or altered | Origin and software supply-chain security remain external controls |
| Wallet | Chain-aware signature or transaction confirmation | Malicious prompt can expose account intent or authorize a wrong public action | Wallet software and user review remain trusted |
| RPC | Chain check, runtime reads, bytecode, logs, roots, fee state, and receipt reconciliation | Lag or manipulation can show stale or inconsistent state | Independent endpoint diversity and finality policy are operational choices |
| Relayer | Exact endpoint, pool and selector allowlist, zero value, deadline, and proof-bound calldata | Key compromise can disrupt service or submit allowed calls | Availability, funding, and private key custody remain private operational facts |
| Pool and verifiers | Proof verification, nullifier rejection, fee bounds, and accounting | Contract or deployment flaw can lose or lock ETH | Audits, formal evidence, deployment review, and governance controls stay necessary |
| Operator process | Approval, release, key custody, monitoring, and incident response | Private control failure can undermine an otherwise correct release | Unpublished operational evidence remains private |

## Artifact root of trust

```mermaid
flowchart TB
  subgraph Root["Independent bundled expectations"]
    EXPECT["Manifest SHA-256, chain, pool<br/>verifier, and public-input order"]
  end

  subgraph Gates["Fetched bytes pass fail-closed checks in order"]
    M{"Raw manifest<br/>hash matches?"}
    S{"Setup active and<br/>deployment-bound?"}
    A{"WASM and zkey<br/>hashes match?"}
    READY["Trusted prover context"]
    STOP["Stop: no trusted proving"]

    M -->|yes| S
    M -->|no| STOP
    S -->|yes| A
    S -->|no| STOP
    A -->|yes| READY
    A -->|no| STOP
  end

  EXPECT -->|authenticate fetched manifest| M
```

Trust starts with the expected pin in bundled runtime configuration, outside the fetched manifest, setup record, WASM, and zkey set. `approvedBy` and `approvedAt` are display metadata only.

Cache identity includes that expected pin. A new pin forces fresh verification.

See [Authenticate proving artifacts](/developers/proving-artifacts.md) for the byte caps and validation order.

## Transaction trust path

Before treating a withdrawal as settled, the client checks:

1. Recovered note and commitment
2. Accepted root and local Merkle witness
3. Current fee and intended public destination
4. Nine positional public inputs
5. Proof against the bound verifier relation
6. Pool, selector, value, deadline, and submission route
7. Receipt, pool event, and recorded nullifier

If one of these values changes, rebuild every dependent proof or transaction value. UI refresh speed leaves stale proofs stale.

## If the frontend itself is compromised

Artifact authentication rejects malicious same-origin file replacement while the trusted frontend bundle and its bundled pin remain intact. Compromise of both frontend logic and pin moves trust to reproducible builds, reviewed release provenance, protected deployment credentials, origin security, and independent artifact verification.

`approvedBy`, `approvedAt`, a green UI state, and a fast MegaETH receipt stay outside that trust root.