Fees

Fees are an integral part of any protocol's design. Proper fee pricing contributes to the longevity and security of a network, and the fee payment mechanisms available inform the types of applications that can be built.

In a nutshell, the pricing of transactions transparently accounts for:

• L1 costs, including L1 execution of a block, and data availability via blobs,
• L2 node operating costs, including proving

This is achieved through multiple variables and calculations.

Terminology and factors

Familiar terms from Ethereum mainnet as referred to on the Aztec network:

Ethereum Mainnet	Aztec	Description
gas	mana	unit measuring computational effort for transaction operations
fee per gas	Aztec token per mana	price per unit of mana
fee (wei)	Aztec token	total fee paid for a transaction

Fees on Aztec are paid in the Aztec token, which is bridged from L1. An oracle informs the price of Aztec token per wei, which can be used to calculate a transaction's fee in wei.

Aztec also borrows ideas from EIP-1559, including congestion multipliers and the ability to specify base and priority fees per mana.

Aztec-specific fields

Other fields used in mana and fee calculations are determined in various ways:

• hard-coded constants (eg congestion update fraction)
• values assumed constant (eg L1 gas cost of publishing a block, blobs per block)
• informed from previous block header and/or L1 rollup contract (eg base fee per mana)
• informed via an oracle (eg wei per mana)

Most constants are defined by the protocol, while others are part of the rollup contract on L1.

User-defined settings

Users can define the following settings as part of a transaction:

gas_settings_vars

/** Gas usage and fees limits set by the transaction sender for different dimensions and phases. */
export class GasSettings {
  constructor(
    public readonly gasLimits: Gas,
    public readonly teardownGasLimits: Gas,
    public readonly maxFeesPerGas: GasFees,
    public readonly maxPriorityFeesPerGas: GasFees,
  ) {}

^{_{Source code: yarn-project/stdlib/src/gas/gas_settings.ts#L17-L26}}

The Gas and GasFees types each specify Data availability and L2 cost components, so the settings are:

• gasLimits: DA and L2 gas limits
• teardownGasLimits: DA and L2 gas limits for a txs optional teardown operation
• maxFeesPerGas: maximum DA and L2 fees-per-gas
• maxPriorityFeesPerGas: maximum priority DA and L2 fees-per-gas

Fee payment

A fee payer will have bridged the Aztec token from L1. On Aztec this fee asset is non-transferable, and only deducted by the protocol to pay for fees. A user can claim bridged Aztec token and use it to pay for transaction fees in the same transaction.

The mechanism for bridging is the same as any other token. For more on this concept see the Token Bridge Tutorial which describes portal contracts and cross-chain messaging.

Payment methods

An account with the Aztec token can pay for its transactions directly, including deployment of a new account, if the Aztec token has been bridged to the address where the account will be deployed.

Alternatively, accounts can use fee-paying contracts (FPCs) to pay for transactions. FPCs accept tokens and pay fees in the Aztec token on behalf of users. Common patterns include:

• Sponsored FPCs: Pay fees unconditionally, enabling free transactions for users
• Token-accepting FPCs: Accept a specific token in exchange for paying fees

FPCs can contain arbitrary logic to authorize fee payments and can operate privately or publicly.

Teardown phase

Transactions can optionally have a "teardown" phase as part of their public execution, during which the "transaction fee" is available to public functions. This is useful to transactions/contracts that need to compute a "refund", e.g. contracts that facilitate fee abstraction.

This enables FPCs to calculate the actual transaction cost and refund any overpayment to the user.

Operator rewards

The calculated fee of a transaction is deducted from the fee payer (nominated account or fee-paying contract), then pooled together across transactions, blocks, and epochs. Once an epoch is proven, the total collected fees (minus any burnt congestion amount) are distributed to the provers and block proposers that contributed to the epoch.

Next steps

For a guide on paying fees programmatically, see How to Pay Fees.