Migration notes
Aztec is in active development. Each version may introduce breaking changes that affect compatibility with previous versions. This page documents common errors and difficulties you might encounter when upgrading, along with guidance on how to resolve them.
TBD
4.1.0-rc.2
[Aztec.js] simulate(), send(), and deploy return types changed to always return objects
All SDK interaction methods now return structured objects that include offchain output alongside the primary result. This affects .simulate(), .send(), deploy .send(), and Wallet.sendTx().
Impact: Every call site that uses .simulate(), .send(), or deploy must destructure the result. This is a mechanical transformation. Custom wallet implementations must update sendTx() to return the new object shapes, using extractOffchainOutput to decode offchain messages from raw effects.
The offchain output includes two fields:
offchainEffects— raw offchain effects emitted during execution, other thanoffchainMessagesoffchainMessages— decoded messages intended for specific recipients
We are making this change now so in the future we can add more fields to the responses of this APIs without breaking backwards compatibility, so this won't ever happen again.
simulate() — always returns { result, offchainEffects, offchainMessages } object:
- const value = await contract.methods.foo(args).simulate({ from: sender });
+ const { result: value } = await contract.methods.foo(args).simulate({ from: sender });
When using includeMetadata or fee.estimateGas, stats and estimatedGas are also available as optional fields on the same object:
- const { stats, estimatedGas } = await contract.methods.foo(args).simulate({
+ const sim = await contract.methods.foo(args).simulate({
from: sender,
includeMetadata: true,
});
+ const stats = sim.stats!;
+ const estimatedGas = sim.estimatedGas!;
SimulationReturn is no longer a generic conditional type — it's a single flat type with optional stats and estimatedGas fields.
send() — returns { receipt, offchainEffects, offchainMessages } object:
- const receipt = await contract.methods.foo(args).send({ from: sender });
+ const { receipt } = await contract.methods.foo(args).send({ from: sender });
When using NO_WAIT, returns { txHash, offchainEffects, offchainMessages } instead of a bare TxHash:
- const txHash = await contract.methods.foo(args).send({ from: sender, wait: NO_WAIT });
+ const { txHash } = await contract.methods.foo(args).send({ from: sender, wait: NO_WAIT });
Offchain messages emitted by the transaction are available on the result:
const { receipt, offchainMessages } = await contract.methods.foo(args).send({ from: sender });
for (const msg of offchainMessages) {
console.log(`Message for ${msg.recipient} from contract ${msg.contractAddress}:`, msg.payload);
}
Deploy — returns { contract, receipt, offchainEffects, offchainMessages } object:
- const myContract = await MyContract.deploy(wallet, ...args).send({ from: sender });
+ const { contract: myContract } = await MyContract.deploy(wallet, ...args).send({ from: sender });
The deploy receipt is also available via receipt if needed (e.g. for receipt.txHash or receipt.transactionFee).
Custom wallet implementations — sendTx() must return objects:
If you implement the Wallet interface (or extend BaseWallet), the sendTx() method must now return objects that include offchain output. Use extractOffchainOutput to split raw effects into decoded messages and remaining effects:
+ import { extractOffchainOutput } from '@aztec/aztec.js/contracts';
async sendTx(executionPayload, opts) {
const provenTx = await this.pxe.proveTx(...);
+ const offchainOutput = extractOffchainOutput(provenTx.getOffchainEffects());
const tx = await provenTx.toTx();
const txHash = tx.getTxHash();
await this.aztecNode.sendTx(tx);
if (opts.wait === NO_WAIT) {
- return txHash;
+ return { txHash, ...offchainOutput };
}
const receipt = await waitForTx(this.aztecNode, txHash, opts.wait);
- return receipt;
+ return { receipt, ...offchainOutput };
}
Scope enforcement for private state access (TXE and PXE)
Scope enforcement is now active across both TXE (test environment) and PXE (client). Previously, private execution could implicitly access any account's keys and notes. Now, only the caller (from) address is in scope by default, and accessing another address's private state requires explicitly granting scope.
Noir developers (TXE)
TXE now enforces scope isolation, matching PXE behavior. During private execution, only the caller's keys and notes are accessible. If a Noir test accesses private state of an address other than from, it will fail. When from is the zero address, scopes are empty (deny-all).
If your TXE tests fail with key or note access errors, ensure the test is calling from the correct address, or restructure the test to match the expected access pattern.
Aztec.js developers (PXE/Wallet)
The wallet now passes scopes to PXE, and only the from address is in scope by default. Auto-expansion of scopes for nested calls to registered accounts has been removed. A new additionalScopes option is available on send(), simulate(), and deploy() for cases where private execution needs access to another address's keys or notes.
When do you need additionalScopes?
-
Deploying contracts whose constructor initializes private storage (e.g., account contracts, or any contract using
SinglePrivateImmutable/SinglePrivateMutablein the constructor). The contract's own address must be in scope so its nullifier key is accessible during initialization. -
Operations that access another contract's private state (e.g., withdrawing from an escrow contract that nullifies the contract's own token notes).
**Example: deploying a contract with private storage (e.g., `PrivateToken`)**
```diff
const tokenDeployment = PrivateTokenContract.deployWithPublicKeys(
tokenPublicKeys, wallet, initialBalance, sender,
);
const tokenInstance = await tokenDeployment.getInstance();
await wallet.registerContract(tokenInstance, PrivateTokenContract.artifact, tokenSecretKey);
const token = await tokenDeployment.send({
from: sender,
+ additionalScopes: [tokenInstance.address],
});
Example: withdrawing from an escrow contract
await escrowContract.methods
.withdraw(token.address, amount, recipient)
- .send({ from: owner });
+ .send({ from: owner, additionalScopes: [escrowContract.address] });
simulateUtility renamed to executeUtility
The simulateUtility method and related types have been renamed to executeUtility across the entire stack to better reflect that utility functions are executed, not simulated.
TypeScript:
- import { SimulateUtilityOptions, UtilitySimulationResult } from '@aztec/aztec.js';
+ import { ExecuteUtilityOptions, UtilityExecutionResult } from '@aztec/aztec.js';
- const result: UtilitySimulationResult = await wallet.simulateUtility(functionCall, opts);
+ const result: UtilityExecutionResult = await wallet.executeUtility(functionCall, opts);
Noir (test environment):
- let result = env.simulate_utility(my_contract_address, selector);
+ let result = env.execute_utility(my_contract_address, selector);
[Protocol] include_by_timestamp renamed to expiration_timestamp
The include_by_timestamp field has been renamed to expiration_timestamp across the protocol to better convey its meaning.
Noir:
- context.set_tx_include_by_timestamp(123456789);
+ context.set_expiration_timestamp(123456789);
[CLI] Dockerless CLI Installation
The Aztec CLI is now installed without Docker. The installation command has changed:
Old installation (deprecated):
bash -i <(curl -sL https://install.aztec.network)
aztec-up <version>
New installation:
VERSION=<version> bash -i <(curl -sL https://install.aztec.network/<version>)
For example, to install version 4.1.0-rc.2:
VERSION=4.1.0-rc.2 bash -i <(curl -sL https://install.aztec.network/4.1.0-rc.2)
Key changes:
- Docker is no longer required to run the Aztec CLI tools
- The
VERSIONenvironment variable must be set in the installation command - The version must also be included in the URL path
aztec-up is now a version manager:
After installation, aztec-up functions as a version manager with the following commands:
| Command | Description |
|---|---|
aztec-up install <version> | Install a specific version and switch to it |
aztec-up use <version> | Switch to an already installed version |
aztec-up list | List all installed versions |
aztec-up self-update | Update aztec-up itself |
@aztec/test-wallet replaced by @aztec/wallets
The @aztec/test-wallet package has been removed. Use @aztec/wallets instead, which provides EmbeddedWallet with a static create() factory:
- import { TestWallet, registerInitialLocalNetworkAccountsInWallet } from '@aztec/test-wallet/server';
+ import { EmbeddedWallet } from '@aztec/wallets/embedded';
+ import { registerInitialLocalNetworkAccountsInWallet } from '@aztec/wallets/testing';
- const wallet = await TestWallet.create(node);
+ const wallet = await EmbeddedWallet.create(node);
For browser environments, the same import resolves to a browser-specific implementation automatically via conditional exports:X
The EmbeddedWallet.create() factory accepts an optional second argument for logger injection and ephemeral storage:
const wallet = await EmbeddedWallet.create(node, {
logger: myLogger, // custom logger; child loggers derived via createChild()
ephemeral: true, // use in-memory stores (no persistence)
});
[Aztec.nr] debug_log module renamed to logging
The debug_log module has been renamed to logging to avoid naming collisions with per-level logging functions that were introduced in this PR (warn_log, info_log, debug_log... and the "format" versions warn_log_format, debug_log_format). Update all import paths accordingly:
- use aztec::oracle::debug_log::debug_log;
- use aztec::oracle::debug_log::debug_log_format;
+ use aztec::oracle::logging::debug_log;
+ use aztec::oracle::logging::debug_log_format;
For inline paths:
- aztec::oracle::debug_log::debug_log_format("msg: {}", [value]);
+ aztec::oracle::logging::debug_log_format("msg: {}", [value]);
The function names themselves (debug_log, debug_log_format, debug_log_with_level, debug_log_format_with_level) are unchanged.
Additionally, debug_log_format_slice has been removed. Use debug_log_format instead, which accepts a fixed-size array of fields:
- debug_log_format_slice("values: {}", &[value1, value2]);
+ debug_log_format("values: {}", [value1, value2]);
This has been done as usage of Noir slices is discouraged and the function was unused in the aztec codebase.
[AztecNode] Sentinel validator status values renamed
The ValidatorStatusInSlot values returned by getValidatorsStats and getValidatorStats have been updated to reflect the multi-block-per-slot model, where blocks and checkpoints are distinct concepts:
- 'block-mined'
+ 'checkpoint-mined'
- 'block-proposed'
+ 'checkpoint-proposed'
- 'block-missed'
+ 'checkpoint-missed' // blocks were proposed but checkpoint was not attested
+ 'blocks-missed' // no block proposals were sent at all
The attestation-sent and attestation-missed values are unchanged but now explicitly refer to checkpoint attestations.
The ValidatorStatusType used for categorizing statuses has also changed from 'block' | 'attestation' to 'proposer' | 'attestation'.
[aztec.js] getDecodedPublicEvents renamed to getPublicEvents with new signature
The getDecodedPublicEvents function has been renamed to getPublicEvents and now uses a filter object instead of positional parameters:
- import { getDecodedPublicEvents } from '@aztec/aztec.js/events';
+ import { getPublicEvents } from '@aztec/aztec.js/events';
- const events = await getDecodedPublicEvents(node, eventMetadata, fromBlock, limit);
+ const events = await getPublicEvents(node, eventMetadata, {
+ fromBlock,
+ toBlock,
+ contractAddress, // optional
+ txHash, // optional
+ });
The new function returns richer metadata including contractAddress, txHash, l2BlockNumber, and l2BlockHash for each event:
import { getPublicEvents } from "@aztec/aztec.js/events";
import { MyContract } from "./artifacts/MyContract.js";
// Query events from a contract
const events = await getPublicEvents<{ amount: bigint; sender: AztecAddress }>(
aztecNode,
MyContract.events.Transfer,
{ contractAddress: myContractAddress, fromBlock: BlockNumber(1) },
);
// Each event includes decoded data and metadata
for (const { event, metadata } of events) {
console.log(`Transfer of ${event.amount} from ${event.sender}`);
console.log(` Block: ${metadata.l2BlockNumber}, Tx: ${metadata.txHash}`);
console.log(` Contract: ${metadata.contractAddress}`);
}
[Aztec.nr] nophasecheck renamed as allow_phase_change
[AztecNode] Removed sibling path RPC methods
The following methods have been removed from the AztecNode interface:
getNullifierSiblingPathgetNoteHashSiblingPathgetArchiveSiblingPathgetPublicDataSiblingPath
These methods were not used by PXE and returned a subset of the information already available through the corresponding membership witness methods:
| Removed Method | Use Instead |
|---|---|
getNullifierSiblingPath | getNullifierMembershipWitness |
getNoteHashSiblingPath | getNoteHashMembershipWitness |
getArchiveSiblingPath | getBlockHashMembershipWitness |
getPublicDataSiblingPath | getPublicDataWitness |
The membership witness methods return both the sibling path and additional context (leaf index, preimage data) needed for proofs.
[Protocol] "Nullifier secret key" renamed to "nullifier hiding key" (nsk → nhk)
The nullifier secret key (nsk_m / nsk_app) has been renamed to nullifier hiding key (nhk_m / nhk_app). This is a protocol-breaking change: the domain separator string changes from "az_nsk_m" to "az_nhk_m", producing a different constant value.
Noir changes:
- context.request_nsk_app(npk_m_hash)
+ context.request_nhk_app(npk_m_hash)
- get_nsk_app(npk_m_hash)
+ get_nhk_app(npk_m_hash)
TypeScript changes:
- import { computeAppNullifierSecretKey, deriveMasterNullifierSecretKey } from '@aztec/stdlib/keys';
+ import { computeAppNullifierHidingKey, deriveMasterNullifierHidingKey } from '@aztec/stdlib/keys';
- const masterNullifierSecretKey = deriveMasterNullifierSecretKey(secret);
+ const masterNullifierHidingKey = deriveMasterNullifierHidingKey(secret);
- const nskApp = await computeAppNullifierSecretKey(masterNullifierSecretKey, contractAddress);
+ const nhkApp = await computeAppNullifierHidingKey(masterNullifierHidingKey, contractAddress);
The GeneratorIndex.NSK_M enum member is now GeneratorIndex.NHK_M.
[AztecNode/Aztec.nr] getArchiveMembershipWitness renamed to getBlockHashMembershipWitness
The getArchiveMembershipWitness method has been renamed to getBlockHashMembershipWitness to better reflect its purpose. Block hashes are the leaves of the archive tree - each time a new block is added to the chain, its block hash is appended as a new leaf. This rename clarifies that the method finds a membership witness for a block hash in the archive tree.
TypeScript (AztecNode interface):
- const witness = await aztecNode.getArchiveMembershipWitness(blockNumber, archiveLeaf);
+ const witness = await aztecNode.getBlockHashMembershipWitness(blockNumber, blockHash);
The second parameter type has also changed from Fr to BlockHash.
Noir (aztec-nr):
- use dep::aztec::oracle::get_membership_witness::get_archive_membership_witness;
+ use dep::aztec::oracle::get_membership_witness::get_block_hash_membership_witness;
- let witness = get_archive_membership_witness(block_header, leaf_value);
+ let witness = get_block_hash_membership_witness(anchor_block_header, block_hash);
[Aztec.nr] protocol_types renamed to protocol
The protocol_types re-export from the aztec crate has been renamed to protocol. Update all imports accordingly:
- use dep::aztec::protocol_types::address::AztecAddress;
+ use dep::aztec::protocol::address::AztecAddress;
Protocol contract interface separate from protocol contracts
We've stripped protocol contract of aztec-nr macros in order for auditors to not need to audit them (protocol contracts are to be audited during the protocol circuits audit).
This results in the nice Noir interface no longer being generated.
For context, this is the interface I am talking about:
let update_delay = self.view(MyContract::at(my_contract_address).my_fn());
where the macros generate the MyContract struct.
For this reason we've created place holder protocol contracts in noir-projects/noir-contracts/contracts/protocol_interface that still have these macros applied and hence you can use them to get the interface.
On your side all you need to do is update the dependency in Nargo.toml:
-auth_contract = { path = "../../protocol/auth_registry_contract" }
+auth_contract = { path = "../../protocol_interface/auth_registry_interface" }
-instance_contract = { path = "../../protocol/contract_instance_registry" }
+instance_contract = { path = "../../protocol_interface/contract_instance_registry_interface" }
[aztec-nr] History module refactored to use standalone functions
The aztec::history module has been refactored to use standalone functions instead of traits. This changes the calling convention from method syntax to function syntax.
- use dep::aztec::history::note_inclusion::ProveNoteInclusion;
+ use dep::aztec::history::note::assert_note_existed_by;
let block_header = context.get_anchor_block_header();
- let confirmed_note = block_header.prove_note_inclusion(hinted_note);
+ let confirmed_note = assert_note_existed_by(block_header, hinted_note);
Function name and module mapping:
| Old (trait method) | New (standalone function) |
|---|---|
history::note_inclusion::prove_note_inclusion | history::note::assert_note_existed_by |
history::note_validity::prove_note_validity | history::note::assert_note_was_valid_by |
history::nullifier_inclusion::prove_nullifier_inclusion | history::nullifier::assert_nullifier_existed_by |
history::nullifier_inclusion::prove_note_is_nullified | history::note::assert_note_was_nullified_by |
history::nullifier_non_inclusion::prove_nullifier_non_inclusion | history::nullifier::assert_nullifier_did_not_exist_by |
history::nullifier_non_inclusion::prove_note_not_nullified | history::note::assert_note_was_not_nullified_by |
history::contract_inclusion::prove_contract_deployment | history::deployment::assert_contract_bytecode_was_published_by |
history::contract_inclusion::prove_contract_non_deployment | history::deployment::assert_contract_bytecode_was_not_published_by |
history::contract_inclusion::prove_contract_initialization | history::deployment::assert_contract_was_initialized_by |
history::contract_inclusion::prove_contract_non_initialization | history::deployment::assert_contract_was_not_initialized_by |
history::public_storage::public_storage_historical_read | history::storage::public_storage_historical_read |
[Aztec.js] Transaction sending API redesign
The old chained .send().wait() pattern has been replaced with a single .send(options) call that handles both sending and waiting.
+ import { Contract, NO_WAIT } from '@aztec/aztec.js/contracts';
- const receipt = await contract.methods.transfer(recipient, amount).send().wait();
// Send now waits by default
+ const receipt = await contract.methods.transfer(recipient, amount).send({ from: sender });
// getTxHash() would confusingly send the transaction too
- const txHash = await contract.methods.transfer(recipient, amount).send().getTxHash();
// NO_WAIT to send the transaction and return TxHash immediately
+ const txHash = await contract.methods.transfer(recipient, amount).send({
+ from: sender,
+ wait: NO_WAIT
+ });
Deployment changes
The old .send().deployed() method has been removed. Deployments now return the contract instance by default, or you can request the full receipt with returnReceipt: true:
- const contract = await MyContract.deploy(wallet, ...args).send().deployed();
- const { contract, instance } = await MyContract.deploy(wallet, ...args).send().wait();
+ const contract = await MyContract.deploy(wallet, ...args).send({ from: deployer });
+ const { contract, instance } = await MyContract.deploy(wallet, ...args).send({
+ from: deployer,
+ wait: { returnReceipt: true },
+ });
Breaking changes to Wallet interface
getTxReceipt() has been removed from the interface.
sendTx method signature has changed to support the new wait behavior:
- sendTx(payload: ExecutionPayload, options: SendOptions): Promise<TxReceipt>
+ sendTx<W extends InteractionWaitOptions = undefined>(
+ payload: ExecutionPayload,
+ options: SendOptions<W>
+ ): Promise<SendReturn<W>>
Manual waiting with waitForTx
When using NO_WAIT to send transactions, you can manually wait for confirmation using the waitForTx utility:
import { waitForTx } from "@aztec/aztec.js/node";
const txHash = await contract.methods.transfer(recipient, amount).send({
from: sender,
wait: NO_WAIT,
});
const receipt = await waitForTx(node, txHash, {
timeout: 60000, // Optional: timeout in ms
interval: 1000, // Optional: polling interval in ms
dontThrowOnRevert: true, // Optional: return receipt even if tx reverted
});
[aztec-nr] Removal of intermediate modules
Lots of unnecessary modules have been removed from the API, making imports shorter. These are the modules that contain just a single struct, in which the module has the same name as the struct.
- use aztec::state_vars::private_mutable::PrivateMutable;
+ use aztec::state_vars::PrivateMutable;
Affected structs include all state variables, notes, contexts, messages, etc.
[L1 Contracts] Fee asset pricing direction inverted
The fee model now uses ethPerFeeAsset instead of the previous feeAssetPerEth. This change inverts how the exchange rate is represented: values now express how much ETH one fee asset (AZTEC) is worth, with 1e12 precision.
Key changes:
FeeHeader.feeAssetPerEth→FeeHeader.ethPerFeeAssetRollupConfigInputnow requiresinitialEthPerFeeAssetparameter at deployment- Default value:
1e7(0.00001 ETH per AZTEC) - Valid range:
100(1e-10 ETH/AZTEC) to1e11(0.1 ETH/AZTEC)
New environment variable for node operators:
AZTEC_INITIAL_ETH_PER_FEE_ASSET- Sets the initial ETH per fee asset price with 1e12 precision
[L1 Contracts] Fee asset price modifier now in basis points
The OracleInput.feeAssetPriceModifier field now expects values in basis points (BPS) instead of the previous representation. The modifier is applied as a percentage change to the ETH/AZTEC price each checkpoint.
Key changes:
- Valid range:
-100to+100BPS (±1% max change per checkpoint) - A value of
+100increases the price by 1%,-100decreases by 1% - Validated by
MAX_FEE_ASSET_PRICE_MODIFIER_BPS = 100
[Aztec.js] Wallet batching now supports all methods
The BatchedMethod type is now a discriminated union that ensures type safety: the args must match the specific method name. This prevents runtime errors from mismatched arguments.
- // Before: Only 5 methods could be batched
- const results = await wallet.batch([
- { name: "registerSender", args: [address, "alias"] },
- { name: "sendTx", args: [payload, options] },
- ]);
+ // After: All methods can be batched
+ const results = await wallet.batch([
+ { name: "getChainInfo", args: [] },
+ { name: "getContractMetadata", args: [contractAddress] },
+ { name: "registerSender", args: [address, "alias"] },
+ { name: "simulateTx", args: [payload, options] },
+ { name: "sendTx", args: [payload, options] },
+ ]);
[Aztec.js] Refactored getContractMetadata and getContractClassMetadata in Wallet
The contract metadata methods in the Wallet interface have been refactored to provide more granular information and avoid expensive round-trips.
ContractMetadata:
{
- contractInstance?: ContractInstanceWithAddress,
+ instance?: ContractInstanceWithAddress; // Instance registered in the Wallet, if any
isContractInitialized: boolean; // Is the init nullifier onchain? (already there)
isContractPublished: boolean; // Has the contract been published? (already there)
+ isContractUpdated: boolean; // Has the contract been updated?
+ updatedContractClassId?: Fr; // If updated, the new class ID
}
ContractClassMetadata:
This method loses the ability to request the contract artifact via the includeArtifact flag
{
- contractClass?: ContractClassWithId;
- artifact?: ContractArtifact;
isContractClassPubliclyRegistered: boolean; // Is the class registered onchain?
+ isArtifactRegistered: boolean; // Does the Wallet know about this artifact?
}
- Removes expensive artifact/class transfers between wallet and app
- Separates PXE storage info (
instance,isArtifactRegistered) from public chain info (isContractPublished,isContractClassPubliclyRegistered) - Makes it easier to determine if actions like
registerContractare needed
[Aztec.js] Removed UnsafeContract and protocol contract helper functions
The UnsafeContract class and async helper functions (getFeeJuice, getClassRegistryContract, getInstanceRegistryContract) have been removed. Protocol contracts are now accessed via auto-generated type-safe wrappers with only the ABI (no bytecode). Since PXE always has protocol contract artifacts available, importing and using these contracts from aztec.js is very lightweight and follows the same pattern as regular user contracts.
Migration:
- import { getFeeJuice, getClassRegistryContract, getInstanceRegistryContract } from '@aztec/aztec.js/contracts';
+ import { FeeJuiceContract, ContractClassRegistryContract, ContractInstanceRegistryContract } from '@aztec/aztec.js/protocol';
- const feeJuice = await getFeeJuice(wallet);
+ const feeJuice = FeeJuiceContract.at(wallet);
await feeJuice.methods.check_balance(feeLimit).send().wait();
- const classRegistry = await getClassRegistryContract(wallet);
+ const classRegistry = ContractClassRegistryContract.at(wallet);
await classRegistry.methods.publish(...).send().wait();
- const instanceRegistry = await getInstanceRegistryContract(wallet);
+ const instanceRegistry = ContractInstanceRegistryContract.at(wallet);
await instanceRegistry.methods.publish_for_public_execution(...).send().wait();
Note: The higher-level utilities like publishInstance, publishContractClass, and broadcastPrivateFunction from @aztec/aztec.js/deployment are still available and unchanged. These utilities use the new wrappers internally.
[Aztec.nr] Renamed Router contract
Router contract has been renamed as PublicChecks contract.
The name of the contract became stale as its use changed from routing public calls through it to simply having public functions that can be called by anyone.
Having these "standard checks" on one contract results in a potentially large privacy set for apps that use it.
[Aztec Node] getBlockByHash and getBlockHeaderByHash removed
The getBlockByHash and getBlockHeaderByHash methods have been removed. Use getBlock and getBlockHeader with a block hash instead.
Migration:
- const block = await node.getBlockByHash(blockHash);
+ const block = await node.getBlock(blockHash);
- const header = await node.getBlockHeaderByHash(blockHash);
+ const header = await node.getBlockHeader(blockHash);
[Aztec.nr] Oracle functions now take BlockHeader instead of block number
The low-level oracle functions for fetching membership witnesses and storage now take a BlockHeader instead of a block_number: u32. This change improves type safety and ensures the correct block state is queried.
Affected functions:
get_note_hash_membership_witness(block_header, leaf_value)- was(block_number, leaf_value)get_archive_membership_witness(block_header, leaf_value)- was(block_number, leaf_value)get_nullifier_membership_witness(block_header, nullifier)- was(block_number, nullifier)get_low_nullifier_membership_witness(block_header, nullifier)- was(block_number, nullifier)get_public_data_witness(block_header, public_data_tree_index)- was(block_number, public_data_tree_index)storage_read(block_header, address, storage_slot)- was(address, storage_slot, block_number)
Migration:
If you were calling these oracle functions directly (which is uncommon), update your code to pass a BlockHeader instead of a block number:
- let witness = get_note_hash_membership_witness(self.global_variables.block_number, note_hash);
+ let witness = get_note_hash_membership_witness(self, note_hash);
- let witness = get_nullifier_membership_witness(block_number, nullifier);
+ let witness = get_nullifier_membership_witness(block_header, nullifier);
- let value: T = storage_read(address, slot, block_number);
+ let value: T = storage_read(block_header, address, slot);
Note: The high-level history proof functions on BlockHeader (such as prove_note_inclusion, prove_nullifier_inclusion, etc.) are not affected by this change. They continue to work the same way.
[Toolchain] Node.js upgraded to v24
Node.js minimum version changed from v22 to v24.12.0.
[L1 Contracts] Renamed base fee to min fee
The L1 rollup contract functions and types related to fee calculation have been renamed from "base fee" to "min fee" to better reflect their purpose.
Renamed functions:
getManaBaseFeeAt→getManaMinFeeAtgetManaBaseFeeComponentsAt→getManaMinFeeComponentsAt
Renamed types:
ManaBaseFeeComponents→ManaMinFeeComponents
Renamed errors:
Rollup__InvalidManaBaseFee→Rollup__InvalidManaMinFee
Migration:
- uint256 fee = rollup.getManaBaseFeeAt(timestamp, true);
+ uint256 fee = rollup.getManaMinFeeAt(timestamp, true);
- ManaBaseFeeComponents memory components = rollup.getManaBaseFeeComponentsAt(timestamp, true);
+ ManaMinFeeComponents memory components = rollup.getManaMinFeeComponentsAt(timestamp, true);
[Aztec.js] Renamed base fee to min fee
The Aztec Node API method for getting current fees has been renamed:
getCurrentBaseFees→getCurrentMinFees
Migration:
- const fees = await node.getCurrentBaseFees();
+ const fees = await node.getCurrentMinFees();
[Aztec.nr] Renamed fee context methods
The context methods for accessing fee information have been renamed:
context.base_fee_per_l2_gas()→context.min_fee_per_l2_gas()context.base_fee_per_da_gas()→context.min_fee_per_da_gas()
Migration:
- let l2_fee = context.base_fee_per_l2_gas();
- let da_fee = context.base_fee_per_da_gas();
+ let l2_fee = context.min_fee_per_l2_gas();
+ let da_fee = context.min_fee_per_da_gas();
[Aztec.nr] Cleaning up message sender functions
There has been a design decision made to have low-level API exposed on self.context and a nicer higher-level API exposed directly on self.
Currently the msg_sender function on self was a copy of that same function on self.context.
The msg_sender function on self got modified to return the message sender address directly instead of having it be wrapped in an Option<...>.
In case the underlying message sender is none the function panics.
You need to update your code to no longer trigger the unwrap on the return value:
- let message_sender: AztecAddress = self.msg_sender().unwrap();
+ let message_sender: AztecAddress = self.msg_sender();
If you want to handle the null case use the lower level API of context:
- let maybe_message_sender: Option<AztecAddress> = self.msg_sender();
+ let maybe_message_sender: Option<AztecAddress> = self.context.maybe_msg_sender();
The self.context.msg_sender_unsafe method has been dropped as its use can be replaced with the standard self.context.maybe_msg_sender function.
[Aztec.nr] Renamed message delivery options
The following terms have been renamed:
MessageDelivery::UNCONSTRAINED_OFFCHAIN->MessageDelivery::OFFCHAINMessageDelivery::UNCONSTRAINED_ONCHAIN->MessageDelivery::ONCHAIN_UNCONSTRAINEDMessageDelivery::CONSTRAINED_ONCHAIN->MessageDelivery::ONCHAIN_CONSTRAINED
We believe these names will better convey the meaning of the concepts.
[Aztec Node] changes to getLogsByTags endpoint
getLogsByTags endpoint has been optimized for our new log sync algorithm and these are the changes:
- The
logsPerTagpagination argument has been removed. Pagination was unnecessary here, since multiple logs per tag typically only occur if several devices are sending logs from the same sender to a recipient, which is unlikely to generate enough logs to require pagination. - The structure of
TxScopedL2Loghas been revised to meet the requirements of our new log sync algorithm. - The endpoint has been separated into two versions:
getPrivateLogsByTagsandgetPublicLogsByTagsFromContract. This change was made because it was never desirable in PXE to mix public and private logs. The public version requires both aTagand a contract address as input. In contrast to the private version—which usesSiloedTag(a tag that hashes the raw tag with the emitting contract's address)—the public version uses the rawTagtype, since kernels do not hash the tag with the contract address for public logs.
[AVM] Gas cost multipliers for public execution to reach simulation/proving parity
Gas costs for several AVM opcodes have been adjusted with multipliers to better align public simulation costs with actual proving costs.
| Opcode | Multiplier | Previous Cost | New Cost |
|---|---|---|---|
| FDIV | 25x | 9 | 225 |
| SLOAD | 10x | 129 | 1,290 |
| SSTORE | 20x | 1,657 | 33,140 |
| NOTEHASHEXISTS | 4x | 126 | 504 |
| EMITNOTEHASH | 15x | 1,285 | 19,275 |
| NULLIFIEREXISTS | 7x | 132 | 924 |
| EMITNULLIFIER | 20x | 1,540 | 30,800 |
| L1TOL2MSGEXISTS | 5x | 108 | 540 |
| SENDL2TOL1MSG | 2x | 209 | 418 |
| CALL | 3x | 3,312 | 9,936 |
| STATICCALL | 3x | 3,312 | 9,936 |
| GETCONTRACTINSTANCE | 4x | 1,527 | 6,108 |
| POSEIDON2 | 15x | 24 | 360 |
| ECADD | 10x | 27 | 270 |
Impact: Contracts with public bytecode performing any of these operations will see increased gas consumption.
[PXE] deprecated getNotes
This function serves only for debugging purposes so we are taking it out of the main PXE API. If you still need to consume it, you can
do so through the new debug sub-module.
- this.pxe.getNotes(filter);
+ this.pxe.debug.getNotes(filter);
3.0.0-devnet.20251212
[Aztec node, archiver] Deprecated getPrivateLogs
Aztec node no longer offers a getPrivateLogs method. If you need to process the logs of a block, you can instead use getBlock and call getPrivateLogs on an L2BlockNew instance. See the diff below for before/after equivalent code samples.
- const logs = await aztecNode.getPrivateLogs(blockNumber, 1);
+ const logs = (await aztecNode.getBlock(blockNumber))?.toL2Block().getPrivateLogs();
[Aztec.nr] Private event emission API changes
Private events are still emitted via the emit function, but this now returns an EventMessage type that must have deliver_to called on it in order to deliver the event message to the intended recipients. This allows for multiple recipients to receive the same event.
- self.emit(event, recipient, delivery_method)
+ self.emit(event).delivery(recipient, delivery_method)
[Aztec.nr] History proof functions no longer require storage_slot parameter
The HintedNote struct now includes a storage_slot field, making it self-contained for proving note inclusion and validity. As a result, the history proof functions in the aztec::history module no longer require a separate storage_slot parameter.
Affected functions:
BlockHeader::prove_note_inclusion- removedstorage_slot: FieldparameterBlockHeader::prove_note_validity- removedstorage_slot: FieldparameterBlockHeader::prove_note_is_nullified- removedstorage_slot: FieldparameterBlockHeader::prove_note_not_nullified- removedstorage_slot: Fieldparameter
Migration:
The storage_slot is now read from hinted_note.storage_slot internally. Simply remove the storage_slot argument from all calls to these functions:
let header = context.get_anchor_block_header();
- header.prove_note_inclusion(hinted_note, storage_slot);
+ header.prove_note_inclusion(hinted_note);
let header = context.get_anchor_block_header();
- header.prove_note_validity(hinted_note, storage_slot, context);
+ header.prove_note_validity(hinted_note, context);
let header = context.get_anchor_block_header();
- header.prove_note_is_nullified(hinted_note, storage_slot, context);
+ header.prove_note_is_nullified(hinted_note, context);
let header = context.get_anchor_block_header();
- header.prove_note_not_nullified(hinted_note, storage_slot, context);
+ header.prove_note_not_nullified(hinted_note, context);
[Aztec.nr] Note fields are now public
All note struct fields are now public, and the new() constructor methods and getter methods have been removed. Notes should be instantiated using struct literal syntax, and fields should be accessed directly.
The motivation for this change has been enshrining of randomness which lead to the new method being unnecessary boilerplate.
Affected notes:
UintNote-valueis now public,new()andget_value()removedAddressNote-addressis now public,new()andget_address()removedFieldNote-valueis now public,new()andvalue()removed
Migration:
- let note = UintNote::new(100);
+ let note = UintNote { value: 100 };
- let value = note.get_value();
+ let value = note.value;
- let address_note = AddressNote::new(owner);
+ let address_note = AddressNote { address: owner };
- let address = address_note.get_address();
+ let address = address_note.address;
- let field_note = FieldNote::new(42);
+ let field_note = FieldNote { value: 42 };
- let value = field_note.value();
+ let value = field_note.value;
[Aztec.nr] emit renamed to deliver
Private state variable functions that created notes and returned their messages no longer return a NoteEmission but instead a NoteMessage. These messages are delivered to their owner via deliver instead of emit. The verb 'emit' remains for things like emitting events.
- self.storage.balances.at(owner).add(5).emit(owner);
+ self.storage.balances.at(owner).add(5).deliver();
To deliver a message to a different recipient, use deliver_to:
- self.storage.balances.at(owner).add(5).emit(other);
+ self.storage.balances.at(owner).add(5).deliver_to(other);
[Aztec.nr] ValueNote renamed to FieldNote and value-note crate renamed to field-note
The ValueNote struct has been renamed to FieldNote to better reflect that it stores a Field value. The crate has also been renamed from value-note to field-note.
Migration:
- Update your
Nargo.tomldependencies:value_note = { path = "..." }→field_note = { path = "..." } - Update imports:
use value_note::value_note::ValueNote→use field_note::field_note::FieldNote - Update type references:
ValueNote→FieldNote - Update generic parameters:
PrivateSet<ValueNote, ...>→PrivateSet<FieldNote, ...>
[Aztec.nr] New balance-set library for managing token balances
A new balance-set library has been created that provides BalanceSet<Context> for managing u128 token balances with UintNote. This consolidates balance management functionality that was previously duplicated across contracts.
Features:
add(amount: u128)- Add to balancesub(amount: u128)- Subtract from balance (with change note)try_sub(amount: u128, max_notes: u32)- Attempt to subtract with configurable note limitbalance_of()- Get total balance (unconstrained)
Usage:
use balance_set::BalanceSet;
#[storage]
struct Storage<Context> {
balances: Owned<BalanceSet<Context>, Context>,
}
// In a private function:
self.storage.balances.at(owner).add(amount).deliver(owner, MessageDelivery.CONSTRAINED_ONCHAIN);
self.storage.balances.at(owner).sub(amount).deliver(owner, MessageDelivery.CONSTRAINED_ONCHAIN);
// In an unconstrained function:
let balance = self.storage.balances.at(owner).balance_of();
[Aztec.nr] EasyPrivateUint deprecated and removed
The EasyPrivateUint type and easy-private-state crate have been deprecated and removed. Use BalanceSet from the balance-set crate instead.
Migration:
- Remove
easy_private_statedependency fromNargo.toml - Add
balance_set = { path = "../../../../aztec-nr/balance-set" }toNargo.toml - Update storage:
EasyPrivateUint<Context>→Owned<BalanceSet<Context>, Context> - Update method calls:
add(amount, owner)→at(owner).add(amount).deliver(owner, MessageDelivery.CONSTRAINED_ONCHAIN)sub(amount, owner)→at(owner).sub(amount).deliver(owner, MessageDelivery.CONSTRAINED_ONCHAIN)get_value(owner)→at(owner).balance_of()(returnsu128instead ofField)
[Aztec.nr] balance_utils removed from value-note (now field-note)
The balance_utils module has been removed from the field-note crate (formerly value-note). If you need similar functionality, implement it locally in your contract or use BalanceSet for u128 balances.
[Aztec.nr] filter_notes_min_sum removed from value-note (now field-note)
The filter_notes_min_sum function has been removed from the field-note crate (formerly in value-note). If you need this functionality, copy it to your contract locally. This function was only used in specific test contracts and doesn't belong in the general-purpose note library.
[Aztec.nr] derive_ecdh_shared_secret_using_aztec_address removed
This function made it annoying to deal with invalid addresses in circuits. If you were using it, replace it with derive_ecdh_shared_secret instead:
-let shared_secret = derive_ecdh_shared_secret_using_aztec_address(secret, address).unwrap();
+let shared_secret = derive_ecdh_shared_secret(secret, address.to_address_point().unwrap().inner);
[Aztec.nr] Note owner is now enshrined
It turns out that in all cases a note always has a logical owner. For this reason we have decided to enshrine the concept of a note owner and you should drop the field from your note:
#[derive(Deserialize, Eq, Packable, Serialize)]
#[note]
pub struct ValueNote {
value: Field,
- owner: AztecAddress,
}
The owner being enshrined means that our API explicitly expects it on the input.
The NoteHash trait got modified as follows:
pub trait NoteHash {
fn compute_note_hash(
self,
+ owner: AztecAddress,
storage_slot: Field,
randomness: Field,
) -> Field;
fn compute_nullifier(
self,
context: &mut PrivateContext,
+ owner: AztecAddress,
note_hash_for_nullification: Field,
) -> Field;
unconstrained fn compute_nullifier_unconstrained(
self,
+ owner: AztecAddress,
note_hash_for_nullification: Field,
) -> Field;
}
Our low-level note utilities now also accept owner as a parameter:
pub fn create_note<Note>(
context: &mut PrivateContext,
+ owner: AztecAddress,
storage_slot: Field,
note: Note,
) -> NoteEmission<Note>
where
Note: NoteType + NoteHash + Packable,
{
...
}
Signature of some functions like destroy_note_unsafe is unchanged:
pub fn destroy_note_unsafe<Note>(
context: &mut PrivateContext,
hinted_note: HintedNote<Note>,
note_hash_read: NoteHashRead,
)
where
Note: NoteHash,
{
...
}
because HintedNote now contains owner.
PrivateImmutable, PrivateMutable and PrivateSet got modified to directly contain the owner instead of implicitly "containing it" by including it in the storage slot via a Map.
These state variables now implement a newly introduced OwnedStateVariable trait (see docs of OwnedStateVariable for explanation of what it is).
These changes make the state variables incompatible with Map and now instead these should be wrapped in new Owned state variable:
#[storage]
struct Storage<Context> {
- private_nfts: Map<AztecAddress, PrivateSet<NFTNote, Context>, Context>,
+ private_nfts: Owned<PrivateSet<NFTNote, Context>, Context>,
}
Note that even though the types of your state variables are changing from Map<AztecAddress, T, Context> to Owned<T, Context>, usage remains unchanged:
let nft_notes = self.storage.private_nfts.at(from).pop_notes(NoteGetterOptions::new().select(NFTNote::properties().token_id, Comparator.EQ, token_id).set_limit(1));
With this change the underlying notes will inherit the storage slot of the Owned state variable.
This is unlike Map where the nested state variable got the storage slot computed as hash([map_storage_slot, key]).
if you had PrivateImmutable or PrivateMutable defined out of a Map, e.g.:
#[storage]
struct Storage<Context> {
signing_public_key: PrivateImmutable<PublicKeyNote, Context>,
}
you were most likely dealing with some kind of admin flow where only the admin can modify the state variable.
Now, unfortunately, there is a bit of a regression and you will need to wrap the state variable in Owned and call at on the state var:
+ use aztec::state_vars::Owned;
#[storage]
struct Storage<Context> {
- signing_public_key: PrivateImmutable<PublicKeyNote, Context>,
+ signing_public_key: Owned<PrivateImmutable<PublicKeyNote, Context>, Context>,
}
#[external("private")]
fn my_external_function() {
- self.storage.signing_public_key.initialize(pub_key_note)
+ self.storage.signing_public_key.at(self.address).initialize(pub_key_note)
.emit(self.address, MessageDelivery.CONSTRAINED_ONCHAIN);
}
We are likely to come up with a concept of admin state variables in the future.
None of the reference notes now contain the owner so if you manually construct AddressNote, UintNote or ValueNote you need to update the call to new method:
- let note = UintNote::new(156, owner);
+ let note = UintNote::new(156);
[Aztec.nr] Note randomness is now handled internally
In order to prevent pre-image attacks, it is necessary to inject randomness to notes. Aztec.nr users were previously expected to add said randomness to their custom note types. From now on, Aztec.nr takes care of handling randomness as built-in note metadata, making it impossible to miss for library users. This change breaks backwards compatibility as we'll discuss below.
Changes to Aztec.nr note types
If you're using any of the following note types, please be aware that randomness no longer is an explicit attribute in them.
- ValueNote
- UintNote
- NFTNote
- AddressNote
Migrating your custom note types: refer to UintNote as an example of how to migrate
We show the changes to UintNote below since it serves as a good example of the adjustments you will need to make to your own custom note types, including those that need to support partial notes.
Remove randomness from note struct
pub struct UintNote {
/// The owner of the note, i.e. the account whose nullifier secret key is required to compute the nullifier.
owner: AztecAddress,
- /// Random value, protects against note hash preimage attacks.
- randomness: Field,
/// The number stored in the note.
value: u128,
}
impl UintNote {
pub fn new(value: u128, owner: AztecAddress) -> Self {
- let randomness = unsafe { random() };
- Self { value, owner, randomness }
+ Self { value, owner }
}
Add randomness to compute_note_hash implementation
The NoteHash trait now requires compute_note_hash to receive a randomness field. This impacts
pub trait NoteHash {
/// ...
- fn compute_note_hash(self, storage_slot: Field) -> Field;
+ fn compute_note_hash(self, storage_slot: Field, randomness: Field) -> Field;
Then in trait implementations:
impl NoteHash for UintNote {
- fn compute_note_hash(self, storage_slot: Field) -> Field {
+ fn compute_note_hash(self, storage_slot: Field, randomness: Field) -> Field {
/// ...
- let private_content =
- UintPartialNotePrivateContent { owner: self.owner, randomness: self.randomness };
- let partial_note = PartialUintNote {
- commitment: private_content.compute_partial_commitment(storage_slot),
- };
+ let private_content =
+ UintPartialNotePrivateContent { owner: self.owner };
+ let partial_note = PartialUintNote {
+ commitment: private_content.compute_partial_commitment(storage_slot, randomness),
+ };
It's worth noting that this change also affects how partial notes are structured and handled.
pub fn partial(
owner: AztecAddress,
storage_slot: Field,
randomness: Field,
context: &mut PrivateContext,
recipient: AztecAddress,
completer: AztecAddress,
) -> PartialUintNote {
- let commitment = UintPartialNotePrivateContent { owner, randomness }
- .compute_partial_commitment(storage_slot);
+ let commitment = UintPartialNotePrivateContent { owner }
+ .compute_partial_commitment(storage_slot, randomness);
let private_log_content =
- UintPartialNotePrivateLogContent { owner, randomness, public_log_tag: commitment };
+ UintPartialNotePrivateLogContent { owner, public_log_tag: commitment };
let encrypted_log = note::compute_partial_note_private_content_log(
private_log_content,
storage_slot,
+ randomness,
recipient,
);
/// ...
}
struct UintPartialNotePrivateContent {
owner: AztecAddress,
- randomness: Field,
}
impl UintPartialNotePrivateContent {
- fn compute_partial_commitment(self, storage_slot: Field) -> Field {
+ fn compute_partial_commitment(self, storage_slot: Field, randomness: Field) -> Field {
poseidon2_hash_with_separator(
- self.pack().concat([storage_slot]),
+ self.pack().concat([storage_slot, randomness]),
DOM_SEP__NOTE_HASH,
)
}
}
struct UintPartialNotePrivateLogContent {
public_log_tag: Field,
owner: AztecAddress,
- randomness: Field,
}
Note size
As a result of this change, the maximum packed length of the content of a note is 11 fields, down from 12. This is a direct consequence of moving the randomness field from the note content structure to the note's metadata.
HintedNote now includes randomness field
pub struct HintedNote<Note> {
pub note: Note,
pub contract_address: AztecAddress,
+ pub randomness: Field,
pub metadata: NoteMetadata,
}
[L1 Contracts] Block is now Checkpoint
A checkpoint is now the primary unit handled by the L1 contracts.
A checkpoint may contain one or more L2 blocks. The protocol circuits already support producing multiple blocks per checkpoint. Updating the L1 contracts to operate on checkpoints allow L2 blockchain to advance faster.
Below are the API and event renames reflecting this change:
- event L2BlockProposed
+ event CheckpointProposed
- event BlockInvalidated
+ event CheckpointInvalidated
- function getEpochForBlock(uint256 _blockNumber) external view returns (Epoch);
+ function getEpochForCheckpoint(uint256 _checkpointNumber) external view returns (Epoch);
- function getProvenBlockNumber() external view returns (uint256);
+ function getProvenCheckpointNumber() external view returns (uint256);
- function getPendingBlockNumber() external view returns (uint256);
+ function getPendingCheckpointNumber() external view returns (uint256);
- function getBlock(uint256 _blockNumber) external view returns (BlockLog memory);
+ function getCheckpoint(uint256 _checkpointNumber) external view returns (CheckpointLog memory);
- function getBlockReward() external view returns (uint256);
+ function getCheckpointReward() external view returns (uint256);
Additionally, any function or struct that previously referenced an L2 block number now uses a checkpoint number instead:
- function status(uint256 _blockNumber) external view returns (
+ function status(uint256 _checkpointNumber) external view returns (
- uint256 provenBlockNumber,
+ uint256 provenCheckpointNumber,
bytes32 provenArchive,
- uint256 pendingBlockNumber,
+ uint256 pendingCheckpointNumber,
bytes32 pendingArchive,
bytes32 archiveOfMyBlock,
Epoch provenEpochNumber
);
Note: current node softwares still produce exactly one L2 block per checkpoint, so for now checkpoint numbers and L2 block numbers remain equal. This may change once multi-block checkpoints are enabled.
[L1 Contracts] L2-to-L1 messages are now grouped by epoch.
L2-to-L1 messages are now aggregated and organized per epoch rather than per block. This change affects how you compute membership witnesses for consuming messages on L1. You now need to know the epoch number in which the message was emitted to retrieve and consume the message.
Note: This is only an API change. The protocol behavior remains the same - messages can still only be consumed once an epoch is proven as before.
What changed
Previously, you might have computed the membership witness without explicitly needing the epoch:
const witness = await computeL2ToL1MembershipWitness(
node,
l2TxReceipt.blockNumber,
l2ToL1Message,
);
Now, you should provide the epoch number:
const epoch = await rollup.getEpochNumberForCheckpoint(
CheckpointNumber.fromBlockNumber(l2TxReceipt.blockNumber),
);
const witness = await computeL2ToL1MembershipWitness(
node,
epoch,
l2ToL1Message,
);
[Aztec.js] Wallet interface changes
simulateTx is now batchable
The simulateTx method on the Wallet interface is now batchable, meaning it can be called as part of a batch operation using wallet.batch(). This allows you to batch simulations together with other wallet operations like registerContract, sendTx, and registerSender.
- // Could not batch simulations
- const simulationResult = await wallet.simulateTx(executionPayload, options);
+ // Can now batch simulations with other operations
+ const results = await wallet.batch([
+ { name: 'registerContract', args: [instance, artifact] },
+ { name: 'simulateTx', args: [executionPayload, options] },
+ { name: 'sendTx', args: [anotherPayload, sendOptions] },
+ ]);
ExecutionPayload moved to @aztec/stdlib/tx
The ExecutionPayload type has been moved from @aztec/aztec.js to @aztec/stdlib/tx. Update your imports accordingly.
- import { ExecutionPayload } from '@aztec/aztec.js';
+ import { ExecutionPayload } from '@aztec/stdlib/tx';
+ // Or import from the re-export in aztec.js/tx:
+ import { ExecutionPayload } from '@aztec/aztec.js/tx';
ExecutionPayload now includes feePayer property
The ExecutionPayload class now includes an optional feePayer property that specifies which address is paying for the fee in the execution payload (if any)
const payload = new ExecutionPayload(
calls,
authWitnesses,
capsules,
extraHashedArgs,
+ feePayer // optional AztecAddress
);
This was previously provided as part of the SendOptions (and others) in the wallet interface, which could cause problems if a payload was assembled with a payment method and the parameter was later omitted. This means SendOptions now loses embeddedPaymentMethodFeePayer
-wallet.simulateTx(executionPayload, { from: address, embeddedFeePaymentMethodFeePayer: feePayer });
+wallet.simulateTx(executionPayload, { from: address });
simulateUtility signature and return type changed
The simulateUtility method signature has changed to accept a FunctionCall object instead of separate functionName, args, and to parameters. Additionally, the return type has changed from AbiDecoded to Fr[].
- const result: AbiDecoded = await wallet.simulateUtility(functionName, args, to, authWitnesses);
+ const result: UtilitySimulationResult = await wallet.simulateUtility(functionCall, authWitnesses?);
+ // result.result is now Fr[] instead of AbiDecoded
The new signature takes:
functionCall: AFunctionCallobject containingname,args,to,selector,type,isStatic,hideMsgSender, andreturnTypesauthWitnesses(optional): An array ofAuthWitnessobjects
The first argument is exactly the same as what goes into ExecutionPayload.calls. As such, the data is already encoded. The return value is now UtilitySimulationResult with result: Fr[] instead of returning an AbiDecoded value directly. You'll need to decode the Fr[] array yourself if you need typed results.
Contract.at() is now synchronous and no longer calls registerContract
The Contract.at() method (and generated contract .at() methods) is now synchronous and no longer automatically registers the contract with the wallet. This reduces unnecessary artifact storage and RPC calls.
- const contract = await TokenContract.at(address, wallet);
+ const contract = TokenContract.at(address, wallet);
Important: You now need to explicitly call registerContract if you want the wallet to store the contract instance and artifact. This is only necessary when:
- An app first registers a contract
- An app tries to update a contract's artifact
If you need to register the contract, do so explicitly:
// Get the instance from deployment
const { contract, instance } = await TokenContract.deploy(wallet, ...args)
.send({ from: address })
.wait();
// wallet already has it registered, since the deploy method does it by default
// to avoid it, set skipContractRegistration: true in the send options.
// Register it with another wallet
await otherWallet.registerContract(instance, TokenContract.artifact);
// Now you can use the contract
const otherContract = TokenContract.at(instance.address, otherWallet);
Publicly deployed contract instances can be retrieved via node.getContract(address). Otherwise and if deployment parameters are known, an instance can be computed via the getContractInstanceFromInstantiationParams from @aztec/aztec.js/contracts
registerContract signature simplified
The registerContract method now takes a ContractInstanceWithAddress instead of a Contract object, and the artifact parameter is now optional. If the artifact is not provided, the wallet will attempt to look it up from its contract class storage.
- await wallet.registerContract(contract);
+ await wallet.registerContract(instance, artifact?);
The method now only accepts:
instance: AContractInstanceWithAddressobjectartifact(optional): AContractArtifactobjectsecretKey(optional): A secret key for privacy keys registration
Return value of getNotes no longer contains a recipient and it contains some other additional info
Return value of getNotes used to be defined as Promise<UniqueNote[]> and is now defined as Promise<NoteDao[]>.
NoteDao is mostly a super-set of UniqueNote but it doesn't contain a recipient.
Having the recipient in the return value has been redundant as the same outcome can be achieved by populating the scopes array in NoteFilter with the recipient value.
Changes to getPrivateEvents
The signature of getPrivateEvents has changed for two reasons:
- To align it with how other query methods that include filtering by block range work (for example,
AztecNode#getPublicLogs) - To enrich the returned private events with metadata.
getPrivateEvents<T>(
- contractAddress: AztecAddress,
- eventMetadata: EventMetadataDefinition,
- from: number,
- numBlocks: number,
- recipients: AztecAddress[],
- ): Promise<T[]>;
+ eventFilter: PrivateEventFilter,
+ ): Promise<PrivateEvent<T>[]>;
PrivateEvent<T> bundles together an ABI decoded event of type T, with metadata of type InTx:
export type InBlock = {
l2BlockNumber: BlockNumber;
l2BlockHash: L2BlockHash;
};
export type InTx = InBlock & {
txHash: TxHash;
};
export type PrivateEvent<T> = {
event: T;
metadata: InTx;
};
You will need to update any calls to Wallet#getPrivateEvents accordingly. See below for before/after comparison which conserves
semantics.
Pay special attention to the fact that the old method expects a numBlocks parameter that instructs it to
return numBlocks blocks after fromBlock, whereas the new version expects an (exclusive) toBlock block number.
Also note we're replacing recipient terminology with scope. While underlying data types are equivalent (they are Aztec addresses), they have different semantics. Messages have a recipient who will be able to receive and process them. As a result of processing messages for a given recipient address, PXE might discover events. Those events are then said to be in scope for that address.
- const events = await context.client.getPrivateEvents(contractAddress, eventMetadata, 42, 10, [recipient]);
- doSomethingWithAnEvent(events[0]);
+ const events = await context.client.getPrivateEvents(eventMetadata, {
+ contractAddress,
+ fromBlock: BlockNumber(42),
+ toBlock: BlockNumber(42 + 10),
+ scopes: [scope],
+ });
+ doSomethingWithAnEvent(events[0].event);
Please refer to the wallet interface js-docs for further details.
[CLI] Command refactor
The sandbox command has been renamed and remapped to "local network". We believe this conveys better what is actually being spun up when running it.
REMOVED/RENAMED:
aztec start --sandbox: nowaztec start --local-network
[Aztec.nr] - Contract API redesign
In this release we decided to largely redesign our contract API. Most of the changes here are not a breaking change
(only renaming of original #[internal] to #[only_self] and storage now being available on the newly introduced
self struct are a breaking change).
1. Renaming of original #[internal] as #[only_self]
We want for internal to mean the same as in Solidity where internal function can be called only from the same contract
and is also inlined (EVM JUMP opcode and not EVM CALL). The original implementation of our #[internal] macro also
results in the function being callable only from the same contract but it results in a different call (hence it doesn't
map to EVM JUMP). This is very confusing for people that know Solidity hence we are doing the rename. A true
#[internal] will be introduced in the future.
To migrate your contracts simply rename all the occurrences of #[internal] with #[only_self] and update the imports:
- use aztec::macros::functions::internal;
+ use aztec::macros::functions::only_self;
#[external("public")]
- #[internal]
+ #[only_self]
fn _deduct_public_balance(owner: AztecAddress, amount: u64) {
...
}
2. Introducing of new #[internal]
Same as in Solidity internal functions are functions that are callable from inside the contract. Unlike #[only_self] functions, internal functions are inlined (e.g. akin to EVM's JUMP and not EVM's CALL).
Internal function can be called using the following API which leverages the new self struct (see change 3 below for
details):
self.internal.my_internal_function(...)
Private internal functions can only be called from other private external or internal functions. Public internal functions can only be called from other public external or internal functions.
3. Introducing self in contracts and a new call interface
Aztec contracts now automatically inject a self parameter into every contract function, providing a unified interface
for accessing the contract's address, storage, calling of function and an execution context.
What is self?
self is an instance of ContractSelf<Context, Storage> that provides:
self.address- The contract's own addressself.storage- Access to your contract's storageself.context- The execution context (private, public, or utility)self.msg_sender()- Get the address of the callerself.emit(...)- Emit eventsself.call(...)- Call an external functionself.view(...)- Call an external function staticallyself.enqueue(...)- Enqueue a call to an external functionself.enqueue_view(...)- Enqueue a call to an external functionself.enqueue_incognito(...)- Enqueue a call to an external function but hides themsg_senderself.enqueue_view_incognito(...)- Enqueue a static call to an external function but hides themsg_senderself.set_as_teardown(...)- Enqueue a call to an external public function and sets the call as teardownself.set_as_teardown_incognito(...)- Enqueue a call to an external public function and sets the call as teardown and hides themsg_senderself.internal.my_internal_fn(...)- Call an internal function
self also provides you with convenience API to call and enqueue calls to external functions from within the same
contract (this is just a convenience API as self.call(MyContract::at(self.address).my_external_fn(...)) would also
work):
self.call_self.my_external_fn(...)- Call external function from within the same contractself.enqueue_self.my_public_external_fn(...)self.call_self_static.my_static_external_fn(...)self.enqueue_self_static.my_static_external_public_fn(...)
How it works
The #[external(...)] macro automatically injects self into your function. When you write:
#[external("private")]
fn transfer(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
self.storage.balances.at(sender).sub(amount);
self.storage.balances.at(recipient).add(amount);
}
The macro transforms it to initialize self with the context and storage before your code executes.
Migration guide
Before: Access context and storage as separate parameters
#[external("private")]
fn old_transfer(amount: u128, recipient: AztecAddress) {
let storage = Storage::init(context);
let sender = context.msg_sender().unwrap();
storage.balances.at(sender).sub(amount);
}
After: Use self to access everything
#[external("private")]
fn new_transfer(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
self.storage.balances.at(sender).sub(amount);
}
Key changes
- Storage and context access:
Storage and context are no longer injected into the function as standalone variables and instead you need to access them via self:
- let balance = storage.balances.at(owner).read();
+ let balance = self.storage.balances.at(owner).read();
- context.push_nullifier(nullifier);
+ self.context.push_nullifier(nullifier);
Note that context is expected to be use only when needing to access a low-level API (like directly emitting a nullifier).
-
Getting caller address: Use
self.msg_sender()instead ofcontext.msg_sender()- let caller = context.msg_sender().unwrap();
+ let caller = self.msg_sender().unwrap(); -
Getting contract address: Use
self.addressinstead ofcontext.this_address()- let this_contract = context.this_address();
+ let this_contract = self.address; -
Emitting events:
In private functions:
- emit_event_in_private(event, context, recipient, delivery_mode);
+ self.emit(event, recipient, delivery_mode);In public functions:
- emit_event_in_public(event, context);
+ self.emit(event); -
Calling functions:
In private functions:
- Token::at(stable_coin).mint_to_public(to, amount).call(&mut context);
+ self.call(Token::at(stable_coin).mint_to_public(to, amount));
Example: Full contract migration
Before:
#[external("private")]
fn withdraw(amount: u128, recipient: AztecAddress) {
let storage = Storage::init(context);
let sender = context.msg_sender().unwrap();
let token = storage.donation_token.get_note().get_address();
// ... withdrawal logic
emit_event_in_private(Withdraw { withdrawer, amount }, context, withdrawer, MessageDelivery.UNCONSTRAINED_ONCHAIN);
}
After:
#[external("private")]
fn withdraw(amount: u128, recipient: AztecAddress) {
let sender = self.msg_sender().unwrap();
let token = self.storage.donation_token.get_note().get_address();
// ... withdrawal logic
self.emit(Withdraw { withdrawer, amount }, withdrawer, MessageDelivery.UNCONSTRAINED_ONCHAIN);
}
No-longer allowing calling of non-view function statically via the old higher-level API
We used to allow calling of non-view function statically as follows:
MyContract::at(address).my_non_view_function(...).view(context);
MyContract::at(address).my_non_view_function(...).enqueue_view(context);
This is no-longer allowed and if you will want to call a function statically you will need to mark the function with
#[view].
Phase checks
Now private external functions check by default that no phase change from non revertible to revertible happens during the execution of the function or any of its nested calls. If you're developing a function
that handles phase change (you call context.end_setup() or call a function that you expect will change phase) you need to opt out of the phase check using the #[nophasecheck] macro. Also, now it's possible to know if you're in the revertible phase of the transaction at any point using self.context.in_revertible_phase().
[aztec command] Moving functionality of aztec-nargo to aztec command
aztec-nargo has been deprecated and all workflows should now migrate to the aztec command that fully replaces aztec-nargo:
-
For contract initialization:
aztec init(Behaves like
nargo init, but defaults to a contract project.) -
For testing:
aztec test(Starts the Aztec TXE and runs your tests.)
-
For compiling contracts:
aztec compile(Transpiles your contracts and generates verification keys.)
3.0.0-devnet.4
[aztec.js] Removal of barrel export
aztec.js is now divided into granular exports, which improves loading performance in node.js and also makes the job of web bundlers easier:
-import { AztecAddress, Fr, getContractInstanceFromInstantiationParams, type Wallet } from '@aztec/aztec.js';
+import { AztecAddress } from '@aztec/aztec.js/addresses';
+import { getContractInstanceFromInstantiationParams } from '@aztec/aztec.js/contracts';
+import { Fr } from '@aztec/aztec.js/fields';
+import type { Wallet } from '@aztec/aztec.js/wallet';
Additionally, some general utilities reexported from foundation have been removed:
-export { toBigIntBE } from '@aztec/foundation/bigint-buffer';
-export { sha256, Grumpkin, Schnorr } from '@aztec/foundation/crypto';
-export { makeFetch } from '@aztec/foundation/json-rpc/client';
-export { retry, retryUntil } from '@aztec/foundation/retry';
-export { to2Fields, toBigInt } from '@aztec/foundation/serialize';
-export { sleep } from '@aztec/foundation/sleep';
-export { elapsed } from '@aztec/foundation/timer';
-export { type FieldsOf } from '@aztec/foundation/types';
-export { fileURLToPath } from '@aztec/foundation/url';
getSenders renamed to getAddressBook in wallet interface
An app could request "contacts" from the wallet, which don't necessarily have to be senders in the wallet's PXE. This method has been renamed to reflect that fact:
-wallet.getSenders();
+wallet.getAddressBook();
Removal of proveTx from Wallet interface
Exposing this method on the interface opened the door for certain types of attacks, were an app could route proven transactions through malicious nodes (that stored them for later decryption, or collected user IPs for example). It also made transactions difficult to track for the wallet, since they could be sent without their knowledge at any time. This change also affects ContractFunctionInteraction and DeployMethod, which no longer expose a prove() method.
msg_sender is now an Option<AztecAddress> type.
Because Aztec has native account abstraction, the very first function call of a tx has no msg_sender. (Recall, the first function call of an Aztec transaction is always a private function call).
Previously (before this change) we'd been silently setting this first msg_sender to be AztecAddress::from_field(-1);, and enforcing this value in the protocol's kernel circuits. Now we're passing explicitness to smart contract developers by wrapping msg_sender in an Option type. We'll explain the syntax shortly.
We've also added a new protocol feature. Previously (before this change) whenever a public function call was enqueued by a private function (a so-called private->public call), the called public function (and hence the whole world) would be able to see msg_sender. For some use cases, visibility of msg_sender is important, to ensure the caller executed certain checks in private-land. For #[only_self] public functions, visibility of msg_sender is unavoidable (the caller of an #[only_self] function must be the same contract address by definition). But for some use cases, a visible msg_sender is an unnecessary privacy leakage.
We therefore have added a feature where msg_sender can be optionally set to Option<AztecAddress>::none() for enqueued public function calls (aka private->public calls). We've been colloquially referring to this as "setting msg_sender to null".
Aztec.nr diffs
Note: we'll be doing another pass at this aztec.nr syntax in the near future.
Given the above, the syntax for accessing msg_sender in Aztec.nr is slightly different:
For most public and private functions, to adjust to this change, you can make this change to your code:
- let sender: AztecAddress = context.msg_sender();
+ let sender: AztecAddress = context.msg_sender().unwrap();
Recall that Option::unwrap() will throw if the Option is "none".
Indeed, most smart contract functions will require access to a proper contract address (instead of a "null" value), in order to do bookkeeping (allocation of state variables against user addresses), and so in such cases throwing is sensible behaviour.
If you want to output a useful error message when unwrapping fails, you can use Option::expect:
- let sender: AztecAddress = context.msg_sender();
+ let sender: AztecAddress = context.msg_sender().expect(f"Sender must not be none!");
For a minority of functions, a "null" msg_sender will be acceptable:
- A private entrypoint function.
- A public function which doesn't seek to do bookkeeping against
msg_sender.
Some apps might even want to assert that the msg_sender is "null" to force their users into strong privacy practices:
let sender: Option<AztecAddress> = context.msg_sender();
assert(sender.is_none());
Enqueueing public function calls
Auto-generated contract interfaces
When you use the #[aztec] macro, it will generate a noir contract interface for your contract, behind the scenes.
This provides pretty syntax when you come to call functions of that contract. E.g.:
Token::at(context.this_address())._increase_public_balance(to, amount).enqueue(&mut context);
In keeping with this new feature of being able to enqueue public function calls with a hidden msg_sender, there are some new methods that can be chained instead of .enqueue(...):
enqueue_incognito-- akin toenqueue, butmsg_senderis set "null".enqueue_view_incognito-- akin toenqueue_view, butmsg_senderis "null".set_as_teardown_incognito-- akin toset_as_teardown, butmsg_senderis "null".
The name "incognito" has been chosen to imply "msg_sender will not be visible to observers".
These new functions enable the calling contract to specify that it wants its address to not be visible to the called public function. This is worth re-iterating: it is the caller's choice. A smart contract developer who uses these functions must be sure that the target public function will accept a "null" msg_sender. It would not be good (for example) if the called public function did context.msg_sender().unwrap(), because then a public function that is called via enqueue_incognito would always fail! Hopefully smart contract developers will write sufficient tests to catch such problems during development!
Making lower-level public function calls from the private context
This is discouraged vs using the auto-generated contract interfaces described directly above.
If you do use any of these low-level methods of the PrivateContext in your contract:
call_public_functionstatic_call_public_functioncall_public_function_no_argsstatic_call_public_function_no_argscall_public_function_with_calldata_hashset_public_teardown_functionset_public_teardown_function_with_calldata_hash
... there is a new hide_msg_sender: bool parameter that you will need to specify.