Trust starts with an independently bundled SHA-256 pin. The browser matches the raw manifest bytes against that pin before trusting the manifest, setup record, WASM, or zkey. This breaks the attack where every proving file is replaced with a matching fake set.

​
Browser trust chain

  1. Runtime configuration provides the manifest URL and expected SHA-256 pin.
  2. The browser fetches with cache: no-store and enforces the manifest byte cap.
  3. It hashes the raw bytes before parsing JSON or following a pointer.
  4. In every supported deployment, a missing pin or hash mismatch rejects the manifest.
  5. The parsed manifest names the setup record and exact proving-file hashes.
  6. The browser caps and hashes the setup record before parsing it.
  7. Status, supersession, chain, pool, verifier, verifier bytecode hash, and public-input order must match the expected deployment.
  8. The browser caps the WASM and zkey and checks their exact SHA-256 values.
  9. Proof generation stays locked until every check passes.

​
Byte limits

Each cap leaves documented room above the current file while limiting memory and network use. The browser rejects a declared Content-Length above the cap immediately. A streamed byte counter enforces the same cap when that header is missing or false.

​
Setup-record binding

The record must agree with both manifest and bundled deployment expectations:
  • Approval status appropriate for chain
  • No supersession marker
  • Chain ID and pool
  • Withdrawal verifier and bytecode hash
  • Deposit verifier binding when required by the selected operation
  • Exact positional public-input order
  • WASM and zkey hashes
approvedBy and approvedAt are display metadata only. Byte authenticity and deployment approval come from the external pin and release evidence.

​
Cache identity

The verified cache key includes the manifest URL, external pin, actual manifest hash, setup-record pointer, deployment, operation, and public-input schema. Cached WASM and zkey results inherit that identity. Changing the external pin creates a different cache key and forces a fresh verification result.

​
No automatic fallback

A missing or mismatched trusted pin must keep proving locked. It must never activate a weaker development path automatically.

​
Where trust moves next

If an attacker replaces both the frontend and its pin, trust moves to reproducible builds, reviewed release artifacts, deployment controls, origin security, and independent verification. The manifest covers proving-file identity. Circuit soundness, ceremony integrity, and source-to-circuit equivalence each need their own evidence.