Reference for triggering the $AZTEC Token Generation Event (TGE)

Governance
1

Aztec Labs, prompted by a request from the Aztec Foundation, has prepared a reference governance payload for the Token Generation Event (TGE) and to unlock the $AZTEC token for transfer as early as February 11th 2026 at 14:00 UTC. If you participated in the $AZTEC token sale, no action is required at this time. Please stay tuned for updates on the voting process in the coming weeks.

Preamble

The goal of this forum post is to share this reference payload with the community for review and describe the governance steps required for a payload to be executed.

Reference payload and contracts

The reference TGE payload has been implemented and published in the Aztec “ignition-contracts” repository.

  • Repository: AztecProtocol/ignition-contracts Github, this contains the contracts used for protocol upgrades, including a TGE reference payload.

  • TGE payload contract: src/tge/TGEPayload.sol, this contract encodes the sequence of calls that, when executed through Aztec governance, will unlock the $AZTEC token.

The payload is a contract which can be deployed on Ethereum mainnet and which conforms to the governance “payload” interface used by the Aztec Governance contracts.

If the Governance contract executes this payload after a successful vote, it will make a series of calls to trigger TGE. Note: This post refers often to Aztec Token Positions (ATPs). This term is interchangeable with the term Token Vault.

What the reference TGE payload does

The reference TGE payload needs to accomplish three key goals:

  • Allow public sale participants to withdraw their $AZTEC

  • Allow the claiming of staking rewards, proving rewards, and flushing rewards

  • Enable the Uniswap v4 pool which was created after the end of the public sale

To accomplish these goals, the payload encodes a series of calls to contracts which are owned by the Aztec Governance Contract. A quick glossary:

  • ATPs → Token vaults which holds AZTEC tokens, used primarily for vesting or locking of tokens. The owner of an ATP can use their tokens in restricted ways, depending on the type of ATP.

    • NCATP → Non Claimable ATP, used for Genesis Sequencers and public sale participants who purchased more than 200k AZTEC.

    • LATP → Linear unlock ATP, unlocks happen in a linear fashion, potentially after a predefined cliff, used for public sale participants who purchased fewer than 200k tokens.

    • MATP → Milestone unlock ATP, unlocks happen when “milestones” are achieved, the milestones are predefined (but can be updated) and can be marked as achieved by the owner of the ATP Registry, used for Insiders, and ecosystem grantees.

  • ATP Registries → controls existing configurations for ATPs. The owner of the Registry contracts can register new Staker implementations.

  • Staker implementations → each ATP can make use of a Staker contract which extends that ATP with specific staking functionality. The specific implementation of a staking contract can be specified by the owner of the ATP Registry, and can also be upgraded with new versions.

  • Rollup contract → the canonical rollup contract, which manages all reward distribution

  • Uniswap v4 Pool Strategy → the Uniswap v4 Pool created at the end of the AZTEC public sale

image
image1360Ă—1918 169 KB

The reference payload will specifically:

For Non-Genesis NCATP Holders (≥ 200k tokens):

  1. Accept ownership of the Registry contract via GovernanceAcceleratedLock

  2. Register a new Staker implementation with a WITHDRAWAL_TIMESTAMP set to the past, allowing immediate token withdrawal (if already registered at least one sequencer).

For LATP Holders (< 200k tokens):

  1. Update unlockStartTime to a past timestamp, enabling immediate token claims via claim()

Network-Wide Changes:

  1. Enable Uniswap v4 trading by calling approveMigration() on the pool strategy contract

  2. Enable transferability of block building rewards by calling setRewardsClaimable(true) on the Rollup contract

  3. Enable voting power delegation for non-genesis sequencers in the new Staker implementation

Reference

How ATPs currently work

NCATPs (≥ 200k tokens and Genesis Sequencers)

NCATPs have their claim() function disabled:

function claim() external override(IATPCore, LATPCore) onlyBeneficiary returns (uint256) {
    revert NoClaimable();
}

NCATP holders can only exit their tokens through their Staker contract using withdrawAllTokensToBeneficiary(). However, this function enforces a WITHDRAWAL_TIMESTAMP of 1794578400 (November 13, 2026 at 9:00:00 AM EST) as well as a minimum one time staking requirement.

function withdrawAllTokensToBeneficiary() external override onlyOperator {
    // ...
    require(block.timestamp >= WITHDRAWAL_TIMESTAMP, WithdrawalDelayNotPassed());
    require(hasStaked(), StakingNotOccurred());
    // ...
}

LATPs (< 200k tokens)

LATPs have an unlockStartTime parameter that currently prevents claims. The TGE payload will update this value to enable immediate claiming.

The TGE Mechanism

1. Registry Contract

The Registry contract controls which Staker implementations are available to ATPs. The owner of the Registry contract can register new Staker implementations:

function registerStakerImplementation(address _implementation) external onlyOwner {
    // Registers a new staker implementation version
}

2. GovernanceAcceleratedLock Contract

At deployment, ownership of the Registry was transferred to the GovernanceAcceleratedLock contract. This contract acts as a time-locked intermediary between Governance and the Registry:

contract GovernanceAcceleratedLock is Ownable {
    uint256 public constant EXTENDED_LOCK_TIME = 365 days;
    uint256 public constant SHORTER_LOCK_TIME = 90 days;
    bool public lockAccelerated = false;

    function relay(address _target, bytes calldata _data) external onlyOwner returns (bytes memory) {
        uint256 lockTime = lockAccelerated ? SHORTER_LOCK_TIME : EXTENDED_LOCK_TIME;
        require(block.timestamp >= START_TIME + lockTime, GovernanceAcceleratedLock__LockTimeNotMet());
        return Address.functionCall(_target, _data);
    }
}

  • Extended Lock: 365 days from START_TIME

  • Accelerated Lock: 90 days from START_TIME (requires governance vote)

The START_TIME is November 13, 2025 (ICO date). With acceleration, the earliest possible TGE is February 11, 2026 at 14:00 UTC.

3. Aztec Governance

The owner of GovernanceAcceleratedLock is the Aztec Governance contract. Governance can:

  • Call accelerateLock() to enable the 90-day lock period

  • Call relay() to execute functions on the Registry after the lock period

Governance lifecycle for the TGE payload

Aztec’s onchain governance defines a standard lifecycle for any protocol upgrade payload, including the eventual TGE payload.

The key stages are:

  • Payload deployment:

    • Any upgrade payload must be deployed on Ethereum L1

    • The address of this deployed payload is what sequencers will signal on and what the Governance Proposer contract will reference when creating the proposal.

    • It is advised to verify the payload contract on Etherscan, for easy review

  • Signaling by sequencers:

    • Sequencers can configure their nodes to signal support for a specific payload address when proposing blocks.

    • Once a quorum of signals is reached within a signaling round (currently 600 signals out of 1000 slots), the payload becomes eligible to be turned into an official proposal.

  • Proposal creation:

    • After quorum is reached, any address can call submitRoundWinner on the Governance Proposer contract to create the onchain proposal for the TGE payload.

    • At this point, the proposal gets a proposal ID and enters the standard governance timeline (voting delay, voting period, execution delay).

  • Voting:

    • Only eligible governance participants (e.g. existing sequencers and users who deposited funds directly into the rollup governance contract) can vote on the TGE proposal.

    • The proposal requires:

      • A minimum participation quorum of 100,000,000 $AZTEC voting.

      • A supermajority of 2/3 “yes” votes to pass.

  • Execution and TGE:

    • After the voting period ends with a successful “yes” outcome, there is a 7‑day execution delay before anyone can execute the proposal.

    • Once the delay has passed, any address can call the Governance contract to execute the proposal, which in turn calls the TGE payload.

    • Execution of this payload triggers TGE and unlocks the $AZTEC tokens purchased in the sale, making them transferable on Ethereum mainnet.

How to structure a forum post for a TGE proposal

Community members who want to champion TGE should start by opening a forum thread that clearly documents the intent and technical details of the proposal.

A suggested structure:

  1. Title

    • Example: “Proposal: Execute TGE payload to unlock $AZTEC token transfers”

  2. Summary

    • One or two sentences describing that this proposal asks governance to schedule and execute the TGE payload at a specified payload address, unlocking $AZTEC token transfers.

  3. Motivation

    • Why TGE is the natural next step for the network (e.g. enabling token holders to transfer and participate more fully in governance, bootstrapping the broader ecosystem, etc.).

    • Clarify that the TGE timing aligns with previously communicated timelines (e.g. “TGE can happen as early as February 11th, 2026” as previously communicated during the sale).

  4. Specification

    • Payload address on Ethereum mainnet.

    • Reference to the implementation:

      • Repository: AztecProtocol/ignition-contracts.

      • Contract: TGEPayload.sol.

    • High-level description of what the payload does, including:

      • Unlocking transferability of $AZTEC tokens from Token Vaults created during the sale.

      • Any additional parameters or safety checks encoded in the payload (e.g. only callable via Governance, idempotency considerations, etc.).

  5. Governance details

    • Reminder of voting parameters:

      • Eligible voters: token sale participants and genesis sequencers (as defined in the governance docs).

      • Quorum: at least 100,000,000 $AZTEC participating.

      • Threshold: 2/3 “yes” required for passage.

      • Voting duration: 7 days.

      • Execution delay: 7 days after a successful vote before execution is possible.

    • Expected effects at execution:

      • $AZTEC tokens from the token sale become fully transferable.

      • No changes are made to allocations or balances beyond removing transfer restrictions defined by the TGE logic.

  6. Security and audits

    • Link to any security reviews or audits that have covered the TGE payload and related contracts.

    • Encourage community review of TGEPayload.sol and any dependent contracts before signaling or voting.

  7. Implementation plan and timeline

    • Outline a realistic timeline, for example:

      • Sequencer signalling window to reach quorum for the payload.

      • Onchain proposal creation via submitRoundWinner.

      • Voting period (7 days).

      • Execution delay (7 days), followed by TGE execution.

    • Clarify that TGE can happen “as early as February 11th 2026, 14:00 UTC”, but ultimately depends on when the proposal is created, passes, and is executed.

  8. Open questions and feedback

    • Invite comments on:

      • The timing of TGE.

      • Any perceived risks or edge cases in the payload implementation.

      • Operational readiness of infrastructure (exchanges, staking providers, wallets, etc.) around the proposed TGE date.

How the Foundation will support this process

To support a smooth and transparent TGE governance process, the Aztec Foundation intends to:

  • Maintain up‑to‑date documentation and links for the TGE payload, including the deployed payload address and any audit reports. (this post)

  • Provide verification of the proposed payload, to ensure all stakeholders are confident of what the governance payload contract will do upon execution.

  • Coordinate with sequencers and infrastructure providers to ensure the network is ready for TGE execution and post‑TGE operations.

The Foundation will not unilaterally trigger TGE. Instead, TGE will only occur if governance participants choose to support and execute the proposal defined by this payload.

12 Likes
Proposal: Execute TGE Payload to Unlock $AZTEC Token Transfers