# Barretenberg

Markdown version of https://l2beat.com/zk-catalog/barretenberg

## Summary

- Creator: Aztec
- Total Value Secured: $43.74 K (+96.3% compared to seven days ago)
- Trusted setups for UltraHonk (Plonk):
  - Aztec Ignition, risk green (lowest risk) per the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381): Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.
  - Used in: [Aztec Network](https://l2beat.com/layer2s/projects/aztecnetwork), [zk.money](https://l2beat.com/privacy/projects/zkmoney), [Payy](https://l2beat.com/privacy/projects/payy)
  - Verifiers: 6 successful (verified by [L2BEAT](https://l2beat.com))
- zkVM: UltraHonk (Plonk), CHONK (Plonk), BN254 (curve), Grumpkin (curve), AVM (ISA)

### About

Barretenberg includes several zk-SNARK proof systems built by Aztec, including UltraHonk and CHONK.

### Links

- Website: https://aztec.network
- Docs: https://barretenberg.aztec.network/docs/, https://eprint.iacr.org/2022/1355
- Repository: https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg
- Social: https://x.com/aztecnetwork

## Value Secured

The interactive TVS chart is shown on [the HTML page](https://l2beat.com/zk-catalog/barretenberg#tvs).

## Proof System

### Description

Barretenberg is a C++ library that implements several Plonk-based proof systems, developed by Aztec. It notably includes UltraHonk SNARK as an optimized version of previous Plonk implementation, and CHONK (Client-side Highly Optimized ploNK) SNARK for client-side proving on weaker devices. Barretenberg implements actual zero-knowledge SNARK modifications that allow proving over private data, and provides tools to generate UltraHonk smart contract verifiers. It also contains circuits to prove private and public transactions on Aztec L2.

### Proof system

The main application of Barretenberg is proving Aztec L2 state transition, which includes users locally proving private transactions with true ZK CHONK and more powerful nodes proving public transactions using UltraHonk. CHONK proofs must be verified within UltraHonk, so Barretenberg also includes tools for recursive proving. Both proving systems operate on arithmetic circuits that could be compiled from [Noir](https://github.com/noir-lang/noir) programs into ACIR, which is a [native circuit representation for Barretenberg](https://barretenberg.aztec.network/docs/#relationship-with-noir).

#### UltraHonk

UltraHonk is built on top of [Plonk](https://eprint.iacr.org/archive/2019/953/1624533038.pdf) proof system, with several optimizations for performance. It also serves as a basis for CHONK. The main optimization comes from using sumcheck protocol over the boolean hypercube as described in the [HyperPlonk paper](https://eprint.iacr.org/2022/1355). This trick allows reducing prover time and memory requirements at the expense of larger proofs. Barretenberg also contains code for circuits [verifying Honk proofs within UltraHonk verifier](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg/cpp/src/barretenberg/stdlib/honk_verifier), allowing prover recursion. For more technical details on UltraHonk see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#readme).

#### CHONK

CHONK is the proof system that is most optimized for client side proving in memory-restricted environments like mobile and browsers. In addition, CHONK has zero-knowledge property to protect prover private inputs, which is achieved by adding random masking polynomials at several stages of the pipeline and some other measures. For the full description of ZK-related modifications see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#zero-knowledge).

One of CHONK’s key innovations is Goblin architecture that efficiently manages elliptic curve operations over BN254 used e.g. in signatures. Elliptic curve operations are collected in a queue during the circuit proving, but the proof of their correctness is deferred to the very end of the proving process. The final step of the proving is done over a different curve called Grumpkin, which is chosen to make these EC operations native (i.e. extremely efficient). The correctness of translation between BN254 and Grumpkin is handled by the [Translator VM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/translator_vm/README.md) and the correctness of EC operations is proven by the [ECCVM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/eccvm/README.md).

CHONK also introduces a folding scheme inspired by [HyperNova](https://eprint.iacr.org/2023/573) for more memory-efficient proving of recursive smart contract calls. In this case different smart contract are represented by different circuits, which are proven separately and then aggregated. The folding scheme allows efficient aggregation of these proofs that results in only one expensive polynomial commitment check in the end, instead of having to check it for each smart contract call.

For more technical details on CHONK see [here](https://github.com/AztecProtocol/aztec-packages/tree/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/chonk#readme).

#### Noir and trusted setups

Although not technically a part of Barretenberg proving repo, [Noir language](https://noir-lang.org) represents the most developer-friendly way to create circuits to be proven with UltraHonk or CHONK. It’s a domain-specific language inspired by Rust.

All Barretenberg proving systems extend Plonk, which is based on KZG commitment schemes. That requires a trusted setup, which is chosen to be Aztec Ignition trusted setup. Some internal proofs, like ECCVM proof, are based on IPA (inner product argument) and thus they require no trusted setup.

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

### Aztec Ignition

- Risk: green (lowest risk)
- Proof systems: UltraHonk (Plonk)

Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019.
It included 176 participants and was publicly open for participation.

- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).
- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).
- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition).

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

### Plonk: UltraHonk

A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library.

#### Payy aggregate verifier

UltraHonk verifier generated with Barretenberg from the final proof aggregation Noir circuit (agg_final) of Payy. The hash is the verification key hash hardcoded in the deployed verifier contract.

- Verifier ID: `0x0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328`
- Source: https://github.com/polybase/payy/tree/dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36/noir/agg_final
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [Payy](https://l2beat.com/privacy/projects/payy)

**Known deployments**

- [0x14DACD534ddc676601B27f41Eb541a7951524a2F](https://etherscan.io/address/0x14DACD534ddc676601B27f41Eb541a7951524a2F#code) on Ethereum, used in: [Payy](https://l2beat.com/privacy/projects/payy)

##### Verification steps

The verifier was regenerated on Linux. VK generation peaked at approximately 1.7 GiB of memory.

Prepare:

1. Install Nargo 1.0.0-beta.14, e.g. with `noirup -v 1.0.0-beta.14`. `nargo --version` should report noirc git version hash `60ccd48e18ad8ce50d5ecda9baf813b712145051`.
2. Install the Barretenberg CLI release `v3.0.0-nightly.20251030-2`, the version pinned to Nargo 1.0.0-beta.14 in the official [bb-versions.json](https://github.com/AztecProtocol/aztec-packages/blob/next/barretenberg/bbup/bb-versions.json) mapping, e.g. by downloading `barretenberg-amd64-linux.tar.gz` from the [aztec-packages release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v3.0.0-nightly.20251030-2). Note that the Payy repository README refers to this bb version as `3.0.0-manual.20251030`, for which no release artifact exists.

Verify:

1. Clone [polybase/payy](https://github.com/polybase/payy), then check out commit `dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36`.
2. Compile the `agg_final` circuit from source:
   ```bash
   cd noir
   nargo compile --package agg_final
   ```
3. Generate the UltraHonk verification key with the keccak oracle hash from the newly compiled bytecode:
   ```bash
   mkdir -p /tmp/payy-repro
   bb write_vk --scheme ultra_honk --oracle_hash keccak \
     -b target/agg_final.json -o /tmp/payy-repro
   xxd -p -c 0 /tmp/payy-repro/vk_hash
   ```
   The final command should print `0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328`.

#### Barretenberg Aztec verifier v5

- Verifier ID: `0x2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1`
- Source: https://github.com/AztecProtocol/aztec-packages/tree/v5.0.0/noir-projects/noir-protocol-circuits
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [Aztec Network](https://l2beat.com/layer2s/projects/aztecnetwork)

**Known deployments**

- [0x098f47c00F4df22a8030746Eb11378236C24b4bC](https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code) on Ethereum, used in: [Aztec Network](https://l2beat.com/layer2s/projects/aztecnetwork)

##### Verification steps

The verifier was regenerated on Linux. VK generation peaked at approximately 11.3 GiB of memory.

Prepare:

1. Install the toolchain expected by the repository: Node.js 24.12.0 or newer, Yarn 4.13.0, Rust 1.89.0, CMake 3.24 or newer, Clang 20, Zig 0.15.1, Ninja, `jq`, `xxd`, `base64`, and `gzip`.
2. Ensure at least 16 GiB of combined memory and swap is available.

Verify:

1. Clone [AztecProtocol/aztec-packages](https://github.com/AztecProtocol/aztec-packages), then check out tag `v5.0.0`. It should resolve to commit `7aa2bd616d632801fe65d97ee8a4434f26886b40`.
2. Initialize the Noir source pinned by the tag: `git submodule update --init --depth 1 noir/noir-repo`. It should resolve to commit `c57152f91260ecdb9faad4efc20abb14b6d2ece7`.
3. Build Nargo from the pinned source:
   ```bash
   cd noir/noir-repo
   cargo +1.89.0 build --locked --release --target-dir target --bin nargo
   cd ../..
   ```
4. Build the Barretenberg CLI from source without AVM components:
   ```bash
   cd barretenberg/cpp
   cmake --fresh --preset clang20-no-avm -DAVM_TRANSPILER_LIB=
   cmake --build --preset clang20-no-avm --target bb --parallel 4
   cd ../..
   ```
5. Generate the ignored Noir workspace files. Do not run the protocol-circuits bootstrap because it consumes the tracked `pinned-build.tar.gz` instead of compiling the circuit source.
   ```bash
   cd noir-projects/noir-protocol-circuits
   corepack yarn@4.13.0 install
   corepack yarn@4.13.0 generate_variants
   ```
6. Compile `rollup_root` from source:
   ```bash
   ../../noir/noir-repo/target/release/nargo check \
     --package rollup_root --silence-warnings --show-program-hash
   ../../noir/noir-repo/target/release/nargo compile \
     --package rollup_root --skip-brillig-constraints-check
   ```
   The monomorphized Noir program hash printed by the first command should be `62fd003ca75d0cd7`.
7. Generate the UltraHonk verification key from the newly compiled bytecode:
   ```bash
   mkdir -p /tmp/aztec-v5-repro
   jq -r '.bytecode' target/rollup_root.json \
     | base64 -d \
     | gunzip \
     | ../../barretenberg/cpp/build/bin/bb write_vk \
         --scheme ultra_honk --oracle_hash keccak \
         -b - -o /tmp/aztec-v5-repro
   xxd -p -c 0 /tmp/aztec-v5-repro/vk_hash
   ```
   The final command should print `2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1`.
8. Regenerate the Solidity verifier:
   ```bash
   ../../barretenberg/cpp/build/bin/bb write_solidity_verifier \
     --scheme ultra_honk --disable_zk \
     -k /tmp/aztec-v5-repro/vk \
     -o /tmp/aztec-v5-repro/HonkVerifier.sol \
     --optimized
   diff -u \
     /tmp/aztec-v5-repro/HonkVerifier.sol \
     ../../l1-contracts/script/deploy/HonkVerifier.sol
   ```
   The generated verifier should be identical to the repository copy except for the latter's provenance comment after the Solidity pragma.

#### zk.money frozen notes refund verifier

Verifies refunds of notes that were unspent when the zk.money portal was frozen. Generated without the zero-knowledge option.

- Verifier ID: `0x05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`
- Source: https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/frozen_notes_refund
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

**Known deployments**

- [0x0694fF404DDA586C73EfCe21f34fe084541BB877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) on Ethereum, used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

##### Verification steps

The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.

Prepare:

1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.
2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.
3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.

Verify:

1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.
2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.
   ```bash
   cd vendor/oxide/noir-projects
   for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do
     (cd $c \
       && nargo compile --silence-warnings --package $c \
       && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \
         | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \
       && echo "$c $(xxd -p -c 0 target/keys/vk_hash)")
   done
   ```
   The printed hashes should be:
   - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`
   - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`
   - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`
   - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`
3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:
   ```bash
   for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \
            frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \
            unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \
            resolver_circuit:pinned/PinnedResolverVerifier:; do
     IFS=: read -r c path flags <<<"$v"
     bb write_solidity_verifier --scheme ultra_honk $flags \
       -k $c/target/keys/vk -o $c/target/verifier.sol
     cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo "$c matches"
   done
   ```
   Each circuit should print `matches`.
4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.
5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.

   | Circuit | Ethereum verifier | Linked libraries |
   | --- | --- | --- |
   | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |
   | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |
   | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |
   | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |

#### zk.money frozen deposit refund verifier

Verifies refunds of deposits that reached Aztec but were unspent when the zk.money portal was frozen. Generated without the zero-knowledge option.

- Verifier ID: `0x2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`
- Source: https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/frozen_deposit_refund
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

**Known deployments**

- [0xa2fd594dCA2d598aF231d615E5D34903154C3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) on Ethereum, used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

##### Verification steps

The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.

Prepare:

1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.
2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.
3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.

Verify:

1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.
2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.
   ```bash
   cd vendor/oxide/noir-projects
   for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do
     (cd $c \
       && nargo compile --silence-warnings --package $c \
       && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \
         | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \
       && echo "$c $(xxd -p -c 0 target/keys/vk_hash)")
   done
   ```
   The printed hashes should be:
   - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`
   - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`
   - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`
   - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`
3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:
   ```bash
   for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \
            frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \
            unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \
            resolver_circuit:pinned/PinnedResolverVerifier:; do
     IFS=: read -r c path flags <<<"$v"
     bb write_solidity_verifier --scheme ultra_honk $flags \
       -k $c/target/keys/vk -o $c/target/verifier.sol
     cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo "$c matches"
   done
   ```
   Each circuit should print `matches`.
4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.
5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.

   | Circuit | Ethereum verifier | Linked libraries |
   | --- | --- | --- |
   | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |
   | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |
   | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |
   | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |

#### zk.money unprocessed deposit refund verifier

Verifies refunds of deposits that had not reached Aztec when the zk.money portal was frozen. Generated without the zero-knowledge option.

- Verifier ID: `0x080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`
- Source: https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/unprocessed_deposit_refund
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

**Known deployments**

- [0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) on Ethereum, used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

##### Verification steps

The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.

Prepare:

1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.
2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.
3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.

Verify:

1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.
2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.
   ```bash
   cd vendor/oxide/noir-projects
   for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do
     (cd $c \
       && nargo compile --silence-warnings --package $c \
       && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \
         | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \
       && echo "$c $(xxd -p -c 0 target/keys/vk_hash)")
   done
   ```
   The printed hashes should be:
   - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`
   - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`
   - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`
   - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`
3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:
   ```bash
   for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \
            frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \
            unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \
            resolver_circuit:pinned/PinnedResolverVerifier:; do
     IFS=: read -r c path flags <<<"$v"
     bb write_solidity_verifier --scheme ultra_honk $flags \
       -k $c/target/keys/vk -o $c/target/verifier.sol
     cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo "$c matches"
   done
   ```
   Each circuit should print `matches`.
4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.
5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.

   | Circuit | Ethereum verifier | Linked libraries |
   | --- | --- | --- |
   | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |
   | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |
   | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |
   | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |

#### zk.money resolver verifier

Verifies that the secret behind a deposit address returned for a zk.money name was derived from the registered user and resolver operator keys, and binds the address to the registered Aztec address. Generated with the zero-knowledge option.

- Verifier ID: `0x279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`
- Source: https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/resolver_circuit
- Verification: successful (verified by [L2BEAT](https://l2beat.com))
- Used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

**Known deployments**

- [0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) on Ethereum, used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney)

##### Verification steps

The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.

Prepare:

1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.
2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.
3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.

Verify:

1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.
2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.
   ```bash
   cd vendor/oxide/noir-projects
   for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do
     (cd $c \
       && nargo compile --silence-warnings --package $c \
       && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \
         | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \
       && echo "$c $(xxd -p -c 0 target/keys/vk_hash)")
   done
   ```
   The printed hashes should be:
   - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`
   - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`
   - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`
   - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`
3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:
   ```bash
   for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \
            frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \
            unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \
            resolver_circuit:pinned/PinnedResolverVerifier:; do
     IFS=: read -r c path flags <<<"$v"
     bb write_solidity_verifier --scheme ultra_honk $flags \
       -k $c/target/keys/vk -o $c/target/verifier.sol
     cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo "$c matches"
   done
   ```
   Each circuit should print `matches`.
4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.
5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.

   | Circuit | Ethereum verifier | Linked libraries |
   | --- | --- | --- |
   | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |
   | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |
   | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |
   | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |