v6.0.0

Overview

Migration difficulty: high, mostly because almost everything you pull from moved.

v6 is a hard fork: it is a complete new deployment starting from genesis, not an upgrade of the existing chain. You are standing up a new node against a new network rather than migrating an existing one, so there is no state to carry over and nothing to resync.

Two things to settle before you start: every artifact location changed, and the ACVM_* configuration variables were renamed with no fallback. A node doing real proving fails to start on the old names; one that is not falls back to WASM simulation and starts anyway, much slower, so a clean startup is not evidence that your configuration migrated.

v6.0.0-rc.1 is Testnet only

v6.0.0-rc.1 is for Testnet. Do not run it on Mainnet. The first v6 release for Mainnet will be the v6.0.0 stable release.

New repository, image and package locations

Everything moved. Old locations keep what was already published, so existing v5 setups keep working, but nothing new lands there.

	v5 and earlier	v6
Source repository	AztecProtocol/aztec-packages	aztec-labs-eng/aztec-node
Docker images	aztecprotocol/aztec	azteclabs/aztec
Prover agent image	aztecprotocol/aztec-prover-agent	azteclabs/aztec-prover-agent
npm (client packages)	@aztec/*	@aztec-labs/*
npm (foundation packages)	@aztec/bb.js, @aztec/noir-*	@aztec-foundation/*
Aztec.nr	in the monorepo	aztec-labs-eng/aztec-nr

Update your image references first. A compose file or Helm values still pointing at aztecprotocol/aztec will pull a v5 image and fail against a v6 network.

- image: aztecprotocol/aztec:5.2.0
+ image: azteclabs/aztec:6.0.0-rc.1

The @aztec npm scope keeps the packages published for earlier versions, so an existing project pinned to a v5 version continues to resolve. The vendored viem fork is unchanged and is still consumed from @aztec/viem.

Behaviour changes

ACVM_* configuration renamed to NOIR_EXECUTE_*

Protocol circuits are now executed with noir's noir-execute rather than the acvm binary, and the configuration naming the executor follows the tool. What you point it at is unchanged.

Old	New
ACVM_BINARY_PATH	NOIR_EXECUTE_BINARY_PATH
ACVM_WORKING_DIRECTORY	NOIR_EXECUTE_WORKING_DIRECTORY
--sequencer.acvmBinaryPath	--sequencer.noirExecuteBinaryPath
--sequencer.acvmWorkingDirectory	--sequencer.noirExecuteWorkingDirectory
--proverNode.acvmBinaryPath	--proverNode.noirExecuteBinaryPath
--proverNode.acvmWorkingDirectory	--proverNode.noirExecuteWorkingDirectory

- ACVM_BINARY_PATH=/usr/src/labs-aztec-toolchain/bin/noir-execute
- ACVM_WORKING_DIRECTORY=/usr/src/acvm
+ NOIR_EXECUTE_BINARY_PATH=/usr/src/labs-aztec-toolchain/bin/noir-execute
+ NOIR_EXECUTE_WORKING_DIRECTORY=/usr/src/noir-execute

There is no fallback to the old names. A prover agent exits with Requested real proving but no path to bb or noir-execute binaries provided; a prover node or sequencer configured for real proofs throws from BBNativeRollupProver.new when it tries to stat an undefined path. Only a node running without real proofs survives, by falling back to WASM simulation, which is much slower, so a node that appears to start may still be badly degraded.

If you run the release image it sets the new variables itself, and its default working directory moves from /usr/src/acvm to /usr/src/noir-execute. Check any values you override.

Attester-initiated sequencer exits

A position can now be exited by its attester rather than only by the registered withdrawer, and exits can be batched: one relayed transaction instead of one per position. That is the point for anyone running tens or hundreds of delegations.

Three functions are live on the rollup:

Function	What it does
initiateWithdrawByAttester(address)	Exit one position. Caller must be the attester.
initiateWithdrawByAttesterBatch(...)	Relay many attester-signed exits. Reverts if any entry is invalid.
initiateWithdrawByAttesterBatchUpToLimit(...)	Same, but processes the largest permitted prefix instead of reverting.

CLI wrappers are not in v6.0.0-rc.1

The aztec initiate-withdraw-by-attester, initiate-withdraw-by-attester-batch and sign-attester-exit commands are not in the v6.0.0-rc.1 toolchain. They are expected in the v6.0.0 stable release. Until then the functions are callable directly, as below.

Calling the contract directly

Exit a single position, signed and submitted by the attester:

cast send $ROLLUP "initiateWithdrawByAttester(address)" $ATTESTER \
    --private-key $ATTESTER_KEY --rpc-url $L1_RPC

Batching needs an EIP-712 signature per attester. The domain is { name: "Aztec Rollup", version: "1", chainId: <L1 chain id>, verifyingContract: <rollup> } and the type is AttesterExit(address attester,uint256 deadline). Sign one per position:

cast wallet sign --private-key $ATTESTER_KEY --data '{
  "domain":{"name":"Aztec Rollup","version":"1","chainId":'$L1_CHAIN_ID',"verifyingContract":"'$ROLLUP'"},
  "types":{"AttesterExit":[{"name":"attester","type":"address"},{"name":"deadline","type":"uint256"}]},
  "primaryType":"AttesterExit",
  "message":{"attester":"'$ATTESTER'","deadline":"'$DEADLINE'"}
}'

Then relay them. Each entry is (attester, deadline, (v, r, s)), and the relayer pays the gas, so the submitting key need not be an attester:

cast send $ROLLUP \
    "initiateWithdrawByAttesterBatchUpToLimit((address,uint256,(uint8,bytes32,bytes32))[])" \
    "[($ATTESTER_0,$DEADLINE,($V0,$R0,$S0)),($ATTESTER_1,$DEADLINE,($V1,$R1,$S1))]" \
    --private-key $RELAYER_KEY --rpc-url $L1_RPC

deadline is a unix timestamp and must be in the future. Each attester may appear only once per batch. Prefer the UpToLimit variant for large batches: the plain initiateWithdrawByAttesterBatch reverts the whole transaction if any single entry is rejected, losing the gas for the rest.

Withdrawer-initiated exits are unchanged.

New node RPC methods

Two additions to the JSON-RPC surface. Both are additive; nothing was removed.

Method	What it is for
aztec_getTxEffectMembershipWitness	Membership proof for a transaction's effects.
aztec_getValidatorStatsBatch	Validator statistics for several attesters in one call.

Both currently render under "Other methods" in the node API reference because the generator has no grouping for them yet.

Upgrade checklist

1. Point your image references at azteclabs/aztec and azteclabs/aztec-prover-agent.
2. Rename ACVM_* to NOIR_EXECUTE_* in your environment, compose files or Helm values, before starting a v6 node.
3. Confirm any overridden working directory matches the new default if you rely on the release image.
4. Take the L1 contract addresses and the RPC endpoint for the network you are joining from networks.md. v6 is a new deployment, so none of the v5 values carry over.

Full release notes

For the developer-facing changes in this release (the npm scope moves in detail, the aztec-nr repository move, Aztec.js artifact and return-type changes, and the removed CLI commands), see the migration notes.