Aztec (AZTEC) Price

Aztec is a Layer 2 network focused on programmable privacy that settles to Ethereum. Developers can specify which functions and states remain private and which are public within the same hybrid contract; therefore, it does not hide all activity indiscriminately, as the public-private boundary is determined by application design. Its key objective is to reduce the direct posting of sensitive information on-chain while retaining verifiability. Private execution and proof generation can occur on users' devices; the network verifies proofs and updates state, and blocks ultimately settle to Ethereum using zero-knowledge proofs, enabling anyone to verify the network state.

AZTEC is the native token of the Aztec network and an ERC-20 token on Ethereum. The official documentation lists an initial total supply of 10,350,000,000 AZTEC; “fixed initial total supply” does not mean the circulating supply will remain unchanged forever. The protocol also has a controlled reward mechanism: tokens used for rewards are pre-minted to the RewardDistributor contract and then distributed by slot. The documentation describes these distributions as not being new net inflationary mints, but they do become newly circulating tokens; therefore, supply should be understood by distinguishing the initial total supply, reward-reserve distributions, and actual circulating supply.

AZTEC has three disclosed core roles: after bridging, it becomes Fee Juice for paying network fees; sequencers and validators stake it to participate in block production; and holders may participate in protocol governance subject to the rules. It does not represent company equity or promise fixed returns. The three roles correspond to different functions: fees pay for transaction processing, staking provides economic constraints for block production, and governance determines protocol upgrades and certain network parameters. Holding the token itself does not mean automatically running a node, automatically receiving rewards, or automatically having voting eligibility; specific participation is also subject to conditions such as staking or governance locking.

Aztec's private functionality is not simply a matter of uploading transaction contents and then masking them. A user's device first executes computations on private functions and sensitive data and generates a zero-knowledge proof; the proof expresses that “the operation complies with the rules” without requiring disclosure of the original sensitive information. The decentralized sequencer network then verifies private transaction proofs and updates private state. If a hybrid transaction contains public functions, the network also executes the public portion and updates public state. Sequencers propose blocks, provers generate zero-knowledge proofs for blocks, and blocks ultimately settle to Ethereum. If an application chooses public functions, interacts with public state, or exposes related metadata, visible information may still result; therefore, the scope of privacy depends on application design and actual interactions.

On Aztec, users pay transaction fees with Fee Juice rather than transferring AZTEC directly within the network. Fee Juice is a non-transferable fee asset created by bridging AZTEC from Ethereum to Aztec, and it can be used to send private transactions, call smart contracts, and deploy contracts. This distinction reflects how the fee asset is created: AZTEC first exists on Ethereum, then bridging creates Fee Juice for payments within the Aztec network. Because Fee Juice is non-transferable, holding AZTEC on Ethereum does not mean that one already holds the in-network fee asset that can directly pay Aztec transaction fees.

Sequencers and validators must stake AZTEC to participate in block production; staked tokens are locked in smart contracts to provide economic incentives for honest operation. Holders may also delegate their stake to operators without maintaining sequencer infrastructure themselves. Participation does not provide unconditional returns: becoming an active validator requires meeting the minimum staking threshold and maintaining the corresponding infrastructure and availability. If a validator violates the protocol, remains inactive for an extended period, or proposes or proves invalid blocks, its own or delegated stake may be partially slashed; slashing is based on evidence collected on-chain and off-chain and is handled through a governance vote.

Exiting staking does not return tokens immediately. Users first initiate an exit, and tokens remain locked during the waiting period; the mainnet unstaking delay is 4 days, after which withdrawal can be completed. The waiting period preserves time to discover and address potential slashing events that occurred during active participation. If tokens are also deposited into Governance Staking Escrow (GSE) for voting, a longer governance withdrawal delay applies: approximately 38 days on mainnet. This duration consists of votingDelay/5 + votingDuration + executionDelay, with the mainnet example in the documentation being approximately 0.6 days + 7 days + 30 days; no staking rewards are earned during the exit waiting period, and tokens may still be slashed for misconduct during active participation.

Rewards for network participants come from two sources: checkpoint rewards issued by the protocol per proven slot and transaction fees paid by users. The current documentation lists checkpoint rewards of 400 AZTEC per slot, of which sequencers receive 70%, or 280 AZTEC, and provers receive 30%, or 120 AZTEC. Sequencers receive their checkpoint share after the block is finalized on L1, along with 70% of the remaining transaction fees after congestion-cost burning; provers receive 30% of the remaining unburned transaction fees. Provers' checkpoint rewards are distributed according to activity scores rather than equally: continuous participation raises the score, while prolonged inactivity lowers it and therefore reduces the reward share.

AZTEC holders can participate in protocol governance, including voting on protocol upgrades and influencing network parameters. However, the official participation table states that voting requires tokens that are staked or governance-locked; arbitrary unlocked balances do not automatically have the same participation conditions. Governance allows token holders to participate in rule changes; for example, the documentation states that checkpoint reward values can be adjusted through governance. A vote represents governance power within the process, not a guarantee that an individual's preference will be implemented, and it should not be conflated with node operation, fee payment, or a return commitment.