# Update Prover Toml

> Regenerate the protocol-circuit sample Prover.toml files (the witnesses CI feeds to `nargo execute`). Covers which of the two commands regenerates which tomls — the prover-client `regenerate_rollup_sample_inputs` suite for the block-root and above rollup circuits, and the e2e prover full test for the private-kernel and transaction-base circuits — and the one exception, private-kernel-reset/Prover.toml (the inner reset), which is NOT generated by the test at all and is maintained entirely by hand. Use when a `nargo execute` CI check fails on a crates/*/Prover.toml, after changing protocol-circuit inputs/constants, or when asked to refresh/regenerate Prover.toml sample inputs.

- Skill: `aztecprotocol/update-prover-toml` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aztecprotocol/update-prover-toml`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aztecprotocol/update-prover-toml/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: aztecprotocol (https://skillmd.com/u/aztecprotocol)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aztecprotocol/update-prover-toml

---


# Updating protocol-circuit Prover.toml files

All paths are from the repository root (one level above `barretenberg/`). The circuit crates and their tomls live in this repository; the TypeScript that regenerates them lives in the `labs/` git submodule, so its paths start with `labs/yarn-project/` and its workspaces are named `@aztec-labs/*`. Run the yarn commands below from `labs/yarn-project`.

## What these files are

Each `noir-projects/fnd/noir-protocol-circuits/crates/<circuit>/Prover.toml` is a checked-in **sample input (witness)** for that circuit. Its job is a CI smoke test: `noir-projects/fnd/noir-protocol-circuits/bootstrap.sh` (`test_cmds` → `circuits_to_execute`) runs, for each listed circuit,

```
nargo execute --program-dir noir-projects/fnd/noir-protocol-circuits/crates/<circuit> --silence-warnings --skip-brillig-constraints-check
```

`nargo execute` reads the `Prover.toml`, generates the witness, and asserts all constraints hold. So each toml must be **valid** (or the execute test fails) and **representative** (so the test exercises the circuit on real-shaped inputs).

The tomls are captured from a real end-to-end run, not written by hand (except the reset one — see below).

Each toml is self-contained on the verification-key side: it carries its own `vk_tree_root`, plus a `vk_data` membership witness (`leaf_index` + `sibling_path`) under that root for every child proof the circuit verifies. So a change that only moves the real VK tree root — adding or removing a circuit, say — does not by itself need a regeneration pass: the committed samples still execute against the root they were captured with.

## How regeneration works

Two commands cover the protocol-circuit tomls, split by whether the sample needs a real client-proved transaction. Both capture circuit inputs during proving via `pushTestData`/`getTestData` and write them with `updateProtocolCircuitSampleInputs(circuitName, TOML.stringify(...))` (`labs/yarn-project/foundation/src/testing/files/index.ts`), which writes `noir-projects/fnd/noir-protocol-circuits/crates/<circuitName>/Prover.toml` under whichever repository root it resolves from — which is no longer this one, see the warning next.

> ⚠️ **The tests that write the tomls no longer live in the repository that holds them.** `getPathToFile` derives the repository root from the calling module's own location, so a run inside the submodule targets `labs/noir-projects/fnd/noir-protocol-circuits/crates/<circuitName>/Prover.toml`. The submodule has no `noir-projects/fnd` — it consumes the compiled circuits as the `@aztec-foundation/protocol-circuits-artifacts` package rather than as a source tree — so the write fails there instead of updating the tomls committed here. As a local stopgap, point the missing directory at this repository before running either command, and remove it afterwards so it does not sit untracked in the submodule:
>
> ```bash
> ln -s ../../noir-projects/fnd labs/noir-projects/fnd   # ... regenerate ... then: rm labs/noir-projects/fnd
> ```

### Block-root and above rollup circuits — prover-client suite

`labs/yarn-project/prover-client/src/test/regenerate_rollup_sample_inputs.test.ts` drives representative epochs through the simulated orchestrator and dumps each rollup circuit's captured input. The whole suite is `describe.skip`ped unless `AZTEC_GENERATE_TEST_DATA=1`, and it needs no L1 sandbox.

```bash
AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec-labs/prover-client test regenerate_rollup_sample_inputs
```

Regenerates every block-root variant plus the block-merge, checkpoint-root, checkpoint-merge, tx-merge and root tomls. Take the exact inventory from the `scenarios` array in that test rather than from a list here: each scenario's `dump` field names the tomls it owns, and the set changes whenever a block-root variant is added or removed.

### Private-kernel and transaction-base circuits — e2e prover full test

`full.test.ts` has a test "generates sample Prover.toml files if generate test data is on". It early-returns unless **both** `AZTEC_GENERATE_TEST_DATA=1` (enables `isGenerateTestDataEnabled()`) and fake proofs (`FAKE_PROOFS=1`, i.e. `REAL_PROOFS` is false) are set. These circuits need real client-proved transactions, which the simulated orchestrator suite above cannot produce.

From the repo root:

```bash
AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 labs/yarn-project/end-to-end/scripts/run_test.sh simple single-node/prover/server/full
```

(Equivalently, from `labs/yarn-project/end-to-end`: `AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn test:e2e single-node/prover/server/full.test`.) This is a full-stack run (L1 anvil + node + prover), ~15 min with fake proofs.

Regenerates:

- `private-kernel-init`, `private-kernel-init-2` … `private-kernel-init-5`
- `private-kernel-inner`, `private-kernel-inner-2` … `private-kernel-inner-5`
- `private-kernel-reset-tail`, `private-kernel-reset-tail-to-public` (the terminal resets — these run as part of every tx's tail)
- `rollup-tx-base-private`, `rollup-tx-base-public`

The circuit list lives in the `forEach(circuitName => ...)` loop in `full.test.ts`. `private-kernel-reset` (the **inner** reset) is deliberately **commented out** of this list and is **not** generated by the test — see the exception below.

After either run, review and stage the changed tomls with `git diff noir-projects/fnd/noir-protocol-circuits/crates/*/Prover.toml`. If you add a new circuit crate, add its name to the appropriate list so its toml gets generated.

## ⚠️ Exception: `private-kernel-reset/Prover.toml` (inner reset) is NOT generated — hand-maintain it

The inner reset is **not regenerated by `full.test.ts` at all**: `'private-kernel-reset'` is commented out of the circuit list and no flow produces it. So the bulk regeneration command above leaves this one toml untouched — when a change affects it, you edit `crates/private-kernel-reset/Prover.toml` **by hand**.

**Figuring out the change.** Whatever change triggered the regeneration of the other tomls almost always applies to the reset toml too, in the same shape. So:

1. Run the regeneration command and look at the diffs to the generated tomls (`git diff noir-projects/fnd/noir-protocol-circuits/crates/*/Prover.toml`) — especially the closely-related `private-kernel-reset-tail` / `private-kernel-reset-tail-to-public`.
2. Apply the analogous edit by hand to `private-kernel-reset/Prover.toml` (e.g. mirror a renamed/added/removed field, an adjusted array length, or a changed constant).
3. Verify it executes (see below) before committing.

When the edit isn't obvious from the other diffs, a known-good earlier version of this same toml (e.g. `git show origin/next:noir-projects/fnd/noir-protocol-circuits/crates/private-kernel-reset/Prover.toml`) is the reference for the surrounding structure; splice in only the section that needs to change.

### Fallback: regenerate a fresh reset toml with the test

If the change is too large to hand-apply (e.g. a reset ABI/layout change), or if there is no Prover.toml to modify, capture a fresh sample by temporarily re-enabling the inner-reset flow:

1. In `full.test.ts`, re-add a flow that forces an inner reset — a `PendingNoteHashesContract.test_recursively_create_notes` tx that emits more notes than a reset dimension can hold — and uncomment `'private-kernel-reset'` in the circuit list.
2. Run the regeneration command above; this now writes `private-kernel-reset/Prover.toml`.
3. **Revert the `full.test.ts` edits** — do not commit the re-enabled flow.

> ⚠️ **Disclaimer: zero out the key-validation requests in the captured toml.** The captured inner reset does not verify the key-validation requests it carries (it has no master secret keys for them), but the full max-dimension `private-kernel-reset` circuit verifies all of them — so the raw captured toml fails `nargo execute`. After capturing, empty the key-validation requests (set their claimed length to zero and clear their array entries) so the verify loop runs over nothing. Confirm with the verify step below.

## Verify

For the reset toml (and any other you touched), confirm it solves before committing. `$NARGO` defaults to `noir/noir-repo/target/release/nargo`:

```bash
noir/noir-repo/target/release/nargo execute \
  --program-dir noir-projects/fnd/noir-protocol-circuits/crates/private-kernel-reset \
  --silence-warnings --skip-brillig-constraints-check
```

Success prints `Circuit witness successfully solved`. This is the same check CI runs, so a clean local execute means the execute test will pass.