feat(aztec): declarative deployment framework at @aztec/aztec/deploy by Thunkar · Pull Request #24685 · AztecProtocol/aztec-packages

Thunkar · 2026-07-14T14:48:27Z

A minimal, declarative deployment framework ported from aztec-kit: describe accounts + a graph of steps (contracts to publish/register and actions to send, with interdependencies) plus a fee policy,. Resolves deterministic addresses, inventories what's already on-chain, funds accounts, and executes only what's missing in dependency order idempotently and resumably.

Lives in the @aztec/aztec/deploy export (needs EmbeddedWallet+PXE, noir-contracts.js, node:fs state, and L1 bridging — all above aztec.js), beside @aztec/aztec/testing. Accepts an already-connected node so it composes with the in-process setupLocalNetwork fixture.

A minimal, declarative deployment framework ported from aztec-kit: describe accounts + a graph of steps (contracts to publish/register and actions to send, with interdependencies) plus a fee policy, and runDeployment resolves deterministic addresses, inventories what's already on-chain, funds accounts, and executes only what's missing in dependency order — idempotently and resumably. Lives in the @aztec/aztec/deploy Node companion (needs EmbeddedWallet+PXE, noir-contracts.js, node:fs state, and L1 bridging — all above aztec.js), beside @aztec/aztec/testing. Network handling is a single `local` boolean rather than a network enum (local = anvil defaults; anything else = caller-supplied L1 details). Accepts an already-connected `node` so it composes with the in-process setupLocalNetwork fixture. Pure graph-scheduling tests run in the fast CI gate; publish/action/idempotency and interdependency/shared-class/register are covered by an on-demand integration suite driven through setupLocalNetwork.

…ol/aztec-packages into gj/upstream_deploy_framework

dbanks12

Really nice work! This is a big chunk of work that probably deserved a thorough design doc. Maybe we just need to move quickly right now, but I still think a DD would have been a huge help for me to review. If it was largely ported from aztec-kit, then it does make sense why it was convenient to just port over!

I left some comments and nits. I'll submit PRs to your branch that will resolve some

dbanks12 · 2026-07-17T02:44:34Z

Three more small ones from claude:

POLL_INTERVAL_MS (bridging.ts) is only used by the warp loop. The poll loop hardcodes 5_000. Rename or unify?
lastLog in the poll loop updates every 30s but nothing logs. Looks like an orphaned throttle from a removed log line. Dead code?
The sponsored path pads maxFeesPerGas x10 (fees.ts). What's the reasoning behind that number? Probably deserves a comment

…ing (#24757) Targets #24685. Drops the transport-level ×3 on `eth_estimateGas` (`createBufferedL1Client`) in favor of plain `createExtendedL1Client`: since #24607 the portal manager buffers Inbox deposits at 2× itself, so the multiplier stacks to 6×. Worst-case Inbox insert verified against the built-in buffer in aztec-labs-eng/aztec-kit#116. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Gregorio Juliana <gregojquiros@gmail.com>

Targets #24685. Comments only, no behavior change: labels the fee dispenser closures in `prepareFeeSession` (what `fee`/`onConsumed` mean, the one-way claim latch, the `next` contract), explains the recording-resolver dry run in the runner, states the layer-readiness condition and the layer/wave naming in `graph.ts`, documents the threshold/fundAmount trade-off on the fee defaults, and notes bridging is fee-juice-only plus the `WARP_BY_SECONDS` update caveat. --------- Co-authored-by: Gregorio Juliana <gregojquiros@gmail.com>

Targets #24685. Two renames from review: the faucet-path decision `minted` → `useFaucet` (it's computed before anything is minted; `minted` stays as the retrospective result field), and `advanceL1ToL2Message` → `warpToL1ToL2Message` to match the file's warp/poll vocabulary. Both symbols are module-local. Co-authored-by: Gregorio Juliana <gregojquiros@gmail.com>

Thunkar · 2026-07-17T19:37:42Z

Three more small ones from claude:

* `POLL_INTERVAL_MS` (bridging.ts) is only used by the warp loop. The poll loop hardcodes  `5_000`. Rename or unify?

* `lastLog` in the poll loop updates every 30s but nothing logs. Looks like an orphaned throttle from a removed log line. Dead code?

* The sponsored path pads `maxFeesPerGas` x10 (fees.ts). What's the reasoning behind that number? Probably deserves a comment

These should all be addressed now!

nventuro

Been trying to get to this a couple times, and broad strokes I agree with @dbanks12 - it's very hard to review a 2.5k line new project with zero to no context. I've not been able to go through the entire thing, rather did an ai-assisted round of review trying to understand where things stand and broad pattens, so my review is very low quality and you prob should not read much into it.

There's also a secondary element of this being obviously already quite advanced, so any large disagreements would imply a massive rewrite (which is I assume part of what @dbanks12 was hinting at when wishing having looked at a design document prior to implementation), which makes the reviewer either feel antagonistic or only comment on minor details and not provide a lot of value in the end.

nventuro · 2026-08-05T22:41:07Z

+   * deferred contracts: declare the steps whose effects the args read, or an explicit empty array
+   * if they only read pre-existing state.


This distinction between undefined and [] seems very odd.

It is, but defered constructor args are wonky. We'll discuss

nventuro · 2026-08-05T22:42:07Z

+  /** Per-contract salt, overriding {@link DeploymentSpec.salt}. */
+  salt?: Fr;
+  /**
+   * For contracts that own private notes (e.g. an FPC): the contract's key secret. The framework


'key secret' is again a bit too generic - do we use this value to derive privacy master keys? It is used for anything else?

Again, this predates the change of deriving separately

Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>

…ec-packages into gj/upstream_deploy_framework

approved

Promotes `v5-next` onto `v5` for the **v5.2.0** release. Frozen at `ee5d2d367e` — the `v5-next` tip at cut time. Both `merge-train/spartan-v5` and `merge-train/fairies-v5` are drained to that same commit, so nothing staged is left behind. ### Testnet validation This branch was cut at `a4db216abf`, which is byte-identical to the `v5.2.0-nightly.20260815` tag — same commit, same tree (`0b22572eace2419ede6bbab173514d6965d4e0d0`). That nightly's CI3 run is green, its artifacts are published to npm and Docker Hub, and it has been **running healthily on testnet since 2026-08-15**: | Component | Image / reported version | |---|---| | validators, prover node, prover broker, prover agents (`testnet` ns) | `aztecprotocol/aztec:5.2.0-nightly.20260815` | | `v5.testnet.rpc.aztec-labs.com` | `nodeVersion=5.2.0-nightly.20260815` | | `canonical.testnet.rpc.aztec-labs.com` | `nodeVersion=5.2.0-nightly.20260815` | Chain advancing normally, no prunes or reorgs, no WARN/ERROR across node pods since rollout. The branch has since been fast-forwarded to `ee5d2d367e` to pick up #25242 (configurable RPC server HTTP timeouts and CORS allowed-headers). That is the only delta from the soaked tree — 8 files, +131/−10, no nightly covers it yet. Its config defaults were checked against Node's built-ins (`keepAliveTimeout` 5000 ms, `headersTimeout` 60000 ms) and match exactly, and the CORS default path resolves to the same `cors()` call as before, so a node that sets none of the new env vars behaves identically. It touches no circuits, protocol contracts, or generated constants. ### Manifest `.release-please-manifest.json` reads `5.2.0` on this branch, which is the released version — correct as-is, no change needed in this PR. `v5-next` moves to `5.3.0` separately in #25240; this branch is frozen and cannot pick that up, so the two can merge in either order. `v5` is a strict ancestor of `v5-next` this cycle, so there was no manifest conflict to pre-resolve. ### Scope 139 commits (86 non-merge, 23 PR-level) spanning 2026-07-14 to 2026-08-17. | Area | Theme | |---|---| | `prover-node` / `prover-client` | Epoch-proving robustness: retry-to-converge with failure declared only at submission-window expiry, ticker-driven expiry, per-checkpoint post-mortem upload, checkpoint-only re-proving, prune-induced fault handling (#24678, #24982, #24983, #24990, #25027) | | `pxe` | Sync performance: hash-pinned node read cache (#24969), anchor-bounded tag log caching (#25074), note/event validation from cached tx data (#25076), constrained tag sync (#24275), sender tagging finalization from log blocks (#25045) | | `p2p` / `validator-client` | Gossip tx validation no longer stalls behind tx-pool finalization (#25148); startup fails when p2p fails to start (#25177); slashing/proposing/health/`sendTx` gated on p2p connectivity (#25185); duplicate time-sensitive proposal validation removed (#25207); `ValidatedProposal` branding (#25222) | | `ethereum` / `aztec-node` | L1 watchers poll `getLogs` instead of `eth_newFilter` (#25176); block stream sync no longer resolves against an earlier pass (#25206) | | `stdlib` / `foundation` | Deserialization bounds hardening (#25026, #25028, #25029, #25109); checkpoint block-shape and block-count validation (#25229); JSON-RPC cookies (#25231) | | `archiver` | Removed-block cleanup and ownership-checked tx-effect deletes (#24765); L2→L1 witness from a single store snapshot (#24754) | | `aztec` | Declarative deployment framework at `@aztec/aztec/deploy` (#24685) | | `slasher` | Own-validator slash-target warnings and metrics (#25058) | | telemetry | JSON-RPC metrics (#25159) | | JSON-RPC server | Configurable HTTP keep-alive / headers timeouts and CORS allowed-headers, defaults preserving current behaviour (#25242) | | toolchain | Noir bumped to `v1.0.0-beta.25` (#24907) | **One breaking change**, inherited from the Noir bump: note types declared directly inside a `contract` module must now be `pub`. Everything else is additive or internal. ### Protocol constants Built from source and compared against `v5` — a cache-free rebuild of every protocol circuit with each ref's own nargo and bb, then regeneration of `vk_tree.ts` and `protocol_contract_data.ts`: - `vkTreeRoot` = `0x2b3b6ea4412b9c8f6457a37f91a2870306f8641e07e16a49b68bda6f8bc02892` — unchanged from v5.1.0 - `protocolContractsHash` = `0x2c075866eafc88a1f6f9addc7e337c6e64e45d1cb7fd7c0d612ebcec72aab2ca` — unchanged from v5.1.0 The Noir beta.24 → beta.25 bump does not reach the circuits: the release build consumes the committed `pinned-build.tar.gz`, which is bit-identical between v5.1.0 and this commit (blob `3bedcb1fd1…`), so the protocol-circuit bytecode is frozen rather than recompiled. The 47 verification keys were recomputed locally from that pinned bytecode with the cache disabled, and all 47 `check_pinned_vk` checks passed. `protocolContractsHash` is likewise backed by the new `pinned-protocol-contracts.tar.gz`, whose three artifacts were byte-compared against the build. Both values were also confirmed inside the published `@aztec/protocol-contracts` and `@aztec/noir-protocol-circuits-types` packages for `5.2.0-nightly.20260815`. That makes v5.2.0 a drop-in upgrade against the current rollup rather than a coordinated one. ✅ **Gate re-run against `ee5d2d367e` (the current head) and passed** — both values reproduced exactly from a build at this commit, with `vkTreeRoot` numerically evaluated rather than inferred. `29556326ce..ee5d2d3` touches no `noir-projects/**`, `l1-contracts/src/**`, `ConstantsGen.sol`, `constants.gen.ts` or `constants.nr`. Scope of the check: it verifies that the pinned circuit bytecode plus locally recomputed VKs agree with the pin — not that a from-source recompile reproduces v5.1.0's bytecode. <details> <summary>Commits added after the original constants check at 2955632</summary> `#25207` `#25222` `#25206` `#25185` `#25176` `#25163` `#25229` `#25159` `#25162` `#25231` `#25224` `#25228` `#25230` `#25242` plus their merge commits. </details> ### Known gap Migration notes carry entries under `## TBD` that arrived with the docs baseline backport (#25017) and describe `next`-line changes not present on the v5 line — protocol contracts removed from `@aztec/noir-contracts.js`, and the `at(wallet)` → `withWallet(wallet)` deprecation. Neither exists on this branch. There is also no `## 5.1.0` heading, and the entries that ship in v5.2.0 sit under `## TBD` rather than a version heading. This ships in the release docs, so it is worth correcting on `v5-next` and backporting to `v5` before the tag, rather than after.

@yev

## Summary Publishes `v5.2.0` as the shared release for both **Alpha (Mainnet)** and **Testnet** across developer and network/operator documentation, and removes the deprecated `v5.1.0` snapshots. - both `mainnet` and `testnet` selectors resolve to the same `v5.2.0` snapshot - developer and network/operator snapshots cut from the `v5.2.0` tag (`49a592109ec`), so `#include_code` snippets and version macros freeze against what shipped - Aztec.nr, TypeScript, Aztec.js, `aztec` / `aztec-wallet` / `aztec-up` CLI, operator `aztec start` CLI and Node JSON-RPC references all regenerated at the tag - identical generated API artifacts under the stable `mainnet` and `testnet` paths - `networks.md` re-derived from the node RPCs and on-chain reads A backport of this release into `v5-next` is [#25265](#25265). ## Merged `next` (2026-08-19) `next` moved 64 commits while this was open. Merged and resolved; `yarn build` re-run green on the merged tree. Two conflicts, both around the Aztec.js reference: - `docs/scripts/aztecjs_reference_generation/transform_to_markdown.py` — **took `next`'s version wholesale.** [#25248](#25248) landed a proper `HeadingSlugger` (github-slugger semantics including the `-1`/`-2` uniqueness suffixes) and code-block handling for multi-line types, which supersedes the two narrower fixes this PR originally carried. - `docs/docs-developers/docs/aztec-js/aztec_js_reference.md` — **took `next`'s version.** [#25249](#25249) added `update_docs.sh --check` to `docs/bootstrap.sh`, so the committed source page must match what the generator produces from the working tree. Regenerating on the merged tree reproduces `next`'s page byte-for-byte (modulo the self-stamped timestamp) and `--check` passes. The **v5.2.0 snapshot's** copy of that page was regenerated with `next`'s generator against the `v5.2.0` tag's `aztec.js` source, so the released snapshot gets the improved anchors and code-block formatting while still documenting v5.2.0's API. Also reconciled from `next` into the snapshot: [#25220](#25220 clarification that `teardownGasLimits` is carved out of `gasLimits` rather than added to it. Verified true at the tag (`yarn-project/stdlib/src/gas/gas_settings.ts`: "teardown gas is reserved from gasLimits during private execution ... the effective gas available for app logic is `gasLimits - teardownGasLimits - privateOverhead`"). The other post-tag doc changes on `next` are fast-inbox / AZIP-22 work (`inbox.md`, the `MessageSent` signature and message-availability wording in `token_bridge.md` and `uniswap_swap.md`, and dropping `AZTEC_INBOX_LAG`), which is not in v5.2.0 — deliberately **not** backported, so the snapshot keeps the wording that is correct for the release. ## Release details Verified from the node RPCs at cut time: | | Alpha (Mainnet) | Testnet | | --- | --- | --- | | `nodeVersion` from RPC | `5.1.0` | `5.2.0-nightly.20260815` | | `rollupVersion` | `4248422647` | `1821665230` | | L1 chain id | `1` | `11155111` | Per the instruction that the network versions are unchanged, the **Version** row in `networks.md` stays `5.1.0` for both columns; only the documentation version advances to `v5.2.0`. Every figure in `networks.md` was re-derived rather than carried forward: - all L1 addresses in both columns match `aztec_getNodeInfo` - Slasher, Honk verifier, Reward Booster, Tally Slashing Proposer and Slash Payload Cloneable re-read on chain from the Rollup / Slasher / Proposer for both networks, all unchanged - rollup version read from `getVersion()` on both rollups; chain ids from `cast chain-id` - governance parameters re-read on chain for **both** columns: proposer quorum 600/1000 and 60/100; voting delay, duration and execution delay decoded from `getConfiguration()` (mainnet 3 d / 7 d / 2 d, testnet 12 h / 24 h / 12 h); slashing quorum 65/128 over 4 epochs (128 slots) ### The canonical SponsoredFPC address changes under v5.2.0 tooling, and the new one is not deployed `aztec get-canonical-sponsored-fpc-address` built from the `v5.2.0` tag returns: ``` 0x2ece607a8dba690c9aa4ee1d53a55286fa815543a27f9364bbaf65eb68e7315b (class id 0x1cf37d561fb76ae2b95d3c395c3204c1dab4a6309b045a3fc17a58483c5ad2e9) ``` Testnet has nothing at that address (`aztec_getContract` returns `null`). What is deployed and funded is the v5.1.0-built FPC, `0x130925fb...923296` (class id `0x184e81e5...8673a5`), which is what this PR keeps. The SponsoredFPC Noir source is byte-identical between `v5.1.0` and `v5.2.0` — the address moved purely because the Noir compiler went `beta.22` to `beta.25`, which changes the compiled bytecode, the contract class id, and therefore the derived address. The same thing happened at the v5.1.0 cut, where a new FPC was deployed and funded. The consequence is worth stating plainly: `wallet.registerContract` does not validate that the supplied artifact matches the instance's class (explicit comment in `yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts`), so `aztec-wallet register-contract ... SponsoredFPC` appears to succeed on v5.2.0 tooling and then fails at simulation, because the PXE only holds the `0x1cf37d...` artifact. **Either a v5.2.0-built SponsoredFPC is deployed and funded on testnet at `0x2ece...` and this PR is repointed at it, or sponsored fees on testnet stay pinned to v5.1.0 tooling.** ## Documentation content changes ### Aztec.nr: the v5.2.0 breaking change was live in three doc snippets Note structs declared inside a `contract` block must now be `pub` (Noir `beta.25`, [#24907](#24907)). `state_variables.md` (`AddressNote`, `UintNote`), `functions/attributes.md` (`CustomNote`) and the `#[custom_note]` example in the `notes.nr` doc comment (published through `nargo doc`) all showed non-`pub` declarations that do not compile on v5.2.0. Every `.nr` **source** file the docs pull in via `#include_code` was already `pub`, so the defect was confined to prose snippets. ### Migration notes - The `pub` note-visibility entry was filed under `## 5.1.0`, but the Noir `beta.25` bump that causes it is not in the `v5.1.0` tag. Moved to a new `## 5.2.0` section. - Four v5.2.0 behaviour changes had no migration note at all, each verified against `v5.1.0..v5.2.0`: the zero-peer proposing gate (`SEQ_MIN_PEERS_TO_PROPOSE`), JSON-RPC internal errors moving from `-32600` to `-32603`, `GET /status` gaining a per-component JSON body (and the widened `StatusCheckFn`), and the removal of `deserializeArrayFromVector` from `@aztec/foundation/serialize`. - The `## TBD` entries on this branch are left untouched: they describe changes on this line that have not shipped in a release yet. ### Operator / node docs All eight new v5.2.0 env vars were missing from the CLI reference; regenerating it at the tag picks them up, along with `--proverNode.proofSubmissionTargetAddress`, which existed in v5.1.0 code but was never documented. Hand edits on top: | File | Change | | --- | --- | | `reference/changelog/v5.2.md` | new page; the operator changelog stopped at v4.3.x. Plus index and sidebar entries | | `concepts/monitoring.md` | claimed the node emits no "about to be slashed" metric; it now does, so that section carries the real logs and metrics | | `monitoring/metrics-reference.md` | new own-validator slashing metrics section (with alert rule) and JSON-RPC server metrics section | | `concepts/sequencer-troubleshooting.md` | the four peerless-node gates, plus the `/status` health check and `P2P_HEALTH_MIN_PEERS` | | `reference/reading-logs.md` | five new entries: fatal p2p start failure, zero-peer warning, skipped proposal, mempool drop reasons, slash-target warning | | `sequencer-management/governance-participation.md` | the node now stops signalling an executed payload; `GOVERNANCE_PROPOSER_FORCE_PAYLOAD_VOTE` escape hatch | | `concepts/l1-rpc.md` | server-side filter methods are no longer required; watchers poll bounded `eth_getLogs` | | `provider/start-node.mdx`, `solo-sequencer/start-node.mdx` | sample `nodeVersion` `5.0.0` to `5.2.0` | Reviewed on the deploy preview by @yev. ### Developer docs - `tutorials/js_tutorials/aave_bridge.md` pinned `@aztec/l1-artifacts` to a literal version; it now uses the version macro like every other pin on that page, so it stops going stale each release. - `aztec-js/how_to_send_transaction.md` documents the new first-receipt-poll delay and `initialDelay` ([#25089](#25089)). - `@aztec/viem@2.38.2` is deliberately left alone in the three tutorials that pin it: it tracks upstream `viem`, not the release line. **Known gap, not fixed here:** the declarative deployment framework at `@aztec/aztec/deploy` ([#24685](#24685)), headlined as "New in this release", has **zero** documentation. It wants a new `aztec-js` page; that was scoped but not written, rather than shipping a half-verified page for a new API. ## Non-docs changes Three one-line source edits, all comment-only, no behaviour change: - `archiver/src/config.ts` and `stdlib/src/interfaces/archiver.ts` — `on-chain` to `onchain`, so the regenerated operator CLI reference passes the repo's own spellcheck (`on-chain` is a repo-wide `flagWord`) - `noir-projects/labs/aztec-nr/aztec/src/macros/notes.nr` — the `pub` fix in the `#[custom_note]` doc comment The equivalent `aztec.js` JSDoc fixes this PR originally carried are gone: `next` made the same corrections upstream, so the merge left nothing to change. ## Validation `MAINNET_TAG=5.2.0 TESTNET_TAG=5.2.0 RELEASE_TYPE=mainnet COMMIT_TAG=v5.2.0 yarn build`, re-run on the merged tree: - CSpell: 682 files, **0 issues** - Redirect targets: 185 checked, all valid - API reference links: 112 checked, **0 broken, 0 version mismatches** - Docusaurus production build: **successful** - `./scripts/aztecjs_reference_generation/update_docs.sh --check`: **✓ Reference matches aztec.js** - no unresolved `#release_version` / `#release_network` / `#include_code` macros in either snapshot - version configs and version lists carry one shared `v5.2.0` snapshot for both Alpha and Testnet - generated `mainnet` and `testnet` Aztec.nr and TypeScript API directories are byte-identical - empty `## TBD` heading stripped from the cut snapshot's migration notes Remaining broken-anchor warnings are the pre-existing ones only (the `validator-keys|valkeys` CLI alias and the operator compose-page anchors); `onBrokenAnchors` is `warn`, so the build passes. **Not run:** the functional validation pass (walking the guides and tutorials against a live local network). This container has no Docker daemon, so the dockerized `aztec` CLI could not be installed; everything above was produced from a source build of the tag with shims for `aztec` / `aztec-wallet` / `aztec-up`. The guides and tutorials in this snapshot are link- and spell-validated but not executed. --- *Created by [claudebox](https://claudebox.work/v2/sessions/c8d26e6f93543878/jobs/12) · group: `slackbot` · requested by Alejo Amiras · [Slack thread](https://aztecfoundation.slack.com/archives/C0B24G1GFGB/p1787064177273599?thread_ts=1787064177.273599&cid=C0B24G1GFGB)*

Thunkar added 2 commits July 14, 2026 15:59

comments

76eaf7b

Thunkar self-assigned this Jul 15, 2026

Thunkar marked this pull request as ready for review July 15, 2026 11:01

Thunkar added 3 commits July 15, 2026 13:01

Merge branch 'merge-train/fairies-v5' into gj/upstream_deploy_framework

36f1477

run all tests

1cfbb71

Merge branch 'gj/upstream_deploy_framework' of github.com:AztecProtoc…

2657892

…ol/aztec-packages into gj/upstream_deploy_framework

dbanks12 mentioned this pull request Jul 16, 2026

refactor(aztec): rely on portal manager gas buffering in deploy bridging #24757

Merged

dbanks12 previously requested changes Jul 17, 2026

View reviewed changes

This was referenced Jul 17, 2026

docs(aztec): clarify deploy framework internals #24761

Merged

refactor(aztec): decision-flavored names in deploy bridging #24762

Merged

Thunkar and others added 7 commits July 17, 2026 07:56

Merge branch 'merge-train/fairies-v5' into gj/upstream_deploy_framework

484c784

address review

1e9d6ec

hardening

a9c3aa6

added funding step

fb78d75

Thunkar requested a review from dbanks12 July 17, 2026 15:43

Thunkar mentioned this pull request Jul 17, 2026

feat(common): vendor upstream deploy framework, replace bridging with fund steps aztec-labs-eng/aztec-kit#118

Merged

Thunkar requested a review from nventuro July 17, 2026 19:24

Thunkar added the backport-to-v5-next label Jul 21, 2026

nventuro added port-to-next Forward-port this merged PR into next and removed backport-to-v5-next labels Aug 5, 2026

nventuro reviewed Aug 5, 2026

View reviewed changes

Thunkar and others added 3 commits August 6, 2026 10:05

Apply suggestions from code review

2c6da74

Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>

Merge branch 'merge-train/fairies-v5' of github.com:AztecProtocol/azt…

74012b1

…ec-packages into gj/upstream_deploy_framework

better gates

d3e7209

Thunkar added 3 commits August 6, 2026 12:27

better dependsOn

0bb7325

better type

e9c8777

clarifying comments

0361ce3

nventuro approved these changes Aug 6, 2026

View reviewed changes

nventuro enabled auto-merge (squash) August 6, 2026 18:00

nventuro merged commit b34c3cb into merge-train/fairies-v5 Aug 6, 2026
12 checks passed

nventuro deleted the gj/upstream_deploy_framework branch August 6, 2026 18:00

aminsammara mentioned this pull request Aug 14, 2026

chore(release): 5.2.0 #25225

Merged

This was referenced Aug 18, 2026

docs: backport v5.2.0 developer and node docs to v5-next #25265

Open

docs: release v5.2.0 developer and node docs #25266

Merged

		* deferred contracts: declare the steps whose effects the args read, or an explicit empty array
		* if they only read pre-existing state.

Uh oh!

Conversation

Thunkar commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dbanks12 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dbanks12 commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Thunkar commented Jul 17, 2026

Uh oh!

nventuro left a comment • 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nventuro Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

Thunkar Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

nventuro Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

Thunkar Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Thunkar commented Jul 14, 2026 •

edited

Loading

dbanks12 commented Jul 17, 2026 •

edited

Loading

nventuro left a comment •

edited

Loading