Vision
16 Sep
## min read

Vulnerabilities patched in Aztec 2.0

Aztec 2.0's recent security enhancements address key vulnerabilities, bolstering trust and safety in the network.

Share
Written by
Zac Williamson
Edited by

In March 2021, we launched Aztec 2.0, which enables users to shield and send funds privately through Aztec private rollups. Aztec 2.0 utilizes our state of the art zkSNARK proving system, PLONK, developed in-house for the express purpose of scaling Ethereum with strong user privacy guarantees.

Aztec 2.0 is built with bleeding-edge cryptography and it is critical to promptly address any bugs. Aztec is in a continual state of audit internally and externally, incentivized by a bug bounty with Immunefi. Our core team discovered two security vulnerabilities as part of our internal efforts, with special thanks to our chief scientist Ariel Gabizon. Community members Sean Bowe and Daira Hopwood also highlighted vulnerabilities.

Transparency is important to us. We want our users to trust our technology not because nobody can understand it, but because anybody can understand it. In this post, we discuss the bugs discovered in Aztec 2.0 after deployment. These security vulnerabilities have been patched and we are confident no user funds have been lost.

Bugs found and addressed pre-launch

See also bugs previously reported in this post.

Bug: Pedersen hash input checks

We use Pedersen hashes inside our circuits when a collision-resistant hash function is required (i.e. when the hash function does not need to be modelled as a random oracle).

When performing a Pedersen hash in TurboPlonk, the binary representation of each input field element is split into 128 2-bit windows, whose sum is equal to the input.

Each window is used to index a 2-bit lookup table of elliptic curve generator points, which are summed together to produce the Pedersen hash output.

The bug was that, when validating the sum of the windows equalled the input field element, we were validating this [mod p], where p is the native circuit modulus.

This meant that every hash input effectively had two possible representations in 2-bit window form (the actual binary value or the value + [p]). This meant that every Pedersen hash effectively had two different outputs.

A consequence of this bug is that it was possible to generate two nullifiers for every note. This would enable a double-spending attack.

Action Taken

Our circuits were updated to always validate the sum of Pedersen hash input 2-bit windows were [< p], when required.

Risks to Users

None. This bug was identified and fixed before we launched.

Bugs found and patched post-launch

Bug: Merkle root position check

The rollup contains a “root” tree; a Merkle tree containing the past Merkle roots of the note tree (which contains all join-split “value” notes and user “account” notes).

As part of the root rollup circuit, the rollup provider must compute the new root of the note tree and insert it into the root tree. The intended position of the new leaf in the tree is directly adjacent to the rightmost non-zero leaf; i.e. the tree is initialized to all zero leaves, and then updated from left-to-right.

The bug was that our circuit did not actually constrain the position of the new leaf. In reality, the rollup provider could have inserted the new leaf at *any* position in the root tree. An adversary would have been able to insert a leaf at an arbitrary location in the root tree and not reveal the location (this location is not a public input).

If after such an insertion the adversary doesn’t participate in future rollup creation, from that point on *nobody else* can create a valid rollup and the system is frozen and unable to process for any future transactions.

Action taken

The root rollup circuit was modified to validate leaves inserted into the root tree are at the correct position. The rollup smart contract was updated to use the verification keys from the new circuit.

Risks to users

In theory, a malicious actor had two months to find and exploit this bug. However, the only entity able to launch this attack was the rollup provider. Currently, only Aztec can create and submit rollup proofs.

We confirmed there was no attack by reconstructing the data root tree and validating there are no out-of-position leaves.

Bug: Recursive proof verification

When aggregating private transactions in our rollup circuit, we use the following circuit structure:

Join-split Circuit: Executes a private transaction; generated by the user locally on their device.

Rollup Circuit: Verifies the correctness of 28 join-split circuit proofs and performs database updates into the rollup’s Merkle trees.

Root Rollup Circuit: Verifies the correctness of 4 rollup circuit proofs.When verifying a Plonk proof inside one of our circuits, partial verification and proof aggregation occurs.Each proof is verified up to the point that a bilinear pairing check is required. The Plonk verification algorithm’s bilinear pairing check is structured such that both G2 group elements are fixed and do not vary between different proofs.

Instead of performing this pairing check inside our root rollup circuit, these two group elements are defined to be public inputs of the root rollup circuit. i.e. they are broadcasted on-chain as part of the root rollup proof.

The verifier smart contract will then extract the two group elements and aggregate them into the pairing check computed by the smart contract.

The bug was that, when performing the proof aggregation step in the root rollup circuit, we were aggregating only the rollup proofs, but not the join-split proofs.

Action Taken

The root rollup circuit was modified to correctly aggregate join-split circuit proofs. The rollup smart contract was updated to use the verification keys from the new circuit.

Risks to Users

This bug enables an adversary to generate fake join-split proofs (e.g. double spend transactions). This would not have been picked up by either the rollup circuit logic or the verifier smart contract logic. If an attacker generated a fake join-split proof, they would need to convince a rollup provider to include their malicious proof in a rollup circuit proof.

Aztec is currently the only rollup provider and we use our falafel software library to validate the correctness of every join-split proof included in a rollup. The verification logic in falafel was not affected by this bug. As a result, we are confident that no malicious proofs were included in any rollup block because of this bug

Bug: Generating randomness

When generating random secrets, a Mersenne Twister was being used with a random seed. The determinism of the twister made this unsuitable as all random variables produced in a proof could be determined with knowledge of one of them. This issue should not have affected the generation of user secrets and private keys.

Action Taken

The Mersenne Twister was removed. Random number generation is delegated to the base operating system. On the web, this is done via the WebCrypto API.

Risks to Users

This bug affected random numbers generated in two instances:

  • Users creating privacy proofs
  • Rollup providers creating rollup proofs

The rollup proof does not have to be zero-knowledge as no secret information is hidden (privacy is achieved entirely via the privacy proof).

When constructing a privacy proof, several random variables are generated as blinding factors. If any of these leak, then it is possible to recover the remaining randomness using this bug and remove the blinding factors from the proof. In theory, this would allow an attacker to recover user secrets and private keys.

It is expected that no random variables are leaked when generating a proof. If a variable is leaked, the user’s device is compromised and it is likely an attacker has access to all 12 random variables regardless.

Bug: Generating prime field elements

When generating random 254-bit prime field elements, a random 256-bit number was generated and then truncated modulo the field order. This produces random numbers where smaller values have a significant positive bias.

Risks to Users

Notes and nullifiers generated prior to May 6th will be marginally easier to decipher via brute-force attacks. Such attacks are still not remotely practical and we are confident that users affected by this issue do not need to regenerate their Aztec private keys.

Action Taken

Random field elements are now generated via creating a 512-bit number and reducing modulo the field modulus. This largely eliminates any bias in the resulting field element.

The last two issues were found with the help of Daira Hopwood and Sean Bowe from the Electric Coin Company. They will both receive zkETH as a thanks for their help.

Bug: Not checking decrypted note details match insertion to tree

During a transaction, a recipient receives the details of their new note in an encrypted message. We weren’t checking that the commitment added to the note tree indeed corresponds to these note details.

Risks to Users

An attacker could have made the user think they received funds that were not really sent. Only when trying to spend the funds using the decrypted note details, would the user realize the problem.

Action Taken

In our code update from May 6th, we added the required checks in our client software that validates viewing keys map to legitimate notes in the Aztec state tree.

We developed PLONK in order to bring scalable privacy to Ethereum. As the team behind this breakthrough cryptography, we take our responsibility to the security of users’ funds and user privacy very seriously. Particularly during these early deployment stages, we will continuously audit and patch the code as necessary.

While we have an incredibly talented core team, we don’t expect that potential vulnerabilities will solely be detected internally. Community members are an essential part of our development process.

We welcome your feedback and contributions to our auditing efforts.

➡️ Get in touch with our team on Discord.

Our currently deployed code can be found on our bug bounty repository.

Read more
Aztec Network
Aztec Network
10 Mar
xx min read

Alpha Network Security: What to Expect

Aztec’s Approach to Security

Aztec is novel code — the bleeding edge of cryptography and blockchain technology. As the first decentralized L2 on Ethereum, Aztec is powered by a global network of sequencers and provers. Decentralization introduces some novel challenges in how security is addressed; there is no centralized sequencer to pause or a centralized entity who has power over the network. The rollout of the network reflects this, with distinct goals at each phase.

Ignition

Validate governance and decentralized block building work as intended on Ethereum Mainnet. 

Alpha

Enable transactions at 1TPS, ~6s block times and improve the security of the network via continual ongoing audits and bug bounty. New releases of the alpha network are expected regularly to address any security vulnerabilities. Please note, every alpha deployment is distinct and state is not migrated between Alpha releases. 

Beta

We will transition to Beta once the network scales to >10 TPS, with reduced block times while ensuring 99.9% uptime. Additionally, the transition requires no critical bugs disclosed via bug bounty in 3 months. State migrations across network releases can be considered.

TL;DR: The roadmap from Ignition to Alpha to Beta is designed to reflect the core team's growing confidence in the network's security.

This phased approach lets us balance ecosystem growth while building security confidence and steadily expanding the community of researchers and tools working to validate the network’s security, soundness and correctness.

Ultimately, time in production without an exploit is the most reliable indicator of how secure a codebase is.

At the start of Alpha, that confidence is still developing. The core team believes the network is secure enough to support early ecosystem use cases and handle small amounts of value. However this is experimental alpha software and users should not deposit more value than they are willing to lose. Apps may choose to limit deposit amounts to mitigate risk for users.

Audits are ongoing throughout Alpha, with the goal to achieve dual external audits across the entire codebase.

The table below shows current security and audit coverage at the time of writing.

The main bug bounty for the network is not yet live, other than for the non-cryptographic L1 smart contracts as audits are ongoing. We encourage security researchers to responsibly disclose findings in line with our security policy .

As the audits are still ongoing, we expect to discover vulnerabilities in various components. The fixes will be packaged and distributed with the “v5” release.

If we discover a Critical vulnerability in “v4” in accordance with the following severity matrix, which would require the change of verification keys to fix, we will first alert the portal operators to pause deposits and then post a message on the forum, stating that the rollup has a vulnerability.

Security of the Aztec Virtual Machine (AVM)

Aztec uses a hybrid execution model, handling private and public execution separately — and the security considerations differ between them.

As per the audit table above, it is clear that the Aztec Virtual Machine (AVM) has not yet completed its internal and external audits. This is intentional as all AVM execution is public, which allows it to benefit from a “Training Wheel” — the validator re-execution committee.

Every 72 seconds, a collection of newly proposed Aztec blocks are bundled into a "checkpoint" and submitted to L1. With each proposed checkpoint, a committee of 48 staking validators randomly selected from the entire set of validators (presently 3,959) re-execute all txs of all blocks in the checkpoint, and attest to the resulting state roots. 33 out of 48 attestations are required for the checkpoint proposal to be considered valid. The committee and the eventual zk proof must agree on the resultant state root for a checkpoint to be added to the proven chain. As a result, an attacker must control 33/48 of any given committee to exploit any bug in the AVM.

The only time the re-execution committee is not active is during the escape hatch, where the cost to propose a block is set at a level which attempts to quantify the security of the execution training wheel. For this version of the alpha network, this is set a 332M AZTEC, a figure intended to approximate the economic protection the committee normally provides, equivalent to roughly 19% of the un-staked circulating supply at the time of writing. Since the Aztec Foundation holds a significant portion of that supply, the effective threshold is considerably higher in practice.

Quantifying the cost of committee takeover attacks

A key design assumption is that just-in-time bribery of the sequencer committee is impractical and the only ****realistic attack vector is stake acquisition, not bribery.

Assuming a sequencer set size of 4,000 and a committee that rotates each epoch (~38.4mins) from the full sequencer set using a Fisher-Yates shuffle seeded by L1 RANDAO we can see the probability and amount of stake required in the table below.

To achieve a 99% probability of controlling at least one supermajority within 3 days, an attacker would need to control approximately 55.4% of the validator set - roughly 2,215 sequencers representing 443M AZTEC in stake. Assuming an exploit is successful their stake would likely de-value by 70-80%, resulting in an expected economic loss of approximately 332M AZTEC.

To achieve only a 0.5% probability of controlling at least one supermajority within 6 months, an attacker would need to control approximately 33.88% of the validator set.

What does this means for builders?

The practical effect of this training wheel is that the network can exist while there are known security issues with the AVM, as long as the value an attacker would gain from any potential exploit is less than the cost of acquiring 332M AZTEC.

The training wheel allows security researchers to spend more time on the private execution paths that don’t benefit from the training wheel and for the network to be deployed in an alpha version where security researchers can attempt to find additional AVM exploits.

In concrete terms, the training wheel means the Alpha network can reasonably secure value up to around 332M AZTEC (~$6.5M at the time of writing).

Ecosystem builders should keep the above limits in mind, particularly when designing portal contracts that bridge funds into the network.

Portals are the main way value will be bridged into the alpha network, and as a result are also the main target for any exploits. The design of portals can allow the network to secure far higher value. If a portal secures > 332M AZTEC and allows all of its funds to be taken in one withdrawal without any rate limits, delays or pause functionality then it is a target for an AVM exploit attack.

If a portal implements a maximum withdrawal per user, pause functionality or delays for larger withdrawals it becomes harder for an attacker to steal a large quantum of funds in one go.

Conclusion

The Aztec Alpha code is ready to go. The next step is for someone in the community to submit a governance proposal and for the network to vote on enabling transactions. This is decentralization working as intended.

Once live, Alpha will run at 1 TPS with roughly 6 second block times. Audits are still ongoing across several components, so keep deposits small and only put in what you're comfortable losing.

On the security side, a 48-validator re-execution committee provides the main protection during Alpha, requiring 33/48 consensus on every 72-second checkpoint. Successfully attacking the AVM would require controlling roughly 55% of the validator set at a cost of around 332M AZTEC, putting the practical security ceiling at approximately $6.5M.

Alpha is about growing the ecosystem, expanding the security of the network, and accumulating the one thing no audit can shortcut: time in production. This is the network maturing in exactly the way it was designed to as it progresses toward Beta.

Aztec Network
Aztec Network
4 Mar
xx min read

Aztec Network: Roadmap Update

The Ignition Chain launched late last year, as the first fully decentralized L2 on Ethereum– a huge milestone for decentralized networks. The team has reinvented what true programmable privacy means, building the execution model from the ground up— combining the programmability of Ethereum with the privacy of Zcash in a single execution environment.

Since then, the network has been running with zero downtime with 3,500+ sequencers and 50+ provers across five continents. With the infrastructure now in place, the network is fully in the hands of the community, and the culmination of the past 8 years of work is now converging. 

Major upgrades have landed across four tracks: the execution layer, the proving system, the programming language, Noir, and the decentralization stack. Together, these milestones deliver on Aztec’s original promise, a system where developers can write fully programmable smart contracts with customizable privacy.

The infrastructure is in place. The code is ready. And we’re ready to ship. 

What’s New on the Roadmap?

The Execution Layer

The execution layer delivers on Aztec's core promise: fully programmable, privacy-preserving smart contracts on Ethereum. 

A complete dual state model is now in place–with both private and public state. Private functions execute client-side in the Private Execution Environment (PXE), running directly in the user's browser and generating zero-knowledge proofs locally, so that private data never leaves the original device. Public functions execute on the Aztec Virtual Machine (AVM) on the network side. 

Aztec.js is now live, giving developers a full SDK for managing accounts and interacting with contracts. Native account abstraction has been implemented, meaning every account is a smart contract with customizable authentication rules. Note discovery has been solved through a tagging mechanism, allowing recipients to efficiently query for relevant notes without downloading and decrypting everything on the network.

Contract standards are underway, with the Wonderland team delivering AIP-20 for tokens and AIP-721 for NFTs, along with escrow contracts and logic libraries, providing the production-ready building blocks for the Alpha Network. 

The Proving System

The proving system is what makes Aztec's privacy guarantees real, and it has deep roots.

In 2019, Aztec's cofounder Zac Williamson and Chief Scientist Ariel Gabizon introduced PLONK, which became one of the most widely used proving systems in zero-knowledge cryptography. Since then, Aztec's cryptographic backend, Barretenberg, has evolved through multiple generations, each facilitating faster, lighter, and more efficient proving than the last. The latest innovation, CHONK (Client-side Highly Optimized ploNK), is purpose-built for proving on phones and browsers and is what powers proof generation for the Alpha Network.

CHONK is a major leap forward for the user experience, dramatically reducing the memory and time required to generate proofs on consumer devices. It leverages best-in-class circuit primitives, a HyperNova-style folding scheme for efficiently processing chains of private function calls, and Goblin, a hyper-efficient purpose-built recursion acceleration scheme. The result is that private transactions can be proven on the devices people actually use, not just powerful servers.

This matters because privacy on Aztec means proofs are generated on the user's own device, keeping private data private. If proving is too slow or too resource-intensive, privacy becomes impractical. CHONK makes it practical.

Decentralization

Decentralization is what makes Aztec's privacy guarantees credible. Without it, a central operator could censor transactions, introduce backdoors, or compromise user privacy at will. 

Aztec addressed this by hardcoding decentralized sequencing, proving, and governance directly into the base protocol. The Ignition Chain has proven the stability of this consensus layer, maintaining zero downtime with over 3,500 sequencers and 50+ provers running across five continents. Aztec Labs and the Aztec Foundation run no sequencers and do not participate in governance.

Noir

Noir 1.0 is nearing completion, bringing a stable, production-grade language within reach. Aztec's own protocol circuits have been entirely rewritten in Noir, meaning the language is already battle-tested at the deepest layer of the stack. 

Internal and external audits of the compiler and toolchain are progressing in parallel, and security tooling including fuzzers and bytecode parsers is nearly finished. A stable, audited language means application teams can build on Alpha with confidence that the foundation beneath them won't shift.

What Comes Next

The code for Alpha Network, a functionally complete and raw version of the network, is ready.

The Alpha Network brings fully programmable, privacy-preserving smart contracts to Ethereum for the first time. It's the culmination of years of parallel work across the four tracks in the Aztec Roadmap. Together, they enable efficient client-side proofs that power customizable smart contracts, letting users choose exactly what stays private and what goes public. 

No other project in the space is close to shipping this. 

The code is written. The network is running. All the pieces are in place. The governance proposal is now live on the forum and open for discussion. Read through it, ask questions, poke holes, and help shape the path forward. 

Once the community is aligned, the proposal moves to a vote. This is how a decentralized network upgrades. Not by a team pushing a button, but by the people running it.

Programmable privacy will unlock a renaissance in onchain adoption. Real-world applications are coming and institutions are paying attention. Alpha represents the culmination of eight years of intense work to deliver privacy on Ethereum. 

Now it needs to be battle-tested in the wild. 

View the updated product roadmap here and join us on Thursday, March 5th, at 3 pm UTC on X to hear more about the most recent updates to our product roadmap.

Aztec Network
Aztec Network
30 Jan
xx min read

Aztec Ignition Chain Update

In November 2025, the Aztec Ignition Chain went live as the first decentralized L2 on Ethereum. Since launch, more than 185 operators across 5 continents have joined the network, with 3,400+ sequencers now running. The Ignition Chain is the backbone of the Aztec Network; true end-to-end programmable privacy is only possible when the underlying network is decentralized and permissionless. 

Until now, only participants from the $AZTEC token sale have been able to stake and earn block rewards ahead of Aztec's upcoming Token Generation Event (TGE), but that's about to change. Keep reading for an update on the state of the network and learn how you can spin up your own sequencer or start delegating your tokens to stake once TGE goes live.

Block Production 

The Ignition Chain launched to prove the stability of the consensus layer before the execution environment ships, which will enable privacy-preserving smart contracts. The network has remained healthy, crossing a block height of 75k blocks with zero downtime. That includes navigating Ethereum's major Fusaka upgrade in December 2025 and a governance upgrade to increase the queue speed for joining the sequencer set.

Source: AztecBlocks

Block Rewards

Over 30M $AZTEC tokens have been distributed to sequencers and provers to date. Block rewards go out every epoch (every 32 blocks), with 70% going to sequencers and 30% going to provers for generating block proofs.

If you don't want to run your own node, you can delegate your stake and share in block rewards through the staking dashboard. Note that fractional staking is not currently supported, so you'll need 200k $AZTEC tokens to stake.

Global Participation  

The Ignition Chain launched as a decentralized network from day one. The Aztec Labs and Aztec Foundation teams are not running any sequencers on the network or participating in governance. This is your network.

Anyone who purchased 200k+ tokens in the token sale can stake or delegate their tokens on the staking dashboard. Over 180 operators are now running sequencers, with more joining daily as they enter the sequencer set from the queue. And it's not just sequencers: 50+ provers have joined the permissionless, decentralized prover network to generate block proofs.

These operators span the globe, from solo stakers to data centers, from Australia to Portugal.

Source: Nethermind 

Node Performance

Participating sequencers have maintained a 99%+ attestation rate since network launch, demonstrating strong commitment and network health. Top performers include P2P.org, Nethermind, and ZKV. You can see all block activity and staker performance on the Dashtec dashboard. 

How to Join the Network 

On January 26th, 2026, the community passed a governance proposal for TGE. This makes tokens tradable and unlocks the AZTEC/ETH Uniswap pool as early as February 11, 2026. Once that happens, anyone with 200k $AZTEC tokens can run a sequencer or delegate their stake to participate in block rewards.

Here's what you need to run a validator node:

  • CPU: 8 cores
  • RAM: 16 GB
  • Storage: 1 TB NVMe SSD
  • Bandwidth: 25 Mbps

These are accessible specs for most solo stakers. If you've run an Ethereum validator before, you're already well-equipped.

To get started, head to the Aztec docs for step-by-step instructions on setting up your node. You can also join the Discord to connect with other operators, ask questions, and get support from the community. Whether you run your own hardware or delegate to an experienced operator, you're helping build the infrastructure for a privacy-preserving future.

Solo stakers are the beating heart of the Aztec Network. Welcome aboard.

Aztec Network
Aztec Network
22 Jan
xx min read

The $AZTEC TGE Vote: What You Need to Know

The TL:DR:

  • The $AZTEC token sale, conducted entirely onchain concluded on December 6, 2025, with ~50% of the capital committed coming from the community. 
  • Immediately following the sale, tokens could be withdrawn from the sale website into personal Token Vault smart contracts on the Ethereum mainnet.
  • The proposal for TGE (Token Generation Event) is now live, and sequencers can start signaling to bring the proposal to a vote to unlock these tokens and make them tradeable. 
  • Anyone who participated in the token sale can participate in the TGE vote. 

The $AZTEC token sale was the first of its kind, conducted entirely onchain with ~50% of the capital committed coming from the community. The sale was conducted completely onchain to ensure that you have control over your tokens from day one. As we approach the TGE vote, all token sale participants will be able to vote to unlock their tokens and make them tradable. 

What Is This Vote About?

Immediately following the $AZTEC token sale, tokens could be withdrawn from the sale website into your personal Token Vault smart contracts on the Ethereum mainnet. Right now, token holders are not able to transfer or trade these tokens. 

The TGE is a governance vote that decides when to unlock these tokens. If the vote passes, three things happen:

  1. Tokens purchased in the token sale become fully transferable 
  2. Trading goes live for the Uniswap v4 pool
  3. Block rewards become transferable for sequencers

This decision is entirely in the hands of $AZTEC token holders. The Aztec Labs and Aztec Foundation teams, and investors cannot participate in staking or governance for 12 months, which includes the TGE governance proposal. Team and investor tokens will also remain locked for 1 year and then slowly unlock over the next 2 years. 

The proposal for TGE is now live, and sequencers are already signaling to bring the proposal to a vote. Once enough sequencers have signaled, anyone who participated in the token sale will be able to connect their Token Vault contract to the governance dashboard to vote. Note, this will require you to stake/unstake and follow the regular 15-day process to withdraw tokens.

If the vote passes, TGE can go live as early as February 12, 2026, at 7am UTC. TGE can be executed by the first person to call the execute function to execute the proposal after the time above. 

How Do I Participate?

If you participated in the token sale, you don't have to do anything if you prefer not to vote. If the vote passes, your tokens will become available to trade at TGE. If you want to vote, the process happens in two phases:

Phase 1: Sequencer Signaling

Sequencers kick things off by signaling their support. Once 600 out of 1,000 sequencers signal, the proposal moves to a community vote.

Phase 2: Community Voting

After sequencers create the proposal, all Token Vault holders can vote using the voting governance dashboard. Please note that anyone who wants to vote must stake their tokens, locking their tokens for at least 15 days to ensure the proposal can be executed before the voter exits. Once signaling is complete, the timeline is as follows:

  • Days 1–3: Waiting period 
  • Days 4–10: Voting period (7 days to cast your vote)
  • Days 11–17: Execution delay
  • Days 18–24: Grace period to execute the proposal

Vote Requirements:

  • At least 100M tokens must participate in the vote. This is less than 10% of the tokens sold in the token sale.  
  • 66% of votes must be in favor for the vote to pass.

Frequently Asked Questions

Do I need to participate in the vote? No. If you don't vote, your tokens will become available for trading when TGE goes live. 

Can I vote if I have less than 200,000 tokens? Yes! Anyone who participated in the token sale can participate in the TGE vote. You'll need to connect your wallet to the governance dashboard to vote. 

Is there a withdrawal period for my tokens after I vote? Yes. If you participate in the vote, you will need to withdraw your tokens after voting. Voters can initiate a withdrawal of their tokens immediately after voting, but require a standard 15-day withdrawal period to ensure the vote is executed before voters can exit.

If I have over 200,000 tokens is additional action required to make my tokens tradable after TGE? Yes. If you purchased over 200,000 $AZTEC tokens, you will need to stake your tokens before they become tradable. 

What if the vote fails? A new proposal can be submitted. Your tokens remain locked until a successful vote is completed, or the fallback date of November 13, 2026, whichever happens first.

I'm a Genesis sequencer. Does this apply to me? Genesis sequencer tokens cannot be unlocked early. You must wait until November 13, 2026, to withdraw. However, you can still influence the vote by signaling, earn block rewards, and benefit from trading being enabled.

Where to Learn More

This overview covers the essentials, but the full technical proposal includes contract addresses, code details, and step-by-step instructions for sequencers and advanced users. 

Read the complete proposal on the Aztec Forum and join us for the Privacy Rabbit Hole on Discord happening this Thursday, January 22, 2026, at 15:00 UTC. 

Follow Aztec on X to stay up to date on the latest developments.