chore: fix deploy script for 5.x and stop shipping stale deployments.json - #21
Merged
Merged
Conversation
…json The recorded deployments.json addresses were generated under the pre-5.0 address-derivation formula (4.1.0-rc.4 era) and cannot match current derivation — stop copying the file into the published npm package until it is regenerated on a live network. The deploy script itself turned out to be broken since 4.2.0: account self-deployment still passed from: AztecAddress.ZERO, which the NO_FROM sentinel replaced. Fixed, plus hygiene from the modernization audit: - skipClassPublication when the contract class is already registered on-chain (engages on re-runs; within a single fast run the prior class registration may not be mined yet since we wait for PROPOSED) - wait timeouts on sends so a stuck network cannot hang the script - match TX_ERROR_EXISTING_NULLIFIER from @aztec/stdlib/tx instead of a hardcoded string - drop dead 'already registered' catches (registerContract is an idempotent upsert) Validated end-to-end against a local network: account + Dripper + WETH/DAI/USDC all deploy successfully (first verified run of this script on 5.x). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
IlyasRidhuan
force-pushed
the
stack/deploy-tooling
branch
from
August 12, 2026 16:40
1f7f165 to
ffd4a2c
Compare
IlyasRidhuan
approved these changes
Aug 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Deploy-tooling fixes from the modernization audit — the headline: the deploy script has been broken since 4.2.0 and
deployments.jsonis stale.deployments.jsonin the npm package: the recorded addresses were generated under the pre-5.0 address-derivation formula (aztec.js 4.1.0-rc.4 era, never regenerated through four derivation-breaking bumps) and cannot match current derivation. The file stays in-repo but is excluded frombuild-package.shuntil regenerated on a live network.from: AztecAddress.ZERO, which 4.2.0 replaced with theNO_FROMsentinel — the script failed on any 5.x network. This (and the fossilizedv4-devnet-2endpoint) is why the deployments were never regenerated.skipClassPublicationwhen the contract class is already registered on-chain (engages on re-runs; within one fast run the prior registration may not be mined yet since we wait for PROPOSED);wait: { timeout }on sends; matchTX_ERROR_EXISTING_NULLIFIERfrom@aztec/stdlib/txinstead of a hardcoded string; drop dead "already registered" catches (registerContractis an idempotent upsert).Validation
Full end-to-end deploy against a local network: account + Dripper + WETH/DAI/USDC all deploy successfully — the first verified run of this script on 5.x.
Follow-up (not this PR)
Regenerate
deployments.jsonby runningyarn deploy --network testnetwith a current endpoint, then re-enable shipping it; add regeneration to the version-bump checklist.🤖 Generated with Claude Code