chore: upgrade aztec to v4.2.0-nightly.20260408-1 by 0xShaito · Pull Request #324 · defi-wonderland/aztec-standards

0xShaito · 2026-04-01T05:13:01Z

Summary

Upgraded all Aztec dependencies from v4.2.0-nightly.20260407 to v4.2.0-nightly.20260408-1
Updated Nargo.toml git tags across all contract packages
Updated test assertion for changed error message in nullifier witness check
Added @aztec/aztec devDependency for CLI tooling

Changes

package.json: Bumped all @aztec/* dependencies, config.aztecVersion, and resolutions to 4.2.0-nightly.20260408-1; added @aztec/aztec devDependency
src/token_contract/Nargo.toml: Updated 4 aztec git dependency tags
src/vault_contract/Nargo.toml: Updated aztec git dependency tag
src/dripper/Nargo.toml: Updated aztec git dependency tag
src/nft_contract/Nargo.toml: Updated 2 aztec git dependency tags
src/escrow_contract/Nargo.toml: Updated 2 aztec git dependency tags
src/escrow_contract/src/test/test_logic_contract/Nargo.toml: Updated aztec git dependency tag
src/generic_proxy/Nargo.toml: Updated aztec git dependency tag
src/token_contract/src/test/transfer_private_to_commitment.nr: Updated should_fail_with message to match new nullifier error format
.aztecrc: Updated version to 4.2.0-nightly.20260408-1
yarn.lock: Updated lockfile for new dependency versions

Test plan

Contracts compile successfully (yarn ccc)
Noir unit tests pass (yarn test:nr)
TypeScript integration tests pass (yarn test:js)

https://claude.ai/code/session_01JWkKLzm777Be6PZHWKeTPM

The aztec-benchmark repo does not have a 4.1.0 tag, only 4.1.0-rc.4. https://claude.ai/code/session_01JWkKLzm777Be6PZHWKeTPM

https://claude.ai/code/session_01D5wkpiw74Hw2WeMdFjm1vj

…rsion Add resolutions to force @aztec/foundation@4.1.1 across all packages, fixing Fr instanceof check failures from version mismatch between @defi-wonderland/aztec-benchmark (4.1.0-rc.4) and @aztec/* (4.1.1). Also bump package version to 4.1.1 to match Aztec version. https://claude.ai/code/session_01D5wkpiw74Hw2WeMdFjm1vj

https://claude.ai/code/session_01Xt9oZkxddNEmxUmxk1wwJ8

The 4.1.2 tag does not exist in defi-wonderland/aztec-benchmark, so the benchmark CI jobs would fail to start. https://claude.ai/code/session_013YRxPVLkEpwFBYYRjCHMV3

https://claude.ai/code/session_01GLhcwraBdpK1qn5UXEoHGb

qodo-code-review · 2026-04-01T05:13:17Z

Review Summary by Qodo

Upgrade Aztec dependencies to v4.2.0-nightly.20260331

✨ Enhancement

Walkthroughs

Description

• Upgrade all Aztec dependencies from 4.2.0-aztecnr-rc.2 to 4.2.0-nightly.20260331
• Update Nargo.toml git tags across all contract packages
• Update config.aztecVersion to match new Aztec version
• Keep @defi-wonderland/aztec-benchmark at 4.2.0-aztecnr-rc.2 (nightly not published)

Diagram

flowchart LR
  A["package.json"] -- "Update @aztec/* deps" --> B["4.2.0-nightly.20260331"]
  C["Nargo.toml files"] -- "Update git tags" --> B
  D["config.aztecVersion"] -- "Update version" --> B
  E["@defi-wonderland/aztec-benchmark"] -- "Keep at rc.2" --> F["4.2.0-aztecnr-rc.2"]

File Changes

1. package.json Dependencies +9/-9

Update Aztec dependencies and config version

• Updated 8 @aztec/* dependencies from 4.2.0-aztecnr-rc.2 to 4.2.0-nightly.20260331
• Updated config.aztecVersion to 4.2.0-nightly.20260331
• Kept @defi-wonderland/aztec-benchmark at 4.2.0-aztecnr-rc.2

package.json

2. src/token_contract/Nargo.toml Dependencies +4/-4

Update token contract Aztec dependencies
• Updated 4 aztec git dependency tags to v4.2.0-nightly.20260331
• Affected dependencies: aztec, uint_note, balance_set, compressed_string
src/token_contract/Nargo.toml

3. src/nft_contract/Nargo.toml Dependencies +2/-2

Update NFT contract Aztec dependencies
• Updated 2 aztec git dependency tags to v4.2.0-nightly.20260331
• Affected dependencies: aztec, compressed_string
src/nft_contract/Nargo.toml

View more (5)

4. src/escrow_contract/Nargo.toml Dependencies +2/-2

Update escrow contract Aztec dependencies
• Updated 2 aztec git dependency tags to v4.2.0-nightly.20260331
• Affected dependencies: aztec, serde
src/escrow_contract/Nargo.toml

5. src/escrow_contract/src/test/test_logic_contract/Nargo.toml Dependencies +1/-1

Update test logic contract Aztec dependency
• Updated 1 aztec git dependency tag to v4.2.0-nightly.20260331
• Affected dependency: aztec
src/escrow_contract/src/test/test_logic_contract/Nargo.toml

6. src/vault_contract/Nargo.toml Dependencies +1/-1

Update vault contract Aztec dependency
• Updated 1 aztec git dependency tag to v4.2.0-nightly.20260331
• Affected dependency: aztec
src/vault_contract/Nargo.toml

7. src/dripper/Nargo.toml Dependencies +1/-1

Update dripper contract Aztec dependency
• Updated 1 aztec git dependency tag to v4.2.0-nightly.20260331
• Affected dependency: aztec
src/dripper/Nargo.toml

8. src/generic_proxy/Nargo.toml Dependencies +1/-1

Update generic proxy contract Aztec dependency
• Updated 1 aztec git dependency tag to v4.2.0-nightly.20260331
• Affected dependency: aztec
src/generic_proxy/Nargo.toml

qodo-code-review · 2026-04-01T05:13:18Z

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

🐞\ ⛨ Security (1) ⚙ Maintainability (4) ⭐ New (1)

1. Workflow ref not SHA-pinned 🐞 ⛨

Description

The benchmark reusable workflows are referenced by a mutable tag (@4.1.0-rc.4) instead of an
immutable commit SHA, so upstream retagging or compromise can silently change what code runs in CI.
This is higher risk here because these workflows are invoked with inherited secrets/permissions.

Code

.github/workflows/pr-checks.yml[16]

+    uses: defi-wonderland/aztec-benchmark/.github/workflows/pr-benchmark.yml@4.1.0-rc.4

Evidence

pr-checks.yml and update-baseline.yml both use an external repo workflow ref by tag (mutable)
rather than a commit SHA, meaning the executed workflow code can change without a change in this
repo. This repo also inherits secrets for these calls, increasing impact if the upstream ref
changes.

.github/workflows/pr-checks.yml[16-22]
.github/workflows/update-baseline.yml[18-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The reusable workflow calls use a mutable tag (e.g., `@4.1.0-rc.4`). Tags can be moved, so the workflow code executed in CI can change without any PR in this repo.

### Issue Context
These workflows are called with inherited secrets/permissions, which increases the blast radius if the upstream workflow ref is changed.

### Fix Focus Areas
- .github/workflows/pr-checks.yml[16-16]
- .github/workflows/update-baseline.yml[18-18]

### Suggested fix
Update each `uses: defi-wonderland/aztec-benchmark/...@...` to reference an immutable commit SHA (e.g., `@<full_commit_sha>`). Optionally add a comment noting the human-readable tag/version that SHA corresponds to.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Wrong Aztec version pinned~~ ☑ 🐞 ≡

Description

The repo is pinned to Aztec 4.2.0-nightly.20260331 across JS deps, .aztecrc, and Noir Nargo.toml
tags, which does not match the PR’s stated target (v4.1.3) and will pull a different Aztec/Noir API
surface than intended.

Code

package.json[R29-36]

+    "@aztec/accounts": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/noir-contracts.js": "4.2.0-nightly.20260331",
+    "@aztec/protocol-contracts": "4.2.0-nightly.20260331",
+    "@aztec/pxe": "4.2.0-nightly.20260331",
+    "@aztec/stdlib": "4.2.0-nightly.20260331",
+    "@aztec/wallet-sdk": "4.2.0-nightly.20260331",
+    "@aztec/wallets": "4.2.0-nightly.20260331",

Evidence

package.json pins all @aztec/* dependencies and config.aztecVersion to 4.2.0-nightly.20260331;
.aztecrc also contains 4.2.0-nightly.20260331; Noir contracts’ Nargo.toml dependencies are tagged
v4.2.0-nightly.20260331 as well, so the repo is consistently configured for nightly 4.2.0 rather
than 4.1.3.

package.json[24-62]
.aztecrc[1-1]
src/token_contract/Nargo.toml[1-12]
src/dripper/Nargo.toml[1-9]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repository is configured to use Aztec `4.2.0-nightly.20260331` (JS deps, `.aztecrc`, and Noir git tags). If the intended target is `v4.1.3` (per PR metadata), this will fetch the wrong toolchain/APIs.

## Issue Context
Aztec version pins appear in multiple places and need to be updated together to avoid mismatched toolchains.

## Fix Focus Areas
- package.json[24-62]
- .aztecrc[1-1]
- src/token_contract/Nargo.toml[1-12]
- src/dripper/Nargo.toml[1-9]
- src/*/Nargo.toml (all contract packages): update aztec-related `tag = "..."`

## Expected fix
- Change all Aztec pins to the intended version (e.g., `4.1.3` / `v4.1.3`), or if nightly is intended, update PR metadata accordingly.
- Regenerate `yarn.lock` after updating `package.json` versions/resolutions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Benchmark deps overridden~~ ☑ 🐞 ☼

Description

The new Yarn resolutions force @aztec/aztec.js and @aztec/wallets to 4.2.0-nightly.20260331,
causing the lockfile to resolve requests for 4.2.0-aztecnr-rc.2 to the nightly build. This defeats
@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2’s explicit dependency pins (and can break
yarn bench) because it will no longer run against the rc.2 Aztec packages it declares.

Code

package.json[R58-62]

+  "resolutions": {
+    "@aztec/foundation": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/wallets": "4.2.0-nightly.20260331"
+  },

Evidence

package.json introduces global resolutions for @aztec/foundation, @aztec/aztec.js, and
@aztec/wallets. In yarn.lock, both @aztec/aztec.js@4.2.0-aztecnr-rc.2 and
@aztec/aztec.js@4.2.0-nightly.20260331 (and similarly for @aztec/wallets) are collapsed to the
nightly version, proving the override is taking effect. Separately, yarn.lock shows
@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2 declares exact rc.2 dependencies on
@aztec/aztec.js and @aztec/wallets, and package.json exposes a bench script that uses
aztec-benchmark, so this mismatch directly impacts repo workflows.

package.json[58-62]
yarn.lock[598-610]
yarn.lock[967-980]
yarn.lock[1217-1226]
package.json[11-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Global Yarn `resolutions` added for `@aztec/aztec.js` and `@aztec/wallets` override `@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2`’s explicit dependency pins (`4.2.0-aztecnr-rc.2`). As a result, the lockfile resolves the rc.2 requests to the nightly versions, so `aztec-benchmark` won’t run with the Aztec versions it declares.

## Issue Context
- `@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2` declares dependencies on `@aztec/aztec.js` and `@aztec/wallets` at `4.2.0-aztecnr-rc.2`.
- The repo adds global resolutions forcing those packages to nightly, and the lockfile confirms both rc.2 and nightly selectors resolve to nightly.
- The repo uses `aztec-benchmark` via the `bench` script.

## Fix approach options
Pick one:
1) **Remove the global resolutions** for `@aztec/aztec.js` and `@aztec/wallets` so Yarn can install both versions (nightly for the repo, rc.2 nested under `aztec-benchmark`).
2) **Add scoped resolutions for `aztec-benchmark`** to preserve its required versions, e.g.:
  - `"@defi-wonderland/aztec-benchmark/@aztec/aztec.js": "4.2.0-aztecnr-rc.2"`
  - `"@defi-wonderland/aztec-benchmark/@aztec/wallets": "4.2.0-aztecnr-rc.2"`
  while keeping global resolutions for the rest of the tree.
3) **If the intent is to benchmark nightly**, upgrade `@defi-wonderland/aztec-benchmark` to a nightly-compatible release and remove the rc.2 pin.

## Fix Focus Areas
- package.json[58-62]
- yarn.lock[598-601]
- yarn.lock[967-970]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. share_escrow test not executed 🐞 ⚙

Description

share_escrow_success no longer has a #[test] attribute (it’s commented out and replaced with
#[allow(dead_code)]), so the Noir test suite provides no automated coverage for share_escrow;
its header comment also references a "v2.0.3" test environment which is inconsistent with this
repo’s current Aztec versioning.

Code

src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[R9-19]

+// NOTE: This test is disabled because share_escrow validation requires the escrow salt
+// to match the logic contract address, which is not possible in v2.0.3 test environment.
+// The salt check will always fail with "Escrow salt mismatch".
+// Additionally, event emission modules are not accessible in Noir tests.
+// Full share_escrow functionality should be tested in TypeScript integration tests.
+// See: https://github.com/AztecProtocol/aztec-packages/issues/16656
+
+// #[test]
+#[allow(dead_code)]
unconstrained fn share_escrow_success() {
    let mut env = TestEnvironment::new();

Evidence
The function is no longer marked as a test and is explicitly kept as dead code; the surrounding
comment documents the disablement and contains the outdated version reference.
src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-19]
src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[20-39]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`share_escrow_success` is not executed by the Noir test runner because `#[test]` is commented out and the function is retained with `#[allow(dead_code)]`. This removes coverage silently and the comment mentions "v2.0.3" which is misleading in the context of this PR.

### Issue Context
The comment suggests the behavior should be validated via TypeScript integration tests until the upstream test environment supports custom salts/events.

### Fix Focus Areas
- src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-39]

### Suggested fix
- Replace the current pattern with an explicit, discoverable mechanism (depending on what Noir supports in this repo):
 - Prefer `#[test]` + an ignore/skip annotation if available, or a dedicated `#[test(should_fail_with = ...)]` negative test that asserts the known failure mode.
 - Update the header comment to reference the correct Aztec version context (4.x) and/or rely solely on the linked upstream issue.
 - If the test must remain disabled, rename the function/comment to make it clear it’s intentionally not part of the test suite.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. ~~Unchecked address decode fallback~~ ☑ 🐞 ≡

Description

getTransferEvents/getNFTTransferEvents fall back to
AztecAddress.fromField(decoded.{from,to}.inner) without validating that .inner exists and is a
valid Field-like value. If decodeFromAbi returns an address-like value with a different shape (or
a different AztecAddress instance that fails instanceof), this will throw at runtime and break
all event assertions that depend on these helpers.

Code

src/ts/test/utils.ts[R665-669]

+      const decoded = decodeFromAbi([eventMetadata.abiType], eventFields) as any;
+      return {
+        from: decoded.from instanceof AztecAddress ? decoded.from : AztecAddress.fromField(decoded.from.inner),
+        to: decoded.to instanceof AztecAddress ? decoded.to : AztecAddress.fromField(decoded.to.inner),
+        amount: decoded.amount,

Evidence

The new decoding logic uses as any and relies on instanceof AztecAddress and then
unconditionally accesses .inner on the fallback path for both Transfer and NFT Transfer events;
there is no guard or error message if .inner is missing or malformed. These helpers feed directly
into expectTransferEvents/expectNFTTransferEvents which compare from/to as AztecAddress
values, so a decode failure here fails many tests at once.

src/ts/test/utils.ts[649-671]
src/ts/test/utils.ts[719-742]
src/ts/test/utils.ts[635-639]
src/ts/test/utils.ts[705-709]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getTransferEvents` and `getNFTTransferEvents` decode `from`/`to` using a brittle runtime check:
- If not `instanceof AztecAddress`, they assume `decoded.{from,to}.inner` exists and can be passed to `AztecAddress.fromField(...)`.
- If the decoded value has a different runtime shape, the code will throw (or construct the wrong address), breaking event assertions.

## Issue Context
This code is in test utilities, but it is a high-fanout helper used across many TS integration tests.

## Fix Focus Areas
- src/ts/test/utils.ts[665-670]
- src/ts/test/utils.ts[735-740]

## Suggested fix
1. Add a small `normalizeAztecAddress(value: unknown): AztecAddress` helper and use it in both functions.
2. In the helper, handle explicitly (and safely):
  - `value instanceof AztecAddress`
  - `value` shaped like `{ inner: ... }` (only if `inner` exists)
  - optionally `value` being a Field/Fr-like directly
3. If the value does not match any supported shape, throw an error with a clear message including `typeof value` and available keys, so failures are diagnosable.
4. Use the helper for both `from` and `to` to avoid duplicated brittle logic.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Dead asserts after failure 🐞 ⚙

Description

In get_escrow_correct_instance, the test is configured to fail with "Incorrect escrow deployed" and
the first assert_eq uses exactly that message, so the subsequent ContractInstance assertions are
effectively dead code under the intended failure path. This makes the test misleading because it
looks like it validates salt/deployer/class id/public keys, but it cannot reach those checks if the
expected failure occurs at the first assert.

Code

src/escrow_contract/src/test/test_logic_contract/src/test/get_escrow.nr[R18-38]

+#[test(should_fail_with = "Incorrect escrow deployed")]
unconstrained fn get_escrow_correct_instance() {
    let mut env = TestEnvironment::new();

+    let secret = 1;
    let (public_keys, secret_key, _, _) = logic_utils::get_test_vector();

+    let deployed_escrow = escrow_utils::deploy_escrow_with_secret(&mut env, secret);
+
    let escrow_class_id = escrow_utils::get_escrow_class_id();
-    let logic = logic_utils::deploy_logic(&mut env, escrow_class_id);

-    let deployed_escrow = escrow_utils::deploy_escrow_with_secret(&mut env, secret_key, logic);
+    let logic = logic_utils::deploy_logic(&mut env, escrow_class_id);

    let caller = env.create_light_account();
    let escrow = env.call_private(caller, TestLogic::at(logic).get_escrow(secret_key));
    assert_eq(deployed_escrow, escrow, "Incorrect escrow deployed");

-    let escrow_instance: ContractInstance = env.utility_context(|_| get_contract_instance(escrow));
+    let escrow_instance: ContractInstance = get_contract_instance(escrow);

    assert_eq(escrow_instance.salt, logic.to_field(), "Salt is not the logic contract");
    assert_eq(escrow_instance.deployer, AztecAddress::from_field(0), "Deployer is not zero");

Evidence

The test is annotated to expect a failure with the string "Incorrect escrow deployed", and the first
failing condition is an assert_eq that uses that same message; any later assertions
(salt/deployer/class id/initialization_hash/public_keys) only run if that first assert unexpectedly
does not fail, and in that scenario the test would likely fail with a different message than the one
required by should_fail_with.

src/escrow_contract/src/test/test_logic_contract/src/test/get_escrow.nr[18-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_escrow_correct_instance` is an expected-failure test (`#[test(should_fail_with = "Incorrect escrow deployed")]`) but it contains multiple follow-up assertions that appear to validate the escrow instance fields. Under the intended path (first `assert_eq` failing with the expected message), those follow-up assertions will not be evaluated, which is misleading.

### Issue Context
This test is currently being used to document a limitation in the test environment (custom salt not supported). The extra assertions suggest additional validation that will not happen if the test fails where it is expected to.

### Fix Focus Areas
- src/escrow_contract/src/test/test_logic_contract/src/test/get_escrow.nr[18-46]

### Suggested fix
Either:
1) Remove the post-failure assertions, keeping only the assertion that is meant to fail; or
2) Split into separate tests:
  - one `should_fail_with` test that asserts the address mismatch,
  - another (currently `#[allow(dead_code)]`/disabled) test that would validate instance fields once the environment supports deploying with custom salt.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (3)

7. ~~Escrow salt auth mismatch~~ ☑ 🐞 ≡

Description

Escrow._assert_msg_sender authorizes based on ContractInstance.salt, and the Logic library
computes the escrow address assuming salt == logic contract address, but the updated
deploy_escrow_with_secret helper no longer supplies any salt/alignment mechanism. As a result, any
flow that deploys via this helper and then calls Escrow from a Logic contract will fail
authorization or compute a different escrow address than the one deployed.

Code

src/escrow_contract/src/test/utils.nr[R39-43]

    let _escrow_contract = ContractDeployment {
        env: *env,
        path: "@escrow_contract/Escrow",
        secret: escrow_secret,
-        salt: 0,
    };

Evidence

The Escrow contract enforces msg_sender == AztecAddress::from_field(escrow_instance.salt) during
private withdrawals. Separately, the Logic library derives the escrow address by constructing a
ContractInstance where salt is explicitly set to context.this_address() (the Logic contract
address), meaning deployments must match this salt to be callable by that Logic contract and to make
_get_escrow compute the deployed address. After this PR, the test deploy helper no longer has a
salt field at all, so it cannot produce an escrow instance whose salt matches the Logic contract
address assumption used throughout the repo’s escrow/logic pattern.

src/escrow_contract/src/test/utils.nr[30-46]
src/escrow_contract/src/main.nr[44-50]
src/escrow_contract/src/library/logic.nr[31-48]
src/escrow_contract/src/test/withdraw.nr[20-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Escrow authorization uses `ContractInstance.salt` as the allowed caller address, and the Logic library computes escrow addresses assuming `salt == logic contract address`. After the Aztec v4.1.3 upgrade, the test deployment helper no longer allows setting salt, so the deployed escrow instance can’t be aligned with the Logic contract, breaking (or permanently preventing) the intended Logic→Escrow calling pattern.

### Issue Context
- Escrow checks authorization by reading its own `ContractInstance.salt` and comparing it to `msg_sender`.
- Logic library `_get_escrow` constructs an instance with `salt = context.this_address()` to derive the deterministic escrow address.
- The updated test deploy helper no longer sets salt, so deployed escrow instances won’t match what `_get_escrow` computes and won’t authorize Logic callers.

### Fix Focus Areas
- src/escrow_contract/src/test/utils.nr[30-46]
- src/escrow_contract/src/main.nr[44-50]
- src/escrow_contract/src/library/logic.nr[31-48]

### What to change
Pick one approach:
1) **Deployment-alignment approach (preferred if Aztec test env supports it):** update `deploy_escrow_with_secret` to accept a `salt` (logic address) and use the correct v4.1.3 deploy/cheatcode API that can deploy with that salt (or deploy from the logic contract context if that’s the supported mechanism).
2) **Authorization-model approach:** stop using `ContractInstance.salt` for authorization; store the authorized Logic address in contract storage (set during constructor/initializer) and compare `msg_sender` against that stored address instead. Ensure `_get_escrow` is updated accordingly (or no longer depends on salt for authorization semantics).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

8. ~~Package version not bumped~~ ☑ 🐞 ⚙

Description

The repo upgrades Aztec dependencies/config to 4.2.0-nightly.20260331, but package.json "version" is
still 4.2.0-aztecnr-rc.2, which makes the published artifact version misleading and will fail the
Production Release workflow’s input-version validation when trying to release the upgraded build.
This can block releases or cause consumers to install a package version that doesn’t reflect the
Aztec dependency set it was built against.

Code

package.json[53]

+    "aztecVersion": "4.2.0-nightly.20260331"

Evidence

package.json still declares the package version as rc.2 while config.aztecVersion is nightly; the
production release workflow explicitly compares the manual input to package.json.version and fails
if they differ, so leaving the version unchanged prevents releasing a nightly-upgrade under a
consistent version string.

package.json[1-4]
package.json[50-54]
.github/workflows/release.yml[46-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This PR upgrades Aztec deps/config to `4.2.0-nightly.20260331`, but `package.json.version` is still `4.2.0-aztecnr-rc.2`. This makes the package metadata inconsistent with the dependency set and blocks the Production Release workflow’s version validation.

## Issue Context
The Production Release workflow compares the workflow input to `require('./package.json').version` and exits non-zero on mismatch.

## Fix Focus Areas
- package.json[1-4]
- package.json[50-54]
- .github/workflows/release.yml[46-55]

## Suggested fix
Update `package.json.version` to the intended release version for this upgrade (e.g., `4.2.0-nightly.20260331` or whatever versioning scheme you use for nightly-based releases), ensuring it matches the value you’ll pass to the release workflow.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. ~~Dual Aztec dependency trees~~ ☑ 🐞 ☼

Description

Because @defi-wonderland/aztec-benchmark remains pinned to 4.2.0-aztecnr-rc.2 while this PR upgrades
all top-level @aztec/* deps to 4.2.0-nightly.20260331, Yarn installs both rc.2 and nightly copies of
@aztec/aztec.js/@aztec/wallets. This creates a high risk of benchmark runtime/type incompatibilities
and duplicated singletons because the benchmark scripts import Aztec types from the nightly packages
while the benchmark runner pulls rc.2 Aztec packages.

Code

package.json[R29-37]

+    "@aztec/accounts": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/noir-contracts.js": "4.2.0-nightly.20260331",
+    "@aztec/protocol-contracts": "4.2.0-nightly.20260331",
+    "@aztec/pxe": "4.2.0-nightly.20260331",
+    "@aztec/stdlib": "4.2.0-nightly.20260331",
+    "@aztec/wallet-sdk": "4.2.0-nightly.20260331",
+    "@aztec/wallets": "4.2.0-nightly.20260331",
    "@defi-wonderland/aztec-benchmark": "4.2.0-aztecnr-rc.2",

Evidence

package.json now mixes nightly @aztec/* with an rc.2 aztec-benchmark; yarn.lock confirms both
versions of @aztec/aztec.js are installed simultaneously and that aztec-benchmark depends on the
rc.2 Aztec packages. The benchmark entrypoints import Aztec types from @aztec/aztec.js directly, so
they will run in a process where both copies can exist, which is a common source of instance/type
mismatches and singleton duplication issues.

package.json[28-39]
yarn.lock[610-643]
yarn.lock[1621-1630]
benchmarks/token_contract.benchmark.ts[1-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`@defi-wonderland/aztec-benchmark` is pinned to `4.2.0-aztecnr-rc.2` while the repo upgrades all top-level `@aztec/*` packages to `4.2.0-nightly.20260331`, which causes two Aztec dependency trees to be installed (`rc.2` + `nightly`). This is risky for benchmark execution because the benchmark runner and the benchmark scripts may each load different copies of Aztec classes/singletons.

## Issue Context
- `yarn.lock` shows both `@aztec/aztec.js@4.2.0-aztecnr-rc.2` and `@aztec/aztec.js@4.2.0-nightly.20260331`.
- `@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2` depends on `@aztec/aztec.js` and `@aztec/wallets` at `rc.2`.

## Fix Focus Areas
- package.json[28-40]
- yarn.lock[610-643]
- yarn.lock[1621-1630]

## Suggested fix options
1) If possible, upgrade `@defi-wonderland/aztec-benchmark` to a version built against `4.2.0-nightly.20260331`.
2) If a nightly benchmark package is not published yet, add `resolutions` to force the benchmark package’s transitive `@aztec/*` dependencies to resolve to `4.2.0-nightly.20260331`, and validate `yarn bench` works.
3) Alternatively, keep the whole repo on `4.2.0-aztecnr-rc.2` until a matching benchmark release exists (to avoid mixed trees).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. Stale upgrade target text 🐞 ⚙ ⭐

Description

The newly added .aztecrc pins Aztec 4.2.0-nightly.20260408-1, but the PR title/summary still
refer to 4.2.0-nightly.20260407, leaving ambiguous which nightly was actually upgraded. This makes
the upgrade harder to audit and can confuse future debugging/repro attempts.

Code

.aztecrc[1]
+4.2.0-nightly.20260408-1

Evidence

The repository is now explicitly pinned to 4.2.0-nightly.20260408-1 via .aztecrc (and
package.json), while the PR-provided title/description text states a different nightly
(...20260407).

.aztecrc[1-1]
package.json[28-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`.aztecrc` pins Aztec `4.2.0-nightly.20260408-1`, but the PR title/summary text says the upgrade target is `...20260407`.

### Issue Context
This is a metadata/documentation mismatch, but it impacts traceability and reproducibility when auditing upgrades.

### Fix Focus Areas
- .aztecrc[1-1]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. Stale version in comment 🐞 ⚙

Description

The disabled share_escrow_success test comment references a "v2.0.3 test environment", which does
not match this repository’s Aztec dependency context (this PR moves to 4.1.3). This stale version
reference can mislead maintainers about which environment/version actually has the limitation being
described.

Code

src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[R9-14]

+// NOTE: This test is disabled because share_escrow validation requires the escrow salt
+// to match the logic contract address, which is not possible in v2.0.3 test environment.
+// The salt check will always fail with "Escrow salt mismatch".
+// Additionally, event emission modules are not accessible in Noir tests.
+// Full share_escrow functionality should be tested in TypeScript integration tests.
+// See: https://github.com/AztecProtocol/aztec-packages/issues/16656

Evidence

The comment explicitly says the limitation is due to the "v2.0.3 test environment" even though this
PR changes Aztec dependencies/config to the 4.x line (4.1.3). Keeping a mismatched version number in
the rationale makes the TODO harder to trust when revisiting later.

src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-14]
package.json[26-63]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A disabled test comment references a "v2.0.3 test environment" even though the project is on Aztec 4.x. This is likely a stale copy/paste and can mislead future maintenance.

### Issue Context
The comment’s main value is describing why the test is disabled (salt mismatch and event modules not accessible). The specific version number appears incorrect/outdated.

### Fix Focus Areas
- src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-14]

### Suggested fix
Update the comment to either:
- reference the current Aztec/TestEnvironment version context (4.1.3), or
- remove the explicit version number entirely and keep only the capability limitation description + issue link.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Previous review results

Review updated until commit be7ff50

Results up to commit N/A

🐞 Bugs (4)
📘 Rule violations (0)
📎 Requirement gaps (0)
🎨 UX Issues (0)

🐞\ ⛨ Security (1) ⚙ Maintainability (3)

1. Workflow ref not SHA-pinned 🐞 ⛨

Description

The benchmark reusable workflows are referenced by a mutable tag (@4.1.0-rc.4) instead of an
immutable commit SHA, so upstream retagging or compromise can silently change what code runs in CI.
This is higher risk here because these workflows are invoked with inherited secrets/permissions.

Code

.github/workflows/pr-checks.yml[16]

+    uses: defi-wonderland/aztec-benchmark/.github/workflows/pr-benchmark.yml@4.1.0-rc.4

Evidence

pr-checks.yml and update-baseline.yml both use an external repo workflow ref by tag (mutable)
rather than a commit SHA, meaning the executed workflow code can change without a change in this
repo. This repo also inherits secrets for these calls, increasing impact if the upstream ref
changes.

.github/workflows/pr-checks.yml[16-22]
.github/workflows/update-baseline.yml[18-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The reusable workflow calls use a mutable tag (e.g., `@4.1.0-rc.4`). Tags can be moved, so the workflow code executed in CI can change without any PR in this repo.

### Issue Context
These workflows are called with inherited secrets/permissions, which increases the blast radius if the upstream workflow ref is changed.

### Fix Focus Areas
- .github/workflows/pr-checks.yml[16-16]
- .github/workflows/update-baseline.yml[18-18]

### Suggested fix
Update each `uses: defi-wonderland/aztec-benchmark/...@...` to reference an immutable commit SHA (e.g., `@<full_commit_sha>`). Optionally add a comment noting the human-readable tag/version that SHA corresponds to.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Wrong Aztec version pinned~~ ☑ 🐞 ≡

Description

The repo is pinned to Aztec 4.2.0-nightly.20260331 across JS deps, .aztecrc, and Noir Nargo.toml
tags, which does not match the PR’s stated target (v4.1.3) and will pull a different Aztec/Noir API
surface than intended.

Code

package.json[R29-36]

+    "@aztec/accounts": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/noir-contracts.js": "4.2.0-nightly.20260331",
+    "@aztec/protocol-contracts": "4.2.0-nightly.20260331",
+    "@aztec/pxe": "4.2.0-nightly.20260331",
+    "@aztec/stdlib": "4.2.0-nightly.20260331",
+    "@aztec/wallet-sdk": "4.2.0-nightly.20260331",
+    "@aztec/wallets": "4.2.0-nightly.20260331",

Evidence

package.json pins all @aztec/* dependencies and config.aztecVersion to 4.2.0-nightly.20260331;
.aztecrc also contains 4.2.0-nightly.20260331; Noir contracts’ Nargo.toml dependencies are tagged
v4.2.0-nightly.20260331 as well, so the repo is consistently configured for nightly 4.2.0 rather
than 4.1.3.

package.json[24-62]
.aztecrc[1-1]
src/token_contract/Nargo.toml[1-12]
src/dripper/Nargo.toml[1-9]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repository is configured to use Aztec `4.2.0-nightly.20260331` (JS deps, `.aztecrc`, and Noir git tags). If the intended target is `v4.1.3` (per PR metadata), this will fetch the wrong toolchain/APIs.

## Issue Context
Aztec version pins appear in multiple places and need to be updated together to avoid mismatched toolchains.

## Fix Focus Areas
- package.json[24-62]
- .aztecrc[1-1]
- src/token_contract/Nargo.toml[1-12]
- src/dripper/Nargo.toml[1-9]
- src/*/Nargo.toml (all contract packages): update aztec-related `tag = "..."`

## Expected fix
- Change all Aztec pins to the intended version (e.g., `4.1.3` / `v4.1.3`), or if nightly is intended, update PR metadata accordingly.
- Regenerate `yarn.lock` after updating `package.json` versions/resolutions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Benchmark deps overridden~~ ☑ 🐞 ☼

Description

The new Yarn resolutions force @aztec/aztec.js and @aztec/wallets to 4.2.0-nightly.20260331,
causing the lockfile to resolve requests for 4.2.0-aztecnr-rc.2 to the nightly build. This defeats
@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2’s explicit dependency pins (and can break
yarn bench) because it will no longer run against the rc.2 Aztec packages it declares.

Code

package.json[R58-62]

+  "resolutions": {
+    "@aztec/foundation": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/wallets": "4.2.0-nightly.20260331"
+  },

Evidence

package.json introduces global resolutions for @aztec/foundation, @aztec/aztec.js, and
@aztec/wallets. In yarn.lock, both @aztec/aztec.js@4.2.0-aztecnr-rc.2 and
@aztec/aztec.js@4.2.0-nightly.20260331 (and similarly for @aztec/wallets) are collapsed to the
nightly version, proving the override is taking effect. Separately, yarn.lock shows
@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2 declares exact rc.2 dependencies on
@aztec/aztec.js and @aztec/wallets, and package.json exposes a bench script that uses
aztec-benchmark, so this mismatch directly impacts repo workflows.

package.json[58-62]
yarn.lock[598-610]
yarn.lock[967-980]
yarn.lock[1217-1226]
package.json[11-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Global Yarn `resolutions` added for `@aztec/aztec.js` and `@aztec/wallets` override `@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2`’s explicit dependency pins (`4.2.0-aztecnr-rc.2`). As a result, the lockfile resolves the rc.2 requests to the nightly versions, so `aztec-benchmark` won’t run with the Aztec versions it declares.

## Issue Context
- `@defi-wonderland/aztec-benchmark@4.2.0-aztecnr-rc.2` declares dependencies on `@aztec/aztec.js` and `@aztec/wallets` at `4.2.0-aztecnr-rc.2`.
- The repo adds global resolutions forcing those packages to nightly, and the lockfile confirms both rc.2 and nightly selectors resolve to nightly.
- The repo uses `aztec-benchmark` via the `bench` script.

## Fix approach options
Pick one:
1) **Remove the global resolutions** for `@aztec/aztec.js` and `@aztec/wallets` so Yarn can install both versions (nightly for the repo, rc.2 nested under `aztec-benchmark`).
2) **Add scoped resolutions for `aztec-benchmark`** to preserve its required versions, e.g.:
  - `"@defi-wonderland/aztec-benchmark/@aztec/aztec.js": "4.2.0-aztecnr-rc.2"`
  - `"@defi-wonderland/aztec-benchmark/@aztec/wallets": "4.2.0-aztecnr-rc.2"`
  while keeping global resolutions for the rest of the tree.
3) **If the intent is to benchmark nightly**, upgrade `@defi-wonderland/aztec-benchmark` to a nightly-compatible release and remove the rc.2 pin.

## Fix Focus Areas
- package.json[58-62]
- yarn.lock[598-601]
- yarn.lock[967-970]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. share_escrow test not executed 🐞 ⚙

Description

share_escrow_success no longer has a #[test] attribute (it’s commented out and replaced with
#[allow(dead_code)]), so the Noir test suite provides no automated coverage for share_escrow;
its header comment also references a "v2.0.3" test environment which is inconsistent with this
repo’s current Aztec versioning.

Code

src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[R9-19]

+// NOTE: This test is disabled because share_escrow validation requires the escrow salt
+// to match the logic contract address, which is not possible in v2.0.3 test environment.
+// The salt check will always fail with "Escrow salt mismatch".
+// Additionally, event emission modules are not accessible in Noir tests.
+// Full share_escrow functionality should be tested in TypeScript integration tests.
+// See: https://github.com/AztecProtocol/aztec-packages/issues/16656
+
+// #[test]
+#[allow(dead_code)]
unconstrained fn share_escrow_success() {
    let mut env = TestEnvironment::new();

Evidence
The function is no longer marked as a test and is explicitly kept as dead code; the surrounding
comment documents the disablement and contains the outdated version reference.
src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-19]
src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[20-39]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`share_escrow_success` is not executed by the Noir test runner because `#[test]` is commented out and the function is retained with `#[allow(dead_code)]`. This removes coverage silently and the comment mentions "v2.0.3" which is misleading in the context of this PR.

### Issue Context
The comment suggests the behavior should be validated via TypeScript integration tests until the upstream test environment supports custom salts/events.

### Fix Focus Areas
- src/escrow_contract/src/test/test_logic_contract/src/test/share_escrow.nr[9-39]

### Suggested fix
- Replace the current pattern with an explicit, discoverable mechanism (depending on what Noir supports in this repo):
 - Prefer `#[test]` + an ignore/skip annotation if available, or a dedicated `#[test(should_fail_with = ...)]` negative test that asserts the known failure mode.
 - Update the header comment to reference the correct Aztec version context (4.x) and/or rely solely on the linked upstream issue.
 - If the test must remain disabled, rename the function/comment to make it clear it’s intentionally not part of the test suite.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. ~~Unchecked address decode fallback~~ ☑ 🐞 ≡

Description

getTransferEvents/getNFTTransferEvents fall back to
AztecAddress.fromField(decoded.{from,to}.inner) without validating that .inner exists and is a
valid Field-like value. If decodeFromAbi returns an address-like value with a different shape (or
a different AztecAddress instance that fails instanceof), this will throw at runtime and break
all event assertions that depend on these helpers.

Code

src/ts/test/utils.ts[R665-669]

+      const decoded = decodeFromAbi([eventMetadata.abiType], eventFields) as any;
+      return {
+        from: decoded.from instanceof AztecAddress ? decoded.from : AztecAddress.fromField(decoded.from.inner),
+        to: decoded.to instanceof AztecAddress ? decoded.to : AztecAddress.fromField(decoded.to.inner),
+        amount: decoded.amount,

Evidence

The new decoding logic uses as any and relies on instanceof AztecAddress and then
unconditionally accesses .inner on the fallback path for both Transfer and NFT Transfer events;
there is no guard or error message if .inner is missing or malformed. These helpers feed directly
into expectTransferEvents/expectNFTTransferEvents which compare from/to as AztecAddress
values, so a decode failure here fails many tests at once.

src/ts/test/utils.ts[649-671]
src/ts/test/utils.ts[719-742]
src/ts/test/utils.ts[635-639]
src/ts/test/utils.ts[705-709]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getTransferEvents` and `getNFTTransferEvents` decode `from`/`to` using a brittle runtime check:
- If not `instanceof AztecAddress`, they assume `decoded.{from,to}.inner` exists and can be passed to `AztecAddress.fromField(...)`.
- If the decoded value has a different runtime shape, the code will throw (or construct the wrong address), breaking event assertions.

## Issue Context
This code is in test utilities, but it is a high-fanout helper used across many TS integration tests.

## Fix Focus Areas
- src/ts/test/utils.ts[665-670]
- src/ts/test/utils.ts[735-740]

## Suggested fix
1. Add a small `normalizeAztecAddress(value: unknown): AztecAddress` helper and use it in both functions.
2. In the helper, handle explicitly (and safely):
  - `value instanceof AztecAddress`
  - `value` shaped like `{ inner: ... }` (only if `inner` exists)
  - optionally `value` being a Field/Fr-like directly
3. If the value does not match any supported shape, throw an error with a clear message including `typeof value` and available keys, so failures are diagnosable.
4. Use the helper for both `from` and `to` to avoid duplicated brittle logic.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. Dead asserts after failure 🐞 ⚙

Description

In get_escrow_correct_instance, the test is configured to fail with "Incorrect escrow deployed" and
the first assert_eq uses exactly that message, so the subsequent ContractInstance assertions are
effectively dead code under the intended failure path. This makes the test misleading because it
looks like it validates salt/deployer/class id/public keys, but it cannot reach those checks if the
expected failure occurs at the first assert.

Code

src/escrow_contract/src/test/test_logic_contract/src/test/get_escrow.nr[R18-38]

+#[test(should_fail_with = "Incorrect escrow deployed")]
unconstrained fn get_escrow_correct_instance() {
    let mut env = TestEnvironment::new();

+    let secret = 1;
    let (public_keys, secret_key, _, _) = logic_utils::get_test_vector();

+    let deployed_escrow = escrow_utils::deploy_escrow_with_secret(&mut env, secret);
+
    let escrow_class_id = escrow_utils::get_escrow_class_id();
-    let logic = logic_utils::deploy_logic(&mut env, escrow_class_id);

-    let deployed_escrow = escrow_utils::deploy_escrow_with_secret(&mut env, secret_key, logic);
+    let logic = logic_utils::deploy_logic(&mut env, escrow_class_id);

    let caller = env.create_light_account();
    let escrow = env.call_private(caller, TestLogic::at(logic).get_escrow(secret_key));
    assert_eq(deployed_escrow, escrow, "Incorrect escrow deployed");

-    let escrow_instance: ContractInstance = env.utility_context(|_| get_contract_instance(escrow));
+    let escrow_instance: ContractInstance = get_contract_instance(escrow);

    assert_eq(escrow_instance.salt, logic.to_field(), "Salt is not the logic contract");
    assert_eq(escrow_instance.deployer, AztecAddress::from_field(0), "Deployer is not zero");

Evidence

The test is annotated to expect a failure with the string "Incorrect escrow deployed", and the first
failing condition is an assert_eq that uses that same message; any later assertions
(salt/deployer/class id/initialization_hash/public_keys) only run if that first assert unexpectedly
does not fail, and in that scenario the test would likely fail with a different message than the one
required by should_fail_with.

src/escrow_contract/src/test/test_logic_contract/src/test/get_escrow.nr[18-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_escrow_correct_instance` is an expected-failure test (`#[test(should_fail_with = "Incorrect escrow deployed")]`) but it contains multiple follow-up assertions that appear to validate the escrow instance fields. Under the intended path (first `assert_eq` failing with the expected message), those follow-up assertions will not be evaluated, which is misleading.

### Issue Context
This test is currently be...

cubic-dev-ai

No issues found across 9 files

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a9baf8313d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-01T05:17:29Z

package.json

+    "@aztec/accounts": "4.2.0-nightly.20260331",
+    "@aztec/aztec.js": "4.2.0-nightly.20260331",
+    "@aztec/noir-contracts.js": "4.2.0-nightly.20260331",
+    "@aztec/protocol-contracts": "4.2.0-nightly.20260331",
+    "@aztec/pxe": "4.2.0-nightly.20260331",


Keep benchmark and Aztec deps on a single version

Bumping the core @aztec/* packages to 4.2.0-nightly.20260331 while leaving @defi-wonderland/aztec-benchmark on 4.2.0-aztecnr-rc.2 reintroduces two Aztec dependency trees (the lockfile now contains both @aztec/foundation@4.2.0-aztecnr-rc.2 and @aztec/foundation@4.2.0-nightly.20260331). The benchmark suite mixes imports from both sides (Benchmark from @defi-wonderland/aztec-benchmark and Aztec types from @aztec/*), which causes runtime type identity mismatches (e.g., instanceof Fr) and breaks yarn bench/benchmark CI. Please align versions or add a resolutions pin so only one Aztec stack is installed.

Useful? React with 👍 / 👎.

The @defi-wonderland/aztec-benchmark package pins older @aztec/* versions, causing two @aztec/foundation trees and Fr type identity mismatches at runtime. https://claude.ai/code/session_01GLhcwraBdpK1qn5UXEoHGb

qodo-code-review · 2026-04-01T05:20:35Z

Persistent review updated to latest commit 00447d1

cubic-dev-ai

0 issues found across 2 files (changes from recent commits).

package.json

qodo-code-review · 2026-04-02T04:41:33Z

Persistent review updated to latest commit 4a439a0

cubic-dev-ai

0 issues found across 9 files (changes from recent commits).

qodo-code-review · 2026-04-03T05:21:18Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

ⓘ The new review experience is currently in Beta. Learn more

qodo-code-review · 2026-04-03T05:23:31Z

Persistent review updated to latest commit ab9cd57

cubic-dev-ai

0 issues found across 3 files (changes from recent commits).

The CI setup-aztec action may not properly read config.aztecVersion for nightly versions, causing a v4.1.3 sandbox to run against v4.2.0-nightly contracts and SDK. This file provides an alternative version hint. https://claude.ai/code/session_01GLhcwraBdpK1qn5UXEoHGb

https://claude.ai/code/session_01AXBNqfo4Sv8WNVrzq1gHCH

qodo-code-review · 2026-04-06T06:55:42Z

Persistent review updated to latest commit a1796a8

# Conflicts: # src/escrow_contract/src/test/utils.nr

https://claude.ai/code/session_01M2beEWZtD5qxSwL4rzozfc

qodo-code-review · 2026-04-07T05:23:28Z

Persistent review updated to latest commit 07f6f10

v4.1.3 ContractDeployment does not support the salt field, so tests that depend on deterministic salt-based address derivation cannot work. Reverted test files to pre-merge v4.1.3-compatible versions. https://claude.ai/code/session_01M2beEWZtD5qxSwL4rzozfc

qodo-code-review · 2026-04-07T05:50:23Z

Persistent review updated to latest commit 7485b87

In v4.1.3, the ABI path for AztecAddress changed to aztec_address::AztecAddress which the SDK's isAztecAddressStruct() doesn't recognize. This causes decodeFromAbi to return plain objects instead of AztecAddress instances. Fixed by explicitly constructing AztecAddress from the decoded inner field in event decoders. https://claude.ai/code/session_01M2beEWZtD5qxSwL4rzozfc

qodo-code-review · 2026-04-07T06:09:52Z

Persistent review updated to latest commit de1bd35

…ding" This reverts commit de1bd35.

qodo-code-review · 2026-04-07T06:53:47Z

Persistent review updated to latest commit 3bf734d

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

qodo-code-review · 2026-04-08T04:35:11Z

Persistent review updated to latest commit 56eb5ae

cubic-dev-ai

2 issues found across 14 files (changes from recent commits).

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/token_contract/Nargo.toml">

<violation number="1" location="src/token_contract/Nargo.toml:8">
P1: `token_contract` now depends on `v4.2.0-nightly` Aztec Noir packages instead of the PR’s target `v4.1.3`, creating a cross-package version mismatch.</violation>
</file>

<file name="src/nft_contract/Nargo.toml">

<violation number="1" location="src/nft_contract/Nargo.toml:8">
P1: This package is pinned to a nightly Aztec tag instead of the repo’s target `v4.1.3`, causing cross-package version drift and potential compile/runtime incompatibilities.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

cubic-dev-ai · 2026-04-08T04:39:43Z

src/token_contract/Nargo.toml

+aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" }
+uint_note = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/uint-note" }
+balance_set = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/balance-set" }
+compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" }


P1: token_contract now depends on v4.2.0-nightly Aztec Noir packages instead of the PR’s target v4.1.3, creating a cross-package version mismatch.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/token_contract/Nargo.toml, line 8: <comment>`token_contract` now depends on `v4.2.0-nightly` Aztec Noir packages instead of the PR’s target `v4.1.3`, creating a cross-package version mismatch.</comment> <file context> @@ -5,8 +5,8 @@ compiler_version = ">=1.0.0" -uint_note = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/uint-note" } -balance_set = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/balance-set" } -compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/compressed-string" } +aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" } +uint_note = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/uint-note" } +balance_set = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/balance-set" } </file context>

Suggested change

aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" }

uint_note = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/uint-note" }

balance_set = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/balance-set" }

compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" }

aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/aztec" }

uint_note = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/uint-note" }

balance_set = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/balance-set" }

compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/compressed-string" }

cubic-dev-ai · 2026-04-08T04:39:43Z

src/nft_contract/Nargo.toml

+aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" }
+compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" }


P1: This package is pinned to a nightly Aztec tag instead of the repo’s target v4.1.3, causing cross-package version drift and potential compile/runtime incompatibilities.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/nft_contract/Nargo.toml, line 8: <comment>This package is pinned to a nightly Aztec tag instead of the repo’s target `v4.1.3`, causing cross-package version drift and potential compile/runtime incompatibilities.</comment> <file context> @@ -5,6 +5,6 @@ compiler_version = ">=1.0.0" [dependencies] -aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/aztec" } -compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/compressed-string" } +aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" } +compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" } generic_proxy = { path = "../generic_proxy" } </file context>

Suggested change

aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" }

compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" }

aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/aztec" }

compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.1.3", directory = "noir-projects/aztec-nr/compressed-string" }

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

qodo-code-review · 2026-04-08T05:14:37Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

ⓘ The new review experience is currently in Beta. Learn more

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

qodo-code-review · 2026-04-08T05:15:14Z

Persistent review updated to latest commit 5ef751b

cubic-dev-ai

0 issues found across 5 files (changes from recent commits).

_{Requires human review: Auto-approval blocked by 2 unresolved issues from previous reviews.}

https://claude.ai/code/session_015jcSM73UJQi38ZZKbdsSKb

qodo-code-review · 2026-04-09T05:29:37Z

Persistent review updated to latest commit 012291c

qodo-code-review · 2026-04-09T05:32:48Z

CI Feedback 🧐

A test triggered by this PR failed. Here is an AI-generated analysis of the failure:

Action: pre-release / Pre-Release
Failed stage: Setup Aztec environment [❌]
Failed test name: ""
Failure summary: The action failed during the `aztec compile` step because the required Aztec toolchain version was not installed on the runner. - The workflow attempted to run `aztec compile` (around log lines 580-583). - The command aborted with: `Error: Version 4.2.0-nightly.20260407 is not installed.` and exited with code `1` (lines 584-586). - The log indicates the fix is to install that version first via `aztec-up` `install 4.2.0-nightly.20260407`.
Relevant error logs: 1: ##[group]Runner Image Provisioner 2: Hosted Compute Agent ... 431: Or undo this operation with: 432: git switch - 433: Turn off this advice by setting config variable advice.detachedHead to false 434: HEAD is now at f45f28e Merge 012291cfb381861649983f9517de42ca4fa258a3 into 0af8c760a1c574edf30a91ee64e5716ec3bae328 435: ##[endgroup] 436: [command]/usr/bin/git log -1 --format=%H 437: f45f28e718244683c428fabfe6dc60b2564f8404 438: ##[group]Run defi-wonderland/aztec-ci-actions/actions/setup-aztec@v0 439: with: 440: start-pxe: false 441: run-compile: true 442: run-codegen: true 443: ##[endgroup] 444: ##[group]Run if [ "true" = "true" ] && [ "true" = "false" ]; then 445: �[36;1mif [ "true" = "true" ] && [ "true" = "false" ]; then�[0m 446: �[36;1m echo "::error::run-codegen requires run-compile (codegen needs compile artifacts); set run-compile to true"�[0m 447: �[36;1m exit 1�[0m ... 569: warning Resolution field "@aztec/wallets@4.2.0-nightly.20260408-1" is incompatible with requested version "@aztec/wallets@4.2.0-aztecnr-rc.2" 570: [3/5] Fetching packages... 571: [4/5] Linking dependencies... 572: warning "@aztec/aztec > @aztec/cli@4.2.0-nightly.20260408-1" has unmet peer dependency "@aztec/noir-test-contracts.js@4.2.0-nightly.20260408-1". 573: warning "@aztec/aztec > @aztec/archiver > @aztec/epoch-cache > jest-mock-extended@4.0.0" has unmet peer dependency "@jest/globals@^28.0.0 \|\| ^29.0.0 \|\| ^30.0.0". 574: warning "@aztec/aztec > @aztec/archiver > @aztec/epoch-cache > jest-mock-extended@4.0.0" has unmet peer dependency "jest@^24.0.0 \|\| ^25.0.0 \|\| ^26.0.0 \|\| ^27.0.0 \|\| ^28.0.0 \|\| ^29.0.0 \|\| ^30.0.0". 575: warning "@aztec/aztec > @aztec/blob-client > snappy > @napi-rs/snappy-wasm32-wasi > @napi-rs/wasm-runtime@1.1.3" has unmet peer dependency "@emnapi/core@^1.7.1". 576: warning "@aztec/aztec > @aztec/blob-client > snappy > @napi-rs/snappy-wasm32-wasi > @napi-rs/wasm-runtime@1.1.3" has unmet peer dependency "@emnapi/runtime@^1.7.1". 577: [5/5] Building fresh packages... 578: $ husky 579: Done in 54.13s. 580: ##[group]Run aztec compile 581: �[36;1maztec compile�[0m 582: shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0} 583: ##[endgroup] 584: Error: Version 4.2.0-nightly.20260407 is not installed. 585: Run 'aztec-up install 4.2.0-nightly.20260407' to install it first. 586: ##[error]Process completed with exit code 1. 587: Post job cleanup.

cubic-dev-ai

0 issues found across 10 files (changes from recent commits).

_{Requires human review: Auto-approval blocked by 2 unresolved issues from previous reviews.}

https://claude.ai/code/session_015jcSM73UJQi38ZZKbdsSKb

qodo-code-review · 2026-04-09T05:38:37Z

Persistent review updated to latest commit be7ff50

github-actions · 2026-04-09T06:07:24Z

Benchmark Comparison

CPU	Cores	RAM	Arch
AMD EPYC 7763 64-Core Processor	16	63 GiB	x64

Contract: escrow

🚦	Function	Gates			DA Gas			L2 Gas			Proving Time (ms)
		Base	PR	Diff	Base	PR	Diff	Base	PR	Diff	Base	PR	Diff
⚪	`(partial) withdraw`	579,408	579,408		1,312	1,312		495,400	495,400		7,169	7,179	+10 (+0.1%)
⚪	`withdraw`	579,408	579,408		736	736		483,700	483,700		7,140	7,181	+41 (+0.6%)
⚪	`withdraw_nft`	536,373	536,373		736	736		483,700	483,700		6,933	6,995	+62 (+0.9%)

Contract: logic

🚦	Function	Gates			DA Gas			L2 Gas			Proving Time (ms)
		Base	PR	Diff	Base	PR	Diff	Base	PR	Diff	Base	PR	Diff
⚪	`get_escrow`	520,851	520,851		128	128		456,000	456,000		6,854	6,899	+45 (+0.7%)
⚪	`secret_key_to_public_keys`	515,935	515,935		128	128		456,000	456,000		6,819	6,862	+43 (+0.6%)
⚪	`share_escrow`	420,067	420,067		704	704		474,500	474,500		6,006	6,007	+1 (+0.0%)

Contract: nft

🚦	Function	Gates			DA Gas			L2 Gas			Proving Time (ms)
		Base	PR	Diff	Base	PR	Diff	Base	PR	Diff	Base	PR	Diff
⚪	`burn_private`	455,161	455,161		416	416		671,675	671,675		6,360	6,363	+3 (+0.0%)
⚪	`burn_public`	340,915	340,915		448	448		691,760	691,760		5,360	5,361	+1 (+0.0%)
⚪	`mint_to_private`	472,217	472,217		960	960		662,581	662,581		6,428	6,435	+7 (+0.1%)
⚪	`mint_to_public`	340,915	340,915		448	448		694,916	694,916		5,368	5,380	+12 (+0.2%)
⚪	`transfer_private_to_private`	427,956	427,956		736	736		483,700	483,700		6,112	6,078	-34 (-0.6%)
⚪	`transfer_private_to_public`	455,237	455,237		416	416		666,473	666,473		6,323	6,273	-50 (-0.8%)
⚪	`transfer_public_to_private`	468,858	468,858		960	960		662,665	662,665		6,381	6,401	+20 (+0.3%)
⚪	`transfer_public_to_public`	340,915	340,915		384	384		648,357	648,357		5,379	5,360	-19 (-0.4%)

Contract: token

🚦	Function	Gates			DA Gas			L2 Gas			Proving Time (ms)
		Base	PR	Diff	Base	PR	Diff	Base	PR	Diff	Base	PR	Diff
⚪	`burn_private`	486,861	486,861		992	992		687,411	687,411		6,489	6,507	+18 (+0.3%)
⚪	`burn_public`	340,915	340,915		448	448		681,599	681,599		5,340	5,372	+32 (+0.6%)
⚪	`initialize_transfer_commitment`	403,443	403,443		704	704		474,500	474,500		5,898	5,908	+10 (+0.2%)
⚪	`mint_to_private`	473,137	473,137		960	960		656,449	656,449		6,466	6,454	-12 (-0.2%)
⚪	`mint_to_public`	340,915	340,915		448	448		690,521	690,521		5,364	5,368	+4 (+0.1%)
⚪	`transfer_private_to_commitment`	453,824	450,450	-3,374 (-0.7%)	896	896		495,400	495,400		6,229	6,185	-44 (-0.7%)
⚪	`transfer_private_to_private`	470,985	470,985		1,312	1,312		495,400	495,400		6,274	6,316	+42 (+0.7%)
⚪	`transfer_private_to_public`	486,937	486,937		992	992		690,330	690,330		6,532	6,577	+45 (+0.7%)
⚪	`transfer_private_to_public_with_commitment`	497,197	497,197		1,568	1,568		723,630	723,630		6,568	6,559	-9 (-0.1%)
⚪	`transfer_public_to_commitment`	340,915	340,915		576	576		683,157	683,157		5,399	5,353	-46 (-0.9%)
⚪	`transfer_public_to_private`	469,793	469,793		960	960		659,611	659,611		6,394	6,434	+40 (+0.6%)
⚪	`transfer_public_to_public`	340,915	340,915		448	448		684,065	684,065		5,340	5,406	+66 (+1.2%)

Contract: vault

🚦	Function	Gates			DA Gas			L2 Gas			Proving Time (ms)
		Base	PR	Diff	Base	PR	Diff	Base	PR	Diff	Base	PR	Diff
⚪	`deposit_private_to_private`	904,856	904,856		1,280	1,280		894,014	894,014		10,084	10,084
⚪	`deposit_private_to_private_exact`	1,017,026	1,017,026		1,856	1,856		936,548	936,548		10,943	10,958	+15 (+0.1%)
⚪	`deposit_private_to_public`	718,982	718,982		768	768		928,555	928,555		8,480	8,458	-22 (-0.3%)
⚪	`deposit_public_to_private`	589,551	589,551		1,344	1,344		959,628	959,628		7,365	7,364	-1 (-0.0%)
⚪	`deposit_public_to_private_exact`	748,093	748,093		1,920	1,920		1,002,324	1,002,324		8,742	8,729	-13 (-0.1%)
⚪	`deposit_public_to_public`	340,915	340,915		832	832		1,000,133	1,000,133		5,346	5,349	+3 (+0.1%)
⚪	`issue_private_to_private_exact`	1,017,026	1,017,026		1,856	1,856		936,824	936,824		10,911	10,963	+52 (+0.5%)
⚪	`issue_private_to_public_exact`	831,162	831,162		1,344	1,344		971,590	971,590		9,391	9,396	+5 (+0.1%)
⚪	`issue_public_to_private`	639,893	639,893		1,344	1,344		968,462	968,462		7,859	7,845	-14 (-0.2%)
⚪	`issue_public_to_public`	340,915	340,915		832	832		1,000,436	1,000,436		5,348	5,342	-6 (-0.1%)
⚪	`redeem_private_to_private_exact`	1,013,679	1,013,679		1,856	1,856		937,055	937,055		10,890	10,906	+16 (+0.1%)
⚪	`redeem_private_to_public`	718,905	718,905		768	768		919,369	919,369		8,410	8,459	+49 (+0.6%)
⚪	`redeem_public_to_private_exact`	698,526	698,526		1,920	1,920		999,453	999,453		8,292	8,253	-39 (-0.5%)
⚪	`redeem_public_to_public`	340,915	340,915		832	832		987,833	987,833		5,346	5,370	+24 (+0.4%)
⚪	`withdraw_private_to_private`	901,509	901,509		1,280	1,280		893,840	893,840		9,985	9,982	-3 (-0.0%)
⚪	`withdraw_private_to_private_exact`	1,013,679	1,013,679		1,856	1,856		936,617	936,617		10,897	10,887	-10 (-0.1%)
⚪	`withdraw_private_to_public_exact`	831,084	831,084		1,344	1,344		962,194	962,194		9,369	9,367	-2 (-0.0%)
⚪	`withdraw_public_to_private`	586,272	586,272		1,344	1,344		955,866	955,866		7,338	7,342	+4 (+0.1%)
⚪	`withdraw_public_to_public`	340,915	340,915		832	832		987,752	987,752		5,362	5,376	+14 (+0.3%)

claude added 8 commits March 24, 2026 10:17

chore: upgrade aztec to v4.1.0

735abed

https://claude.ai/code/session_01JWkKLzm777Be6PZHWKeTPM

fix: revert benchmark workflow refs to 4.1.0-rc.4

ffeece7

The aztec-benchmark repo does not have a 4.1.0 tag, only 4.1.0-rc.4. https://claude.ai/code/session_01JWkKLzm777Be6PZHWKeTPM

chore: upgrade aztec to v4.1.1

c4ef029

https://claude.ai/code/session_01D5wkpiw74Hw2WeMdFjm1vj

chore: upgrade aztec to v4.1.2

fd64d27

https://claude.ai/code/session_01Xt9oZkxddNEmxUmxk1wwJ8

fix: revert benchmark workflow refs to 4.1.0-rc.4

d7fb584

The 4.1.2 tag does not exist in defi-wonderland/aztec-benchmark, so the benchmark CI jobs would fail to start. https://claude.ai/code/session_013YRxPVLkEpwFBYYRjCHMV3

Merge dev into claude/aztec-upgrade

5705813

chore: upgrade aztec to v4.2.0-nightly.20260331

a9baf83

https://claude.ai/code/session_01GLhcwraBdpK1qn5UXEoHGb

cubic-dev-ai bot previously approved these changes Apr 1, 2026

View reviewed changes

chatgpt-codex-connector bot reviewed Apr 1, 2026

View reviewed changes

fix: add resolutions to prevent duplicate @aztec/foundation versions

00447d1

The @defi-wonderland/aztec-benchmark package pins older @aztec/* versions, causing two @aztec/foundation trees and Fr type identity mismatches at runtime. https://claude.ai/code/session_01GLhcwraBdpK1qn5UXEoHGb

0xShaito dismissed cubic-dev-ai[bot]’s stale review via 00447d1 April 1, 2026 05:20

cubic-dev-ai bot previously approved these changes Apr 1, 2026

View reviewed changes

qodo-code-review bot reviewed Apr 1, 2026

View reviewed changes

package.json Show resolved Hide resolved

This comment has been minimized.

Sign in to view

0xShaito dismissed cubic-dev-ai[bot]’s stale review via 4a439a0 April 2, 2026 04:41

cubic-dev-ai bot previously approved these changes Apr 2, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

0xShaito changed the title ~~chore: upgrade aztec to v4.2.0-nightly.20260331~~ chore: upgrade aztec to v4.2.0-nightly.20260401 Apr 2, 2026

0xShaito dismissed cubic-dev-ai[bot]’s stale review via 8015f13 April 3, 2026 05:21

0xShaito changed the title ~~chore: upgrade aztec to v4.2.0-nightly.20260401~~ chore: upgrade aztec to v4.1.3 Apr 3, 2026

cubic-dev-ai bot previously approved these changes Apr 3, 2026

View reviewed changes

0xShaito dismissed cubic-dev-ai[bot]’s stale review via b8657ce April 3, 2026 05:43

style: apply linter formatting

a1796a8

https://claude.ai/code/session_01AXBNqfo4Sv8WNVrzq1gHCH

claude added 2 commits April 7, 2026 04:27

Merge remote-tracking branch 'origin/dev' into claude/aztec-upgrade

ddb52ca

# Conflicts: # src/escrow_contract/src/test/utils.nr

chore: upgrade aztec to v4.1.3

07f6f10

https://claude.ai/code/session_01M2beEWZtD5qxSwL4rzozfc

Revert "fix: handle AztecAddress ABI path change in v4.1.3 event deco…

3bf734d

…ding" This reverts commit de1bd35.

chore: upgrade aztec to v4.2.0-nightly.20260407

56eb5ae

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

0xShaito changed the title ~~chore: upgrade aztec to v4.1.3~~ chore: upgrade aztec to v4.2.0-nightly.20260407 Apr 8, 2026

cubic-dev-ai bot reviewed Apr 8, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

style: apply linter formatting to upgraded contracts

2ddf24c

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

chore: add .bb-crs to gitignore

5ef751b

https://claude.ai/code/session_01JAiNn4te7tvqgxZMQDcrYv

cubic-dev-ai bot reviewed Apr 8, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

chore: upgrade aztec to v4.2.0-nightly.20260408-1

012291c

https://claude.ai/code/session_015jcSM73UJQi38ZZKbdsSKb

cubic-dev-ai bot reviewed Apr 9, 2026

View reviewed changes

fix: update .aztecrc to match target version

be7ff50

https://claude.ai/code/session_015jcSM73UJQi38ZZKbdsSKb

0xShaito changed the title ~~chore: upgrade aztec to v4.2.0-nightly.20260407~~ chore: upgrade aztec to v4.2.0-nightly.20260408-1 Apr 9, 2026

		aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/aztec" }
		compressed_string = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v4.2.0-nightly.20260407", directory = "noir-projects/aztec-nr/compressed-string" }

Conversation

0xShaito commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Test plan

Uh oh!

qodo-code-review bot commented Apr 1, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-code-review bot commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-code-review bot commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment has been minimized.

qodo-code-review bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

qodo-code-review bot commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

New Review Started

Uh oh!

qodo-code-review bot commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

qodo-code-review bot commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review bot commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai bot Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai bot Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

0xShaito commented Apr 1, 2026 •

edited

Loading

qodo-code-review bot commented Apr 1, 2026 •

edited

Loading

qodo-code-review bot commented Apr 1, 2026 •

edited

Loading

qodo-code-review bot commented Apr 2, 2026 •

edited

Loading

qodo-code-review bot commented Apr 3, 2026 •

edited

Loading

qodo-code-review bot commented Apr 3, 2026 •

edited

Loading

qodo-code-review bot commented Apr 6, 2026 •

edited

Loading

qodo-code-review bot commented Apr 7, 2026 •

edited

Loading

qodo-code-review bot commented Apr 7, 2026 •

edited

Loading

qodo-code-review bot commented Apr 7, 2026 •

edited

Loading

qodo-code-review bot commented Apr 7, 2026 •

edited

Loading

qodo-code-review bot commented Apr 8, 2026 •

edited

Loading

cubic-dev-ai bot Apr 8, 2026 •

edited

Loading

cubic-dev-ai bot Apr 8, 2026 •

edited

Loading

qodo-code-review bot commented Apr 8, 2026 •

edited

Loading

qodo-code-review bot commented Apr 8, 2026 •

edited

Loading

qodo-code-review bot commented Apr 9, 2026 •

edited

Loading

qodo-code-review bot commented Apr 9, 2026 •

edited

Loading