Proposal: Execute TGE Payload to Unlock $AZTEC Token Transfers

Governance
1

Proposal: Execute TGE Payload to Unlock $AZTEC Token Transfers

Summary

This proposal requests that Aztec governance schedule and execute the TGE payload to unlock $AZTEC token transfers as early as February 11th, 2026 at 14:00 UTC. Upon execution, 100% of tokens from the public sale will become fully transferable, accumulated staking rewards will be claimable, and the Uniswap v4 pool will go live.

Note: This is a community proposal for review and discussion. No one should signal or vote for a payload they haven’t personally verified.

Motivation

As a Genesis Sequencer since day one, we believe it’s time to unlock the network’s full potential.

Why now?

  1. Privacy is gaining momentum. The broader crypto ecosystem is waking up to the importance of confidential transactions and private state. Aztec has spent years building the foundational technology. With privacy discourse accelerating across the industry, now is the time to capitalize on this momentum and let the network operate at full capacity.

  2. Honoring expectations. During the token sale, participants were informed that TGE could happen as early as February 11th, 2026. The 90-day accelerated lock period makes this possible. This proposal moves to execute TGE at the earliest opportunity.

  3. Enabling full participation. The network is live, sequencers are producing blocks, and it’s time for token holders to fully participate. This also enables broader ecosystem readiness (wallets, infrastructure, liquidity) around a transparent governance timeline.

Specification

Payload Details

Item Value
Payload Address 0x77A5EEF319E23615B848a09Ebd151744547b959C
Repository AztecProtocol/ignition-contracts
Contract src/tge/TGEPayload.sol
Etherscan Verified Contract

What the Payload Does

The TGE payload executes a series of calls to contracts owned by Aztec Governance:

For NCATP Holders (≥ 200k tokens):

  • Accepts ownership of the Registry contract via GovernanceAcceleratedLock
  • Registers a new Staker implementation with WITHDRAWAL_TIMESTAMP set to the past, enabling immediate token withdrawal (for those who have staked at least once)

For LATP Holders (< 200k tokens):

  • Updates unlockStartTime to a past timestamp, enabling immediate token claims via claim()

Network-Wide Changes:

  • Enables Uniswap v4 trading by calling approveMigration() on the pool strategy contract
  • Enables transferability of block building rewards by calling setRewardsClaimable(true) on the Rollup contract
  • Enables voting power delegation for non-genesis sequencers in the new Staker implementation

What Becomes Unlocked at TGE

  • All tokens in Token Vaults belonging to token sale participants (100%)
  • Accumulated block rewards for stakers
  • Uniswap v4 pool (273,000,000 $AZTEC tokens + matching ETH at final clearing price)

Governance Details

Voting Parameters

Parameter Value
Eligible Voters Token sale participants and Genesis Sequencers
Quorum 100,000,000 $AZTEC minimum participation
Threshold 2/3 supermajority “Yes” required
Voting Duration 7 days
Execution Delay 7 days after successful vote

Governance Lifecycle

  1. Payload Deployment — The TGE payload contract is deployed on Ethereum mainnet :white_check_mark:
  2. Sequencer Signaling — Sequencers signal support by configuring their nodes to include the payload address in block proposals (quorum: 600 of 1000 slots)
  3. Proposal Creation — After signaling quorum, anyone can call submitRoundWinner on the Governance Proposer contract
  4. Voting Period — 7 days for eligible participants to vote
  5. Execution Delay — 7-day waiting period after successful vote
  6. TGE Execution — Anyone can execute the proposal, triggering TGE

Expected Effects

  • $AZTEC tokens from the token sale become fully transferable on Ethereum mainnet
  • No changes to allocations or balances—only transfer restrictions are removed
  • Uniswap v4 pool becomes active for trading

Security and Audits

Community members are encouraged to review the TGE payload implementation before signaling:

The payload can only be executed through Aztec Governance after a successful vote.

Sequencer Signaling (recommended: environment variable)

To signal support for the TGE payload persistently (survives node restarts), set the sequencer payload address via the environment variable:

# Add this to your .env (or docker-compose environment) and restart the node
GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS=0x77A5EEF319E23615B848a09Ebd151744547b959C

This env var corresponds to the sequencer config option --sequencer.governanceProposerPayload and is the recommended “set-and-forget” way to ensure your node continues signaling even after restarts.

Implementation Timeline

Phase Estimated Duration Target
Community discussion Ongoing —
Sequencer signaling Until quorum (600/1000) —
Proposal creation After signaling quorum —
Voting period 7 days —
Execution delay 7 days —
Earliest possible TGE — February 11, 2026 at 14:00 UTC

Note: The actual TGE date depends on when signaling quorum is reached, the proposal passes, and execution occurs.

Open Questions and Feedback

I invite the community to discuss:

  1. Timing — Are there any concerns about executing TGE at the earliest possible date?
  2. Technical — Any perceived risks or edge cases in the payload implementation?
  3. Infrastructure readiness — Are exchanges, staking providers, wallets, and other infrastructure prepared for post-TGE operations?
  4. Anything else — What questions or concerns should be addressed before signaling begins?

References

Author: BlackNodes — Genesis Sequencer

4 Likes
2

gm, please also verify the source of the ATPWithdrawableAndClaimableStakerV2 (new ATP) on etherscan!
edit: nvm i just did

3

gm,

Just a reminder that you can follow the status of this proposal in the Dune dashboard

Please leave a :heart: if you think the Aztec Governance Dashboard is useful for the community, and if we should continue with its maintenance / adding new features and insights

5 Likes
4

Thanks to BlackNodes for putting together a clear and detailed proposal.

Aztec Labs would like to confirm that we have independently reviewed the referenced TGE payload (0x77A5…959C) as implemented in src/tge/TGEPayload.sol in the AztecProtocol/ignition-contracts repository. Our review verified that the payload performs the actions described in this post and is scoped specifically to:

  • Removing transfer restrictions for token sale participants by updating the relevant lock and claim parameters
  • Enabling claimability of accumulated staking and block-building rewards
  • Enabling Uniswap v4 pool migration and trading
  • Registering the new Staker implementation with the intended delegation and withdrawal behavior
  • Making no changes to allocations, balances, or token economics beyond lifting transfer restrictions

In addition to internal verification, this payload has been reviewed by Cantina (cantina.xyz), a third-party audit firm. Their audit did not identify any critical or high-severity issues related to the intended behavior of the TGE payload. You can view the report here

As a reminder, Aztec Labs and all Aztec Labs insiders do not control governance outcomes - and will not participate in this governance proposal. Execution of this payload is only possible following successful signaling, voting, and execution through Aztec Governance, and participants should continue to perform their own due diligence before signaling or voting.

We appreciate the community’s careful review and discussion and are happy to help clarify technical questions about the payload’s behavior where useful.

– Aztec Labs

1 Like
5

Thanks for taking the lead, that’s awesome ! :slight_smile:

1 Like
6

Perhaps somebody with more solidity experience than I have could take a look at this.

In the payload up for vote, there is a function that uses the IStaking interface.

import { IStaking } from "@aztec/core/interfaces/IStaking.sol";

//

    function finalizeWithdraw(uint256 _version, address _attester)
        external
        override(IATPWithdrawableStaker, ATPWithdrawableStaker)
    {
        address rollup = ROLLUP_REGISTRY.getRollup(_version);
        IStaking(rollup).finalizeWithdraw(_attester);
    }

But when I look at the IStaking.sol interface, the function is spelled finaliseWithdraw

function finaliseWithdraw(address _attester) external;

Perhaps not so important from a grammar perspective, different strokes for different folks, but very important for code.

Can somebody with more knowledge on solidity interfaces weigh in on this?

Thanks!

1 Like
7

The ATPWithdrawableAndClaimableStakerV2 contract deployed and made available to Token Vaults by the payload is calling the correct function (finalizeWithdraw) on the rollup contract. The earlier confusion came from an outdated / incorrect interface definition that has since been corrected.

Aside: The finalizeWithdraw function exposed on the rollup contract has no access control and can be called by any address. The fix in the V2 Staker contract was for completeness purposes.

Longer explanation:

  • The staking implementation on the rollup exposes:
function finalizeWithdraw(address _attester) external;

(American spelling)

  • An older version of ATPWithdrawableStaker imported a local IStaking interface ( from "src/staking-registry/StakingRegistry.sol") that mistakenly declared:
function finaliseWithdraw(address _attester) external;

(British spelling)

  • That local interface was simply wrong. Interfaces in Solidity are compile-time only and do not affect runtime dispatch. If the function selector doesn’t exist on the target contract, the call would revert immediately.
  • In practice, this mismatch was caught and fixed by aligning the interface with the actual rollup contract.
  • The new ATPWithdrawableAndClaimableStakerV2 correctly imports IStaking from @aztec/core/interfaces/IStaking.sol, which matches the rollup ABI exactly and calls:
IStaking(rollup).finalizeWithdraw(_attester);
  • As a result:
    • The payload compiles against the correct interface
    • The calldata selector matches the deployed rollup contract
    • There is no ambiguity, fallback behaviour, or silent failure mode here

So to summarize:
This was a naming inconsistency in an older local interface, not a behavioural ambiguity. The payload under vote uses the correct interface and calls the correct function on the rollup staking contract.

Appreciate you flagging it, these are exactly the kinds of details that should be scrutinized in governance payloads.

2 Likes