Skip to main content

Aztec Sandbox Errors

This section contains a list of errors you may encounter when using Aztec Sandbox and an explanation of each of them.

Circuit Errors

To prevent bloating this doc, here is a list of some of the common errors.

Kernel Circuits

We have several versions of public and private kernels as explained in our circuits section. Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public.

Remember that for each function call (i.e. each item in the call stack), there is a new kernel iteration that gets run.


Cannot call contract at address(0x0) privately. This error may also happen when you deploy a new contract and the contract data hash is inconsistent to the expected contract address.


For static calls, new commitments aren't allowed


For static calls, new nullifiers aren't allowed


You cannot execute a public function in the private kernel


You are trying to do something that is currently unsupported in the private kernel. If this is a blocker feel free to open up an issue on our monorepo aztec3-packages or reach out to us on discord

Note that certain operations are unsupported on certain versions of the private kernel. Eg static calls are allowed for all but the initial iteration of the private kernel (which initializes the kernel for subsequent function calls).


For the initial iteration of the private kernel, only the expected contract should be the entrypoint. Static and delegate calls are not allowed in the initial iteration.


The previous kernel iteration within the private kernel must also be private


A constructor must be executed as the first tx in the recursion i.e. a constructor call must be the first item in the call stack i.e. it can be executed in the first kernel iteration but not in subsequent ones. This also means you can't have a contract deploy another contract yet on Aztec.


Confirms that the TxRequest (user's intent) matches the private call being executed. This error may happen when:

  • origin address of tx_request doesn't match call_stack_item's contract_address
  • tx_request.function_data doesn't match call_stack_item.function_data
  • function args passed to tx_request doesn't match args in the call_stack_item


Given a read request and provided witness, we check that the merkle root obtained from the witness' sibling path and it's leaf is similar to the historical state root we want to read against. This is a sanity check to ensure we are reading from the right state. For a non transient read, we fetch the merkle root from the membership witnesses and the leaf index


A pending commitment is the one that is not yet added to note hash tree. A transient read is when we try to "read" a pending commitment. This error happens when you try to read a pending commitment that doesn't exist.


For a transient read request we skip merkle membership checks since pending commitments aren't inserted into the note hash tree yet. But for non transient reads, we do a merkle membership check. Reads are done at the kernel circuit. So this checks that there are no already unresolved reads from a previous kernel iteration (other than non transient ones).


You are trying to do something that is currently unsupported in the public kernel. If this is a blocker feel free to open up an issue on our monorepo aztec3-packages or reach out to us on discord


Calling a private function in a public kernel is not allowed.


Public functions are executed after all the private functions are (see private-public execution). As such, private call stack must be empty when executing in the public kernel.


When the hash stored at the top most of the call stack is different to the call stack item expected by the public kernel's inputs.


Similar to above, except here we actually have the preimages to the call stack and hash to ensure they match.


Public kernel doesn't allow contract deployments


Aztec doesn't support public constructors.


Calling address(0x0) publicly is not permitted.


Cannot call a contract with no function (i.e. function signature of 0) publicly.


For static calls, no contract storage change requests are allowed.


Same as 3022, no contract changes are allowed for static calls.


For static calls, no new commitments or nullifiers can be added to the state.


For static calls, no new commitments or nullifiers can be added to the state.

Rollup circuit errors

These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See rollup circuits for more information.


The L1 chain ID you used in your proof generation (for your private transaction) is different to what the rollup circuits expected. Double check against the global variables passed to noir and the config set in Aztec's rollup contract which are read in by sequencer and subsequently passed in as inputs to the base rollup. When the sequencer submits the block to the rollup contracts, this is again sanity checked so ensure this is the same everywhere.


Same as section 4007 except the version refers to the version of the Aztec L2 instance.

Some scary bugs like 4003 - BASE__INVALID_NULLIFIER_SUBTREE and 4004 - BASE__INVALID_NULLIFIER_RANGE which are to do malformed nullifier trees (see Indexed Merkle Trees) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's code. Same is true for certain instances of 7008 - MEMBERSHIP_CHECK_FAILED.

Generic circuit errors


Circuits work by having a fixed size array. As such, we have limits on how many UTXOs can be created (aka "commitments") or destroyed/nullified (aka "nullifiers") in a transaction. Similarly we have limits on many reads or writes you can do, how many contracts you can create in a transaction. This error typically says that you have reached the current limits of what you can do in a transaction. Some examples when you may hit this error are:

  • too many new commitments in one tx
  • too many new nullifiers in one tx
    • Note: Nullifiers may be created even outside the context of your code. Eg, when creating a contract, we add a nullifier for its address to prevent same address from ever occurring. Similarly, we add a nullifier for your transaction hash too.
  • too many private function calls in one tx (i.e. call stack size exceeded)
  • too many public function calls in one tx (i.e. call stack size exceeded)
  • too many new L2 to L1 messages in one tx
  • too many contracts created in one tx
  • too many public data update requests in one tx
  • too many public data reads in one tx
  • too many transient read requests in one tx
  • too many transient read request membership witnesses in one tx

You can have a look at our current constants/limitations in


Users may create a proof against a historical state in Aztec. The rollup circuits performs a merkle membership check to ensure this state existed at some point. If the historical state doesn't exist, you get this error. Some examples when you may hit this error are:

  • using invalid historical note hash tree state (aka historical commitments tree)
  • using invalid historical contracts data tree state
  • using invalid historical L1 to L2 message data tree state
  • inserting a subtree into the greater tree
    • we make a smaller merkle tree of all the new commitments/nullifiers etc that were created in a transaction or in a rollup and add it to the bigger state tree. Before inserting, we do a merkle membership check to ensure that the index to insert at is indeed an empty subtree (otherwise we would be overwriting state). This can happen when next_available_leaf_index in the state tree's snapshot is wrong (it is fetched by the sequencer from the archiver). The error message should reveal which tree is causing this issue
    • nullifier tree related errors - The nullifier tree uses an Indexed Merkle Tree. It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error.

Archiver Errors

  • "L1 to L2 Message with key ${messageKey.toString()} not found in the confirmed messages store" - happens when the L1 to L2 message doesn't exist or is "pending", when the user has sent a message on L1 via the Inbox contract but it has yet to be included in an L2 block by the sequencer - user has to wait for sequencer to pick it up and the archiver to sync the respective L2 block. You can get the sequencer to pick it up by doing an arbitrary transaction on L2 (eg send DAI to yourself). This would give the sequencer a transaction to process and as a side effect it would look for any pending messages it should include.

  • "Unable to remove message: L1 to L2 Message with key ${messageKeyBigInt} not found in store" - happens when trying to confirm a non-existent pending message or cancelling such a message. Perhaps the sequencer has already confirmed the message?

  • "Block number mismatch: expected ${l2BlockNum} but got ${block.number}" - The archiver keeps track of the next expected L2 block number. It throws this error if it got a different one when trying to sync with the rollup contract's events on L1.

Sequencer Errors

  • "Calldata hash mismatch" - the sequencer assembles a block and sends it to the rollup circuits for proof generation. Along with the proof, the circuits return the hash of the calldata that must be sent to the Rollup contract on L1. Before doing so, the sequencer sanity checks that this hash is equivalent to the calldata hash of the block that it submitted. This could be a bug in our code e.g. if we are ordering things differently in circuits and in our transaction/block (e.g. incorrect ordering of encrypted logs or queued public calls). Easiest way to debug this is by printing the calldata of the block both on the TS (in l2Block.getCalldataHash()) and C++ side (in the base rollup)

  • "${treeName} tree root mismatch" - like with calldata mismatch, it validates that the root of the tree matches the output of the circuit simulation. The tree name could be Public data tree, Note Hash Tree, Contract tree, Nullifier tree or the L1ToL2Message tree,

  • "${treeName} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the next_available_leaf_index is as expected. This is the next index we can insert new values into. Note that for the public data tree, this test is skipped since as it is a sparse tree unlike the others.

  • "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see private-public execution). This error says there are too many public functions requested.

  • "Array size exceeds target length" - happens if you add more items than allowed by the constants set due to our circuit limitations (eg sending too many L2 to L1 messages or creating a function that exceeds the call stack length or returns more values than what functions allow)

  • "Failed to publish block" - Happens when sequencer tries to submit its L2 block + proof to the rollup contract. Use the CLI to find any solidity error and then refer the Contract errors section.

L1 Aztec Contract Errors

Aztec's L1 contracts use custom errors in solidity. While it saves gas, it has a side effect of making it harder to decode when things go wrong. If you get an error when submitting an L2Block into our rollup contract or when interacting with our Inbox/Outbox contracts, you can use the Errors.sol library to match the hex encoded error to the error name.