Struct PrivateContext

Returns the contract address that initiated this function call.

This is similar to msg.sender in Solidity (hence the name).

Important Note: Since Aztec doesn't have a concept of an EoA ( Externally-owned Account), the msg_sender is "null" for the first function call of every transaction. The first function call of a tx is likely to be a call to the user's account contract, so this quirk will most often be handled by account contract developers.

Returns

• Option<AztecAddress> - The address of the smart contract that called this function (be it an app contract or a user's account contract). Returns Option<AztecAddress>::none for the first function call of the tx. No other private function calls in the tx will have a none msg_sender, but public function calls might (see the PublicContext).

"Unsafe" versus calling context.msg_sender(), because it doesn't translate NULL_MSG_SENDER_CONTRACT_ADDRESS as Option<AztecAddress>::none. Used by some internal aztecnr functions.

Returns the contract address of the current function being executed.

This is equivalent to address(this) in Solidity (hence the name). Use this to identify the current contract's address, commonly needed for access control or when interacting with other contracts.

Returns

• AztecAddress - The contract address of the current function being executed.

Returns the chain ID of the current network.

This is similar to block.chainid in Solidity. Returns the unique identifier for the blockchain network this transaction is executing on.

Helps prevent cross-chain replay attacks. Useful if implementing multi-chain contract logic.

Returns

• Field - The chain ID as a field element

Returns the Aztec protocol version that this transaction is executing under. Different versions may have different rules, opcodes, or cryptographic primitives.

This is similar to how Ethereum has different EVM versions.

Useful for forward/backward compatibility checks

Not to be confused with contract versions; this is the protocol version.

Returns

• Field - The protocol version as a field element

Returns the gas settings for the current transaction.

This provides information about gas limits and pricing for the transaction, similar to tx.gasprice and gas limits in Ethereum. However, Aztec has a more sophisticated gas model with separate accounting for L2 computation and data availability (DA) costs.

Returns

• GasSettings - Struct containing gas limits and fee information

Returns the function selector of the currently executing function.

Low-level function: Ordinarily, smart contract developers will not need to access this.

This is similar to msg.sig in Solidity, which returns the first 4 bytes of the function signature. In Aztec, the selector uniquely identifies which function within the contract is being called.

Returns

• FunctionSelector - The 4-byte function identifier

Advanced

Only #[external("private")] functions have a function selector as a protocol- enshrined concept. The function selectors of private functions are baked into the preimage of the contract address, and are used by the protocol's kernel circuits to identify each private function and ensure the correct one is being executed.

Used internally for function dispatch and call verification.

Returns the hash of the arguments passed to the current function.

Very low-level function: You shouldn't need to call this. The #[external("private")] macro calls this, and it makes the arguments neatly available to the body of your private function.

Returns

• Field - Hash of the function arguments

Advanced

• Arguments are hashed to reduce proof size and verification time
• Enables efficient argument passing in recursive function calls
• The hash can be used to retrieve the original arguments from the PXE.

Pushes a new note_hash to the Aztec blockchain's global Note Hash Tree (a state tree).

A note_hash is a commitment to a piece of private state.

Low-level function: Ordinarily, smart contract developers will not need to manually call this. Aztec-nr's state variables (see ../state_vars/) are designed to understand when to create and push new note hashes.

Arguments

• note_hash - The new note_hash.

Advanced

From here, the protocol's kernel circuits will take over and insert the note_hash into the protocol's "note hash tree" (in the Base Rollup circuit). Before insertion, the protocol will:

• "Silo" the note_hash with the contract address of this function, to yield a siloed_note_hash. This prevents state collisions between different smart contracts.
• Ensure uniqueness of the siloed_note_hash, to prevent Faerie-Gold attacks, by hashing the siloed_note_hash with a unique value, to yield a unique_siloed_note_hash (see the protocol spec for more).

In addition to calling this function, aztec-nr provides the contents of the newly-created note to the PXE, via the notify_created_note oracle.

Advanced users might occasionally wish to push data to the context directly for lower-level control. If you find yourself doing this, please open an issue on GitHub to describe your use case: it might be that new functionality should be added to aztec-nr.

Pushes a new nullifier to the Aztec blockchain's global Nullifier Tree (a state tree).

See also: push_nullifier_for_note_hash.

Low-level function: Ordinarily, smart contract developers will not need to manually call this. Aztec-nr's state variables (see ../state_vars/) are designed to understand when to create and push new nullifiers.

A nullifier can only be emitted once. Duplicate nullifier insertions are rejected by the protocol.

Generally, a nullifier is emitted to prevent an action from happening more than once, in such a way that the action cannot be linked (by an observer of the blockchain) to any earlier transactions.

I.e. a nullifier is a random-looking, but deterministic record of a private, one-time action, which does not leak what action has been taken, and which preserves the property of "tx unlinkability".

Usually, a nullifier will be emitted to "spend" a note (a piece of private state), without revealing which specific note is being spent.

(Important: in such cases, use the below push_nullifier_for_note_hash).

Sometimes, a nullifier might be emitted completely unrelated to any notes. Examples include initialization of a new contract; initialization of a PrivateMutable, or signalling in Semaphore-like applications. This push_nullifier function serves such use cases.

Arguments

• nullifier

Advanced

From here, the protocol's kernel circuits will take over and insert the nullifier into the protocol's "nullifier tree" (in the Base Rollup circuit). Before insertion, the protocol will:

• "Silo" the nullifier with the contract address of this function, to yield a siloed_nullifier. This prevents state collisions between different smart contracts.
• Ensure the siloed_nullifier is unique (the nullifier tree is an indexed merkle tree which supports efficient non-membership proofs).

Pushes a nullifier that corresponds to a specific note hash.

Low-level function: Ordinarily, smart contract developers will not need to manually call this. Aztec-nr's state variables (see ../state_vars/) are designed to understand when to create and push new nullifiers.

This is a specialized version of push_nullifier that links a nullifier to the specific note hash it's nullifying. This is the most common usage pattern for nullifiers. See push_nullifier for more explanation on nullifiers.

Arguments

• nullifier
• nullified_note_hash - The note hash of the note being nullified

Advanced

Important: usage of this function doesn't mean that the world will see that this nullifier relates to the given nullified_note_hash (as that would violate "tx unlinkability"); it simply informs the user's PXE about the relationship (via notify_nullified_note). The PXE can then use this information to feed hints to the kernel circuits for "squashing" purposes: If a note is nullified during the same tx which created it, we can "squash" (delete) the note and nullifier (and any private logs associated with the note), to save on data emission costs.

Returns the anchor block header - the historical block header that this private function is reading from.

A private function CANNOT read from the "current" block header, but must read from some older block header, because as soon as private function execution begins (asynchronously, on a user's device), the public state of the chain (the "current state") will have progressed forward.

Returns

• BlockHeader - The anchor block header.

Advanced

• All private functions of a tx read from the same anchor block header.
• The protocol asserts that the include_by_timestamp of every tx is at most 24 hours beyond the timestamp of the tx's chosen anchor block header. This enables the network's nodes to safely prune old txs from the mempool. Therefore, the chosen block header must be one from within the last 24 hours.

Returns the header of any historical block at or before the anchor block.

This enables private contracts to access information from even older blocks than the anchor block header.

Useful for time-based contract logic that needs to compare against multiple historical points.

Arguments

• block_number - The block number to retrieve (must be <= anchor block number)

Returns

• BlockHeader - The header of the requested historical block

Advanced

This function uses an oracle to fetch block header data from the user's PXE. Depending on how much blockchain data the user's PXE has been set up to store, this might require a query from the PXE to another Aztec node to get the data.

This is generally true of all oracle getters (see ../oracle).

Each block header gets hashed and stored as a leaf in the protocol's Archive Tree. In fact, the i-th block header gets stored at the i-th leaf index of the Archive Tree. Behind the scenes, this get_block_header_at function will add Archive Tree merkle-membership constraints (~3k) to your smart contract function's circuit, to prove existence of the block header in the Archive Tree.

Note: we don't do any caching, so avoid making duplicate calls for the same block header, because each call will add duplicate constraints.

Calling this function is more expensive (constraint-wise) than getting the anchor block header (via get_block_header). This is because the anchor block's merkle membership proof is handled by Aztec's protocol circuits, and is only performed once for the entire tx because all private functions of a tx share a common anchor block header. Therefore, the cost (constraint-wise) of calling get_block_header is effectively free.

Sets the hash of the return values for this private function.

Very low-level function: this is called by the #[external("private")] macro.

Arguments

• serialized_return_values - The serialized return values as a field array

Builds the PrivateCircuitPublicInputs for this private function, to ensure compatibility with the protocol's kernel circuits.

Very low-level function: This function is automatically called by the #[external("private")] macro.

Designates this contract as the fee payer for the transaction.

Unlike Ethereum, where the transaction sender always pays fees, Aztec allows any contract to voluntarily pay transaction fees. This enables patterns like sponsored transactions or fee abstraction where users don't need to hold fee-juice themselves. (Fee juice is a fee-paying asset for Aztec).

Only one contract per transaction can declare itself as the fee payer, and it must have sufficient fee-juice balance (>= the gas limits specified in the TxContext) by the time we reach the public setup phase of the tx.

Declares the end of the "setup phase" of this tx.

Only one function per tx can declare the end of the setup phase.

Niche function: Only wallet developers and paymaster contract developers (aka Fee-payment contracts) will need to make use of this function.

Aztec supports a three-phase execution model: setup, app logic, teardown. The phases exist to enable a fee payer to take on the risk of paying a transaction fee, safe in the knowledge that their payment (in whatever token or method the user chooses) will succeed, regardless of whether the app logic will succeed. The "setup" phase enables such a payment to be made, because the setup phase cannot revert: a reverting function within the setup phase would result in an invalid block which cannot be proven. Any side-effects generated during that phase are guaranteed to be inserted into Aztec's state trees (except for squashed notes & nullifiers, of course).

Even though the end of the setup phase is declared within a private function, you might have noticed that public functions can also execute within the setup phase. This is because any public function calls which were enqueued within the setup phase by a private function are considered part of the setup phase.

Advanced

• Sets the minimum revertible side effect counter of this tx to be the PrivateContext's current side effect counter.

Sets a deadline (an "include-by timestamp") for when this transaction must be included in a block.

Other functions in this tx might call this setter with differing values for the include-by timestamp. To ensure that all functions' deadlines are met, the minimum of all these include-by timestamps will be exposed when this tx is submitted to the network.

If the transaction is not included in a block by its include-by timestamp, it becomes invalid and it will never be included.

This expiry timestamp is publicly visible. See the "Advanced" section for privacy concerns.

Arguments

• include_by_timestamp - Unix timestamp (seconds) deadline for inclusion. The include-by timestamp of this tx will be at most the timestamp specified.

Advanced

• If multiple functions set differing include_by_timestamps, the kernel circuits will set it to be the minimum of the two. This ensures the tx expiry requirements of all functions in the tx are met.
• Rollup circuits will reject expired txs.
• The protocol enforces that all transactions must be included within 24 hours of their chosen anchor block's timestamp, to enable safe mempool pruning.
• The DelayedPublicMutable design makes heavy use of this functionality, to enable private functions to read public state.
• A sophisticated Wallet should cleverly set an include-by timestamp to improve the privacy of the user and the network as a whole. For example, if a contract interaction sets include-by to some publicly-known value (e.g. the time when a contract upgrades), then the wallet might wish to set an even lower one to avoid revealing that this tx is interacting with said contract. Ideally, all wallets should standardize on an approach in order to provide users with a large anonymity set -- although the exact approach will need to be discussed. Wallets that deviate from a standard might accidentally reveal which wallet each transaction originates from.

Makes a request to the protocol's kernel circuit to ensure a note_hash actually exists.

"Read requests" are used to prove that a note hash exists without revealing which specific note was read.

This can be used to prove existence of both settled notes (created in prior transactions) and transient notes (created in the current transaction). If you need to prove existence of a settled note at a specific block number, use note_inclusion::prove_note_inclusion.

Low-level function. Ordinarily, smart contract developers will not need to call this directly. Aztec-nr's state variables (see ../state_vars/) are designed to understand when to create and push new note_hash read requests.

Arguments

• note_hash_read - The note hash to read and verify

Advanced

In "traditional" circuits for non-Aztec privacy applications, the merkle membership proofs to check existence of a note are performed within the application circuit.

All Aztec private functions have access to the following constraint optimisation: In cases where the note being read was created earlier in the same tx, the note wouldn't yet exist in the Note Hash Tree, so a hard-coded merkle membership check which then gets ignored would be a waste of constraints. Instead, we can send read requests for all notes to the protocol's kernel circuits, where we can conditionally assess which notes actually need merkle membership proofs, and select an appropriately-sized kernel circuit.

For "settled notes" (which already existed in the Note Hash Tree of the anchor block (i.e. before the tx began)), the kernel does a merkle membership check.

For "pending notes" (which were created earlier in this tx), the kernel will check that the note existed before this read request was made, by checking the side-effect counters of the note_hash and this read request.

This approach improves latency between writes and reads: a function can read a note which was created earlier in the tx (rather than performing the read in a later tx, after waiting for the earlier tx to be included, to ensure the note is included in the tree).

Asserts that a NoteHashRead has been requested to the kernel by this context. Asserts instead of returning a boolean to save on gates.

Arguments

• note_hash_read - The note hash read to assert that has been requested.

Requests to read a specific nullifier from the nullifier tree.

Nullifier read requests are used to prove that a nullifier exists without revealing which specific nullifier preimage was read.

This can be used to prove existence of both settled nullifiers (created in prior transactions) and transient nullifiers (created in the current transaction). If you need to prove existence of a settled nullifier at a specific block number, use nullifier_inclusion::prove_nullifier_inclusion.

Low-level function. Ordinarily, smart contract developers will not need to call this directly. Aztec-nr's state variables (see ../state_vars/) are designed to understand when to create and push new nullifier read requests.

Arguments

• nullifier - The nullifier to read and verify
• contract_address - The contract address that emitted the nullifier

Advanced

This approach improves latency between writes and reads: a function can read a nullifier which was created earlier in the tx (rather than performing the read in a later tx, after waiting for the earlier tx to be included, to ensure the nullifier is included in the tree).

Requests the app-siloed nullifier secret key (nsk_app) for the given (hashed) master nullifier public key (npk_m), from the user's PXE.

Advanced function: Only needed if you're designing your own notes and/or nullifiers.

Contracts are not allowed to compute nullifiers for other contracts, as that would let them read parts of their private state. Because of this, a contract is only given an "app-siloed secret key", which is constructed by hashing the user's master nullifier secret key with the contract's address. However, because contracts cannot be trusted with a user's master nullifier secret key (because we don't know which contracts are honest or malicious), the PXE refuses to provide any master secret keys to any app smart contract function. This means app functions are unable to prove that the derivation of an app-siloed nullifier secret key has been computed correctly. Instead, an app function can request to the kernel (via request_nsk_app) that it validates the siloed derivation, since the kernel has been vetted to not leak any master secret keys.

A common nullification scheme is to inject a nullifier secret key into the preimage of a nullifier, to make the nullifier deterministic but random-looking. This function enables that flow.

Arguments

• npk_m_hash - A hash of the master nullifier public key of the user whose PXE is executing this function.

Returns

• The app-siloed nullifier secret key that corresponds to the given npk_m_hash.

Requests the app-siloed nullifier secret key (nsk_app) for the given (hashed) master nullifier public key (npk_m), from the user's PXE.

See request_nsk_app and request_sk_app for more info.

The intention of the "outgoing" keypair is to provide a second secret key for all of a user's outgoing activity (i.e. for notes that a user creates, as opposed to notes that a user receives from others). The separation of incoming and outgoing data was a distinction made by zcash, with the intention of enabling a user to optionally share with a 3rd party a controlled view of only incoming or outgoing notes. Similar functionality of sharing select data can be achieved with offchain zero-knowledge proofs. It is up to an app developer whether they choose to make use of a user's outgoing keypair within their application logic, or instead simply use the same keypair (the address keypair (which is effectively the same as the "incoming" keypair)) for all incoming & outgoing messages to a user.

Currently, all of the exposed encryption functions in aztec-nr ignore the outgoing viewing keys, and instead encrypt all note logs and event logs to a user's address public key.

Arguments

• ovpk_m_hash - Hash of the outgoing viewing public key master

Returns

• The application-specific outgoing viewing secret key

Sends an "L2 -> L1 message" from this function (Aztec, L2) to a smart contract on Ethereum (L1). L1 contracts which are designed to send/receive messages to/from Aztec are called "Portal Contracts".

Common use cases include withdrawals, cross-chain asset transfers, and triggering L1 actions based on L2 state changes.

The message will be inserted into an Aztec "Outbox" contract on L1, when this transaction's block is proposed to L1. Sending the message will not result in any immediate state changes in the target portal contract. The message will need to be manually consumed from the Outbox through a separate Ethereum transaction: a user will need to call a function of the portal contract -- a function specifically designed to make a call to the Outbox to consume the message. The message will only be available for consumption once the epoch proof has been submitted. Given that there are multiple Aztec blocks within an epoch, it might take some time for this epoch proof to be submitted -- especially if the block was near the start of an epoch.

Arguments

• recipient - Ethereum address that will receive the message
• content - Message content (32 bytes as a Field element). This content has a very specific layout. docs:start:context_message_portal

Consumes a message sent from Ethereum (L1) to Aztec (L2).

Common use cases include token bridging, cross-chain governance, and triggering L2 actions based on L1 events.

Use this function if you only want the message to ever be "referred to" once. Once consumed using this method, the message cannot be consumed again, because a nullifier is emitted. If your use case wants for the message to be read unlimited times, then you can always read any historic message from the L1-to-L2 messages tree; messages never technically get deleted from that tree.

The message will first be inserted into an Aztec "Inbox" smart contract on L1. Sending the message will not result in any immediate state changes in the target L2 contract. The message will need to be manually consumed by the target contract through a separate Aztec transaction. The message will not be available for consumption immediately. Messages get copied over from the L1 Inbox to L2 by the next Proposer in batches. So you will need to wait until the messages are copied before you can consume them.

Arguments

• content - The message content that was sent from L1
• secret - Secret value used for message privacy (if needed)
• sender - Ethereum address that sent the message
• leaf_index - Index of the message in the L1-to-L2 message tree

Advanced

Validates message existence in the L1-to-L2 message tree and nullifies the message to prevent double-consumption.

Emits a private log (an array of Fields) that will be published to an Ethereum blob.

Private logs are intended for the broadcasting of ciphertexts: that is, encrypted events or encrypted note contents. Since the data in the logs is meant to be encrypted, private_logs are broadcast to publicly-visible Ethereum blobs. The intended recipients of such encrypted messages can then discover and decrypt these encrypted logs using their viewing secret key. (See ../messages/discovery for more details).

Important note: This function DOES NOT do any encryption of the input log fields. This function blindly publishes whatever input log data is fed into it, so the caller of this function should have already performed the encryption, and the log should be the result of that encryption.

The protocol does not dictate what encryption scheme should be used: a smart contract developer can choose whatever encryption scheme they like. Aztec-nr includes some off-the-shelf encryption libraries that developers might wish to use, for convenience. These libraries not only encrypt a plaintext (to produce a ciphertext); they also prepend the ciphertext with a tag and ephemeral public key for easier message discovery. This is a very dense topic, and we will be writing more libraries and docs soon.

Currently, AES128 CBC encryption is the main scheme included in aztec.nr. We are currently making significant changes to the interfaces of the encryption library.

In some niche use cases, an app might be tempted to publish un-encrypted data via a private log, because public logs are not available to private functions. Be warned that emitting public data via private logs is strongly discouraged, and is considered a "privacy anti-pattern", because it reveals identifiable information about which function has been executed. A tx which leaks such information does not contribute to the privacy set of the network.

• Unlike emit_raw_note_log, this log is not tied to any specific note

Arguments

• log - The log data that will be publicly broadcast (so make sure it's already been encrypted before you call this function). Private logs are bounded in size (PRIVATE_LOG_SIZE_IN_FIELDS), to encourage all logs from all smart contracts look identical.
• length - The actual length of the log (measured in number of Fields). Although the input log has a max size of PRIVATE_LOG_SIZE_IN_FIELDS, the latter values of the array might all be 0's for small logs. This length should reflect the trimmed length of the array. The protocol's kernel circuits can then append random fields as "padding" after the length, so that the logs of this smart contract look indistinguishable from (the same length as) the logs of all other applications. It's up to wallets how much padding to apply, so ideally all wallets should agree on standards for this.

Advanced

Emits a private log that is explicitly tied to a newly-emitted note_hash, to convey to the kernel: "this log relates to this note".

This linkage is important in case the note gets squashed (due to being read later in this same tx), since we can then squash the log as well.

See emit_private_log for more info about private log emission.

Arguments

• log - The log data as an array of Field elements
• length - The actual length of the log (measured in number of Fields).
• note_hash_counter - The side-effect counter that was assigned to the new note_hash when it was pushed to this

Important: If your application logic requires the log to always be emitted regardless of note squashing, consider using emit_private_log instead, or emitting additional events.

Calls a private function on another contract (or the same contract).

Very low-level function.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• args - Array of arguments to pass to the called function

Returns

• ReturnsHash - Hash of the called function's return values. Use .get_preimage() to extract the actual return values.

This enables contracts to interact with each other while maintaining privacy. This "composability" of private contract functions is a key feature of the Aztec network.

If a user's transaction includes multiple private function calls, then by the design of Aztec, the following information will remain private[1]:

• The function selectors and contract addresses of all private function calls will remain private, so an observer of the public mempool will not be able to look at a tx and deduce which private functions have been executed.
• The arguments and return values of all private function calls will remain private.
• The person who initiated the tx will remain private.
• The notes and nullifiers and private logs that are emitted by all private function calls will (if designed well) not leak any user secrets, nor leak which functions have been executed.

[1] Caveats: Some of these privacy guarantees depend on how app developers design their smart contracts. Some actions can leak information, such as:

• Calling an internal public function.
• Calling a public function and not setting msg_sender to Option::none (feature not built yet - see github).
• Calling any public function will always leak details about the nature of the transaction, so devs should be careful in their contract designs. If it can be done in a private function, then that will give the best privacy.
• Not padding the side-effects of a tx to some standardized, uniform size. The kernel circuits can take hints to pad side-effects, so a wallet should be able to request for a particular amount of padding. Wallets should ideally agree on some standard.
  • Padding should include:
    • Padding the lengths of note & nullifier arrays
    • Padding private logs with random fields, up to some standardized size. See also: https://docs.aztec.network/developers/resources/considerations/privacy_considerations

Advanced

• The call is added to the private call stack and executed by kernel circuits after this function completes
• The called function can modify its own contract's private state
• Side effects from the called function are included in this transaction
• The call inherits the current transaction's context and gas limits

Makes a read-only call to a private function on another contract.

This is similar to Solidity's staticcall. The called function cannot modify state, emit L2->L2 messages, nor emit events. Any nested calls are constrained to also be staticcalls.

See call_private_function for more general info on private function calls.

Arguments

• contract_address - Address of the contract to call
• function_selector - 4-byte identifier of the function to call
• args - Array of arguments to pass to the called function

Returns

• ReturnsHash - Hash of the called function's return values. Use .get_preimage() to extract the actual return values.

Calls a private function that takes no arguments.

This is a convenience function for calling private functions that don't require any input parameters. It's equivalent to call_private_function but slightly more efficient to use when no arguments are needed.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call

Returns

• ReturnsHash - Hash of the called function's return values. Use .get_preimage() to extract the actual return values.

Makes a read-only call to a private function which takes no arguments.

This combines the optimisation of call_private_function_no_args with the safety of static_call_private_function.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call

Returns

• ReturnsHash - Hash of the called function's return values. Use .get_preimage() to extract the actual return values.

Low-level private function call.

This is the underlying implementation used by all other private function call methods. Instead of taking raw arguments, it accepts a hash of the arguments.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• args_hash - Pre-computed hash of the function arguments
• is_static_call - Whether this should be a read-only call

Returns

• ReturnsHash - Hash of the called function's return values

Enqueues a call to a public function to be executed later.

Unlike private functions which execute immediately on the user's device, public function calls are "enqueued" and executed some time later by a block proposer.

This means a public function cannot return any values back to a private function, because by the time the public function is being executed, the private function which called it has already completed execution. (In fact, the private function has been executed and proven, along with all other private function calls of the user's tx. A single proof of the tx has been submitted to the Aztec network, and some time later a proposer has picked the tx up from the mempool and begun executing all of the enqueued public functions).

Privacy warning

Enqueueing a public function call is an inherently leaky action. Many interesting applications will require some interaction with public state, but smart contract developers should try to use public function calls sparingly, and carefully. Internal public function calls are especially leaky, because they completely leak which private contract made the call. See also: https://docs.aztec.network/developers/resources/considerations/privacy_considerations

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• args - Array of arguments to pass to the public function
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Enqueues a read-only call to a public function.

This is similar to Solidity's staticcall. The called function cannot modify state or emit events. Any nested calls are constrained to also be staticcalls.

See also call_public_function for more important information about making private -> public function calls.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• args - Array of arguments to pass to the public function
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Enqueues a call to a public function that takes no arguments.

This is an optimisation for calling public functions that don't take any input parameters. It's otherwise equivalent to call_public_function.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Enqueues a read-only call to a public function with no arguments.

This combines the optimisation of call_public_function_no_args with the safety of static_call_public_function.

Arguments

• contract_address - Address of the contract containing the function
• function_selector - 4-byte identifier of the function to call
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Low-level public function call.

This is the underlying implementation used by all other public function call methods. Instead of taking raw arguments, it accepts a hash of the arguments.

Advanced function: Most developers should use call_public_function or static_call_public_function instead. This function is exposed for performance optimization and advanced use cases.

Arguments

• contract_address - Address of the contract containing the function
• calldata_hash - Hash of the function calldata
• is_static_call - Whether this should be a read-only call
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Enqueues a public function call, and designates it to be the teardown function for this tx. Only one teardown function call can be made by a tx.

Niche function: Only wallet developers and paymaster contract developers (aka Fee-payment contracts) will need to make use of this function.

Aztec supports a three-phase execution model: setup, app logic, teardown. The phases exist to enable a fee payer to take on the risk of paying a transaction fee, safe in the knowledge that their payment (in whatever token or method the user chooses) will succeed, regardless of whether the app logic will succeed. The "setup" phase ensures the fee payer has sufficient balance to pay the proposer their fees. The teardown phase is primarily intended to: calculate exactly how much the user owes, based on gas consumption, and refund the user any change.

Note: in some cases, the cost of refunding the user (i.e. DA costs of tx side-effects) might exceed the refund amount. For app logic with fairly stable and predictable gas consumption, a material refund amount is unlikely. For app logic with unpredictable gas consumption, a refund might be important to the user (e.g. if a hefty function reverts very early). Wallet/FPC/Paymaster developers should be mindful of this.

Arguments

• contract_address - Address of the contract containing the teardown function
• function_selector - 4-byte identifier of the function to call
• args - An array of fields to pass to the function.
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true

Low-level function to set the public teardown function.

This is the underlying implementation for setting the teardown function call that will execute at the end of the transaction. Instead of taking raw arguments, it accepts a hash of the arguments.

Advanced function: Most developers should use set_public_teardown_function instead.

Arguments

• contract_address - Address of the contract containing the teardown function
• calldata_hash - Hash of the function calldata
• is_static_call - Whether this should be a read-only call
• hide_msg_sender - the called function will see a "null" value for msg_sender if set to true