# Privacy Boost Markdown version of https://ethbeat.org/zk-catalog/privacy-boost ## Summary - Creator: Sunnyside Labs - Total Value Secured: $728.00 K (-1.91% compared to seven days ago) - Trusted setups for Gnark (Groth16): - Privacy Boost v3, risk red (highest risk) per the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381): Circuit-specific trusted setup for the 12 Groth16 Privacy Boost epoch, forced withdrawal and gift claim circuits deployed in late September 2026. Phase 1 used 61 Perpetual Powers of Tau participant contributions and a public randomness beacon. The published phase 2 round record reports 16 participants and 16 contributions per circuit. Its public bundle reproduces the deployed keys. The proving system could be broken if either phase 1 or 2 is compromised. - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) - Verifiers: 5 successful (verified by [ETHBEAT](https://ethbeat.org)) - zkVM: BN254 (curve), Gnark (Groth16), R1CS (Arithmetization), App-specific circuits (Other) ### About A shielded ledger for ERC-20 tokens on Base, aimed at institutional users, whose privacy rests on the operator's TEE. ### Links - Website: https://www.privacyboost.io/ - Docs: https://docs.privacyboost.io/ - Repository: https://github.com/sunnyside-io/privacy-boost-protocol, https://github.com/sunnyside-io/privacy-boost-ceremony ## Value Secured The interactive TVS chart is shown on [the HTML page](https://ethbeat.org/zk-catalog/privacy-boost#tvs). ## Proof System Privacy Boost uses **Groth16 over BN254**, with circuits written in Go against the [gnark](https://github.com/Consensys/gnark) R1CS frontend. There is no recursive proof aggregation; batching happens inside each circuit. There are five verifier families: - **Epoch**: private transfers, withdrawals and gateway withdrawals; 9 reviewed configurations. - **Deposit epoch**: standard deposit batches of 1, 4 or 14. - **Portal deposit epoch**: hidden-recipient portal deposit batches of 1 or 6. - **Forced withdrawal**: a permissionless delayed exit spending up to 13 notes, using a live auth key or spend approval checked at request time. - **Gift claim**: private gift claims/refunds and public gift exits, with registered batch sizes 1 and 3. For each of the verifier contracts, different configurations can be allowed with the according verifier keys. There are 17 verifier keys currently registered (9 epoch + 3 deposit + 2 portal + 1 forced withdrawal + 2 gift). ## Milestones & Incidents - 2026-09-08: [Privacy Boost live on Base](https://privacyboost.io/resources/blog/privacy-boost-live-on-base). Sunnyside Labs opens the hosted wallet and SDK to anyone on Base. - 2026-04-20: [Privacy Boost live on OP Mainnet](https://optimism.io/blog/privacy-comes-to-the-op-stack). Sunnyside Labs opens Privacy Boost to its customers on OP Mainnet. ## Trusted Setups Risk levels follow the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381). Yellow (medium risk): all contributions are published and the final output can be verified, the ceremony client is open source, there were at least 30 contributions, participation was open to the public and announced, and participants are publicly identified. Green (lowest risk): everything required for yellow, with at least 150 contributions. Red (highest risk): at least one requirement for yellow is not met. N/A: the proof system needs no trusted setup. ### Privacy Boost v3 - Risk: red (highest risk) - Proof systems: Gnark (Groth16) - Phase 1: 61 contributions - Phase 2: 16 participants (16 contributions per circuit across 12 circuits.) Circuit-specific trusted setup for 12 Groth16 circuits of the Privacy Boost protocol over the BN254 curve, run by Sunnyside Labs as its third production round (`prod-ceremony-2026-03`, release `ceremony/v0.0.5`). Its keys were registered onchain on 23 September 2026 and replace the second round keys of the epoch (9 shapes, down from 13), forced withdrawal and gift claim circuits, which were recompiled with gnark v0.16.3 after the EdDSA signature check was rewritten. The deposit and portal deposit circuits keep their second round keys. It uses the `ppot_0080` files from the public [Perpetual Powers of Tau](https://github.com/privacy-ethereum/perpetualpowersoftau) ceremony as Phase 1. These contain 61 participant contributions and one public randomness beacon. Contribution 0078 resumes from 0058 after a fork, so the included IDs are 0001–0058 and 0078–0080, rather than the first 80 contributions. Phase 2 is a gnark-native MPC ceremony finalized on 23 September 2026. The published round record reports **16 participants** and **192 accepted contributions**, 16 per circuit. Participants are identified by GitHub username, and four of them show a Sunnyside Labs affiliation there. The coordinator served plain HTTP and contributions carry no signatures, so participant names rest on the coordinator's records. The public verification bundle, published on 29 October 2026, re-derives every registered key from these contributions. - Phase 1 ceremony and fork: . - Ceremony repository and contributor tooling: [https://github.com/sunnyside-io/privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) - Round record with the published counts and bundle digests: [rounds/2026-03.md](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e1e5a01d9bc4ce5b0917d6302aa4d294b6539894/rounds/2026-03.md) - Contributor release: [ceremony/v0.0.5](https://github.com/sunnyside-io/privacy-boost-ceremony/releases/tag/ceremony%2Fv0.0.5) - Offline verification procedure: [PUBLIC_VERIFICATION.md](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e1e5a01d9bc4ce5b0917d6302aa4d294b6539894/PUBLIC_VERIFICATION.md) - Public verification bundle: [https://file.ceremony.privacyboost.io/prod-20260923-public.tar.gz](https://file.ceremony.privacyboost.io/prod-20260923-public.tar.gz) - Derived key bundle: [https://file.ceremony.privacyboost.io/prod-20260923-keys.tar.gz](https://file.ceremony.privacyboost.io/prod-20260923-keys.tar.gz) ## Verifier IDs List of different onchain verifiers for this proving system. Unique ID distinguishes different deployments of the same verifier from different verifiers (e.g. different versions). ### Groth16: Gnark Consensys implementation of Groth16 proving system written in Go. #### Privacy Boost epoch verifier, 9 circuits Verifies the batched private transfer and withdrawal proofs. - Verifier ID: `Privacy Boost epoch verifier 23.09.2026` - Source: https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/epoch_circuit.go - Verification: successful (verified by [ETHBEAT](https://ethbeat.org)) - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) **Known deployments** - [0xB144eb785E2CCe17681395Cd475093C01AEeb11e](https://basescan.org/address/0xB144eb785E2CCe17681395Cd475093C01AEeb11e#code) on Base Chain, used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) ##### Verification steps The epoch, forced withdrawal and gift claim verifiers store the 12 verification keys of the third production ceremony: epoch shapes `s1`, `s5`, `m1`, `m4`, `l1`, `l3`, `sp1`, `w51` and `w201`, forced withdrawal `f13` and gift claims `g1` and `g3`. The steps below re-derive all 12 keys from the circuit sources and the ceremony transcript and match them to the keys the verifiers read. The re-derivation takes about 2 hours, stays under 6 GiB of RAM and needs about 10 GB of disk. A [helper script](https://ethbeat.org/files/privacy_boost_artifacts/ceremony-r3.sh) runs all four steps, with the untrusted builds in Docker: `ceremony-r3.sh all`, with `BASE_RPC_URL` set to a Base endpoint. 1. Download the public bundle and the keys, and check their digests against the [round record](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e1e5a01d9bc4ce5b0917d6302aa4d294b6539894/rounds/2026-03.md): `d584146c…` for the bundle, `3dfe30e5…` for the keys and `626faf00…` for `public/manifest.json`. ``` curl -LO https://file.ceremony.privacyboost.io/prod-20260923-public.tar.gz curl -LO https://file.ceremony.privacyboost.io/prod-20260923-keys.tar.gz shasum -a 256 prod-20260923-public.tar.gz prod-20260923-keys.tar.gz tar xzf prod-20260923-public.tar.gz tar xzf prod-20260923-keys.tar.gz shasum -a 256 public/manifest.json ``` 2. Build the verifier from [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e1e5a01d`. It compiles the `frontend/` circuits of [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at `f8a866ce` with gnark v0.16.3 and gnark-crypto v0.21.0, the versions embedded in the signed `ceremony/v0.0.5` release binaries. The protocol commit linked above, `5792c139`, differs from `f8a866ce` only in tests and a Solidity constants file. ``` git clone https://github.com/sunnyside-io/privacy-boost-ceremony cd privacy-boost-ceremony git checkout e1e5a01d9bc4ce5b0917d6302aa4d294b6539894 go build -o ./bin/ceremony ./cmd/ceremony ``` 3. Run the public verification. It checks the bundle root and each contribution chain, recompiles every circuit and matches its R1CS hash, fetches the Perpetual Powers of Tau `pot28_0080` file for the circuit's power and checks its hash, verifies the 16 contributions in order from a freshly computed origin, and matches the re-derived proving and verifying keys with the manifest. ``` ./bin/ceremony verify-public --bundle-dir public ``` 4. Check that each `keys/.vk` hashes to the manifest's `vkSha256` and compare it with the chain. The verifier reads 448 bytes of constants (alpha, then the negated beta, gamma and delta, each G2 point as x1, x0, y1, y0) and the x and y coordinates of the IC points from SSTORE2 contracts. `getEpochVKInfo(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` on the epoch verifier and `getVKInfo(param)` on the forced withdrawal (`13`) and gift claim (`1`, `3`) verifiers return the IC length and the constants contract. The IC contracts sit in the key registry at storage slot 5 for the epoch verifier, keyed by the three parameters, and at slot 2 for the other two. #### Privacy Boost deposit verifier, 3 circuits Verifies the batched deposit epoch proofs. - Verifier ID: `Privacy Boost deposit verifier 09.09.2026` - Source: https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_epoch_circuit.go - Verification: successful (verified by [ETHBEAT](https://ethbeat.org)) - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) **Known deployments** - [0xac60252EF8dbC139e0da63cE7F2a13D25a5B627d](https://basescan.org/address/0xac60252EF8dbC139e0da63cE7F2a13D25a5B627d#code) on Base Chain, used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) ##### Verification steps The deposit verifier stores verification keys for 3 different batched deposit circuits across 3 registered batch sizes (`d1`, `d4`, `d14`). The steps below reproduce all 3 verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the [script archive](https://trusted-setup-hosting.l2beat.com/privacy/privacy-boost/privacy_boost_vk_digest_v2.zip). 1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. ``` curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar ``` 2. Check that the ceremony's circuit matrix in `public/config.snapshot.json` matches the circuit shapes registered on the verifier, and that the manifest's `circuitSpecJson` for each circuit agrees with them and with `circuit-setup/configs/production.ceremony.config.json` in [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`. 3. Re-derive every key from the transcript. The circuits are the `frontend/` package of [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. ``` python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2 ``` 4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block (equivalent to the Base deployment), recomputing the storage slots from the circuit parameters and cross-checking them against the getters. #### Privacy Boost forced withdrawal verifier, 1 circuit Verifies the client-side forced withdrawal proofs. - Verifier ID: `Privacy Boost forced withdrawal verifier 23.09.2026` - Source: https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/forced_withdraw_circuit.go - Verification: successful (verified by [ETHBEAT](https://ethbeat.org)) - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) **Known deployments** - [0x40e93d3357A5A3d249437717Da936f6141ba85cE](https://basescan.org/address/0x40e93d3357A5A3d249437717Da936f6141ba85cE#code) on Base Chain, used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) ##### Verification steps The epoch, forced withdrawal and gift claim verifiers store the 12 verification keys of the third production ceremony: epoch shapes `s1`, `s5`, `m1`, `m4`, `l1`, `l3`, `sp1`, `w51` and `w201`, forced withdrawal `f13` and gift claims `g1` and `g3`. The steps below re-derive all 12 keys from the circuit sources and the ceremony transcript and match them to the keys the verifiers read. The re-derivation takes about 2 hours, stays under 6 GiB of RAM and needs about 10 GB of disk. A [helper script](https://ethbeat.org/files/privacy_boost_artifacts/ceremony-r3.sh) runs all four steps, with the untrusted builds in Docker: `ceremony-r3.sh all`, with `BASE_RPC_URL` set to a Base endpoint. 1. Download the public bundle and the keys, and check their digests against the [round record](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e1e5a01d9bc4ce5b0917d6302aa4d294b6539894/rounds/2026-03.md): `d584146c…` for the bundle, `3dfe30e5…` for the keys and `626faf00…` for `public/manifest.json`. ``` curl -LO https://file.ceremony.privacyboost.io/prod-20260923-public.tar.gz curl -LO https://file.ceremony.privacyboost.io/prod-20260923-keys.tar.gz shasum -a 256 prod-20260923-public.tar.gz prod-20260923-keys.tar.gz tar xzf prod-20260923-public.tar.gz tar xzf prod-20260923-keys.tar.gz shasum -a 256 public/manifest.json ``` 2. Build the verifier from [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e1e5a01d`. It compiles the `frontend/` circuits of [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at `f8a866ce` with gnark v0.16.3 and gnark-crypto v0.21.0, the versions embedded in the signed `ceremony/v0.0.5` release binaries. The protocol commit linked above, `5792c139`, differs from `f8a866ce` only in tests and a Solidity constants file. ``` git clone https://github.com/sunnyside-io/privacy-boost-ceremony cd privacy-boost-ceremony git checkout e1e5a01d9bc4ce5b0917d6302aa4d294b6539894 go build -o ./bin/ceremony ./cmd/ceremony ``` 3. Run the public verification. It checks the bundle root and each contribution chain, recompiles every circuit and matches its R1CS hash, fetches the Perpetual Powers of Tau `pot28_0080` file for the circuit's power and checks its hash, verifies the 16 contributions in order from a freshly computed origin, and matches the re-derived proving and verifying keys with the manifest. ``` ./bin/ceremony verify-public --bundle-dir public ``` 4. Check that each `keys/.vk` hashes to the manifest's `vkSha256` and compare it with the chain. The verifier reads 448 bytes of constants (alpha, then the negated beta, gamma and delta, each G2 point as x1, x0, y1, y0) and the x and y coordinates of the IC points from SSTORE2 contracts. `getEpochVKInfo(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` on the epoch verifier and `getVKInfo(param)` on the forced withdrawal (`13`) and gift claim (`1`, `3`) verifiers return the IC length and the constants contract. The IC contracts sit in the key registry at storage slot 5 for the epoch verifier, keyed by the three parameters, and at slot 2 for the other two. #### Privacy Boost portal deposit verifier, 2 circuits Verifies the batched hidden-recipient portal deposit proofs. - Verifier ID: `Privacy Boost portal deposit verifier 09.09.2026` - Source: https://github.com/sunnyside-io/privacy-boost-protocol/blob/9e3f34e1a91c20497bc7d8f47492761bc868843c/frontend/deposit_portal_circuit.go - Verification: successful (verified by [ETHBEAT](https://ethbeat.org)) - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) **Known deployments** - [0x0c8bb018a3d8DF4c5fC86518ca57F8E1445BCF63](https://basescan.org/address/0x0c8bb018a3d8DF4c5fC86518ca57F8E1445BCF63#code) on Base Chain, used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) ##### Verification steps The portal deposit verifier stores verification keys for 2 different batched portal deposit circuits across 2 registered batch sizes (`p1`, `p6`). The steps below reproduce both verification keys from circuit sources and trusted setup files. They require about 24 GiB RAM with two parallel workers and ~35 GiB disk space. Helper scripts implementing all of the reproduction steps are in the [script archive](https://trusted-setup-hosting.l2beat.com/privacy/privacy-boost/privacy_boost_vk_digest_v2.zip). 1. Download the second production ceremony public bundle (about 9.8 GB, gzip-compressed despite the `.tar` name) and extract it. The archive used for this attestation hashes to `91ad38d7775259116d00e5288630aaec565fbec8ff38a76dc874c13412ae530a`. ``` curl -LO https://file.ceremony.privacyboost.io/prod-20260902-public.tar shasum -a 256 prod-20260902-public.tar tar xzf prod-20260902-public.tar ``` 2. Check that the ceremony's circuit matrix in `public/config.snapshot.json` matches the circuit shapes registered on the verifier, and that the manifest's `circuitSpecJson` for each circuit agrees with them and with `circuit-setup/configs/production.ceremony.config.json` in [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e645b68d`. 3. Re-derive every key from the transcript. The circuits are the `frontend/` package of [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at commit `9e3f34e1a91c`. Note that the ceremony coordinator compiled them with **gnark v0.15.0 and gnark-crypto v0.20.1**, as recorded in the build information embedded in the signed `ceremony/v0.0.x` release binaries. The public ceremony repository pins gnark v0.14.0 instead, which compiles to different constraint systems, so its `verify-public` command fails at the R1CS hash check. The script archive contains a per-circuit helper built against gnark v0.15.0 that recompiles each circuit's R1CS from its spec, checks it against the manifest, fetches and digest-checks the pinned Perpetual Powers of Tau artifact for the required power, recomputes the origin of the phase 2 transcript, verifies every contribution against its predecessor, and seals the proving and verifying keys, comparing them to the manifest commitments. Reading the transcript lazily keeps the peak below 10 GB per circuit. ``` python3 run.py prepare python3 onchain.py python3 run.py run --jobs 2 ``` 4. For each circuit, encode the re-derived `.vk` into the onchain layout (negate `beta`, `gamma`, `delta`; interleave `G1.K`) and confirm its digest equals the value read from chain. The helper reads all registered keys at one finalized OP Mainnet block (equivalent to the Base deployment), recomputing the storage slots from the circuit parameters and cross-checking them against the getters. #### Privacy Boost gift claim verifier, 2 circuits Verifies the batched gift claim, refund and public gift exit proofs. - Verifier ID: `Privacy Boost gift claim verifier 23.09.2026` - Source: https://github.com/sunnyside-io/privacy-boost-protocol/blob/5792c139b9529ed80643262d75b5489055be11b0/frontend/gift_claim_circuit.go - Verification: successful (verified by [ETHBEAT](https://ethbeat.org)) - Used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) **Known deployments** - [0x8f394a08A7544daf39aF38FEA5B2E348180bDC05](https://basescan.org/address/0x8f394a08A7544daf39aF38FEA5B2E348180bDC05#code) on Base Chain, used in: [Privacy Boost](https://ethbeat.org/privacy/projects/privacy-boost) ##### Verification steps The epoch, forced withdrawal and gift claim verifiers store the 12 verification keys of the third production ceremony: epoch shapes `s1`, `s5`, `m1`, `m4`, `l1`, `l3`, `sp1`, `w51` and `w201`, forced withdrawal `f13` and gift claims `g1` and `g3`. The steps below re-derive all 12 keys from the circuit sources and the ceremony transcript and match them to the keys the verifiers read. The re-derivation takes about 2 hours, stays under 6 GiB of RAM and needs about 10 GB of disk. A [helper script](https://ethbeat.org/files/privacy_boost_artifacts/ceremony-r3.sh) runs all four steps, with the untrusted builds in Docker: `ceremony-r3.sh all`, with `BASE_RPC_URL` set to a Base endpoint. 1. Download the public bundle and the keys, and check their digests against the [round record](https://github.com/sunnyside-io/privacy-boost-ceremony/blob/e1e5a01d9bc4ce5b0917d6302aa4d294b6539894/rounds/2026-03.md): `d584146c…` for the bundle, `3dfe30e5…` for the keys and `626faf00…` for `public/manifest.json`. ``` curl -LO https://file.ceremony.privacyboost.io/prod-20260923-public.tar.gz curl -LO https://file.ceremony.privacyboost.io/prod-20260923-keys.tar.gz shasum -a 256 prod-20260923-public.tar.gz prod-20260923-keys.tar.gz tar xzf prod-20260923-public.tar.gz tar xzf prod-20260923-keys.tar.gz shasum -a 256 public/manifest.json ``` 2. Build the verifier from [privacy-boost-ceremony](https://github.com/sunnyside-io/privacy-boost-ceremony) at commit `e1e5a01d`. It compiles the `frontend/` circuits of [privacy-boost-protocol](https://github.com/sunnyside-io/privacy-boost-protocol) at `f8a866ce` with gnark v0.16.3 and gnark-crypto v0.21.0, the versions embedded in the signed `ceremony/v0.0.5` release binaries. The protocol commit linked above, `5792c139`, differs from `f8a866ce` only in tests and a Solidity constants file. ``` git clone https://github.com/sunnyside-io/privacy-boost-ceremony cd privacy-boost-ceremony git checkout e1e5a01d9bc4ce5b0917d6302aa4d294b6539894 go build -o ./bin/ceremony ./cmd/ceremony ``` 3. Run the public verification. It checks the bundle root and each contribution chain, recompiles every circuit and matches its R1CS hash, fetches the Perpetual Powers of Tau `pot28_0080` file for the circuit's power and checks its hash, verifies the 16 contributions in order from a freshly computed origin, and matches the re-derived proving and verifying keys with the manifest. ``` ./bin/ceremony verify-public --bundle-dir public ``` 4. Check that each `keys/.vk` hashes to the manifest's `vkSha256` and compare it with the chain. The verifier reads 448 bytes of constants (alpha, then the negated beta, gamma and delta, each G2 point as x1, x0, y1, y0) and the x and y coordinates of the IC points from SSTORE2 contracts. `getEpochVKInfo(maxTransfers, maxInputsPerTransfer, maxOutputsPerTransfer)` on the epoch verifier and `getVKInfo(param)` on the forced withdrawal (`13`) and gift claim (`1`, `3`) verifiers return the IC length and the constants contract. The IC contracts sit in the key registry at storage slot 5 for the epoch verifier, keyed by the three parameters, and at slot 2 for the other two.