Voting Power Delegation on the Staking Dashboard

Governance
1

The Aztec Foundation identified an issue which prevents anyone who staked through the staking dashboard from delegating their voting power, impacting users’ ability to easily vote “no” once a vote has successfully passed the “signaling” phase.

Users’ can still vote no, but this requires unstaking first, which is not the intended behaviour.

This impacts users that use Token Vaults (also referred to as ATPs) to stake, which is all the stake currently. The issue is confined to the Token Vaults and staker implementation, not the Governance system itself.

This post details the issue, and outlines some potential solutions. We start with a refresher on the governance process for clarity and context.

Summary of Governance Process

image
image3144×209 22.2 KB

  1. Sequencer Signaling → Sequencers signal support for a Payload when proposing blocks. Anyone can deploy a Payload, and signaling can start at any time. Current parameters require 600 signals for a Payload in a round of 1000 slots. This means roughly 60% of all sequencers needs to signal support a Payload. This feature is unaffected by this bug.

  2. Proposal Creation → After a Payload receives enough signaling support in a round, anyone can submit the Payload as an official Proposal to Governance.

  3. Voting Delay (3 days) → A mandatory waiting period before voting opens to allow time for community review and for funds to be deposited/delegated in Governance.

  4. Voting Period (7 days) → Users who held funds in Governance at the end of the Voting Delay vote on the proposal. A proposal passes if at least 20% of all funds in Governance participate in the vote (called “quorum”), and 2/3 of votes cast are "yes”.

  5. Execution Delay (7 days) → After passing the vote, another mandatory delay before execution allows time for node upgrades.

  6. Execution → Anyone can execute the Proposal, which causes Governance to execute the underlying Payload. The Proposal must be executed within a 7-day grace period after the Execution Delay ends.

Background context

For this context it’s important to know about two important purposes of the AZTEC token, in addition to being the fee payment asset of Aztec:

Stake → When someone stakes $AZTEC, they can subsequently be selected to propose blocks, attest to blocks, and earn more $AZTEC in return. These funds are “at stake” in that they can be slashed if the staker does not participate in block production when called upon.

Governance Voting Power → Anyone that holds $AZTEC can vote in governance. If you stake your tokens, you automatically delegate your governance voting power to the current rollup, but you can change your delegation preferences at any time. For holders of $AZTEC who are not staking, they can lock their tokens in Governance directly to gain voting power.

Importantly, Stake is always assigned to only one rollup instance. Governance can choose to upgrade the rollup instance defined as “canonical”. If such a governance proposal passes, Stake needs to transfer to this new “canonical” rollup instance before block production can start.

To avoid block production instability caused by large amounts of stake having to exit and re-enter (potentially having to queue) at each canonical rollup contract upgrade, Stake can choose to commit to “Move with the latest rollup”. By default, all tokens staked through the Staking Dashboard made use of this feature.

  • How the Voting stage of the governance process works

    Read the Aztec Docs on how voting on proposals works

    If the sequencers successfully signal for a Payload and submits it as a Proposal, the Governance Voting Power that is delegated to the Rollup after the Voting Delay will vote “yes” on the Proposal.

  • Move with latest rollup

    “Move with Latest Rollup” is a UX feature for any person staking to not have to rejoin a staking queue when a new rollup version is deployed. The stake will automatically be migrated to the latest rollup and you can keep running your sequencer as is.

  • Propose with lock

    Anyone with 258,750,000 $AZTEC tokens (~2.5% of the total initial supply) has the ability to call Propose with Lock to skip the sequencer signaling functionality, and directly create a Proposal for a Payload. This will instantly start the 3 day Voting Delay for the Proposal, and the $AZTEC used will be withdrawn from Governance, locked for 90 days.

  • Staking with a Token Vault

    To stake from your Token Vault (also called an ATP) a staker contract is deployed for your Token Vault regardless of whether you are solo staking or using a provider. The staker is a Proxy contract, and the underlying implementation limits the actions that can be done with the $AZTEC tokens in the Token Vault, e.g. “stake in the rollup” or “delegate voting power”.

    All Token Vaults created for genesis sequencers belong to one “Registry”, and all Token Vaults created for participants in the auction belong to a different Registry. Only the owner of the Registry can add staker implementations.

    In the case of the auction Token Vaults, the owner is Governance, so Proposals can add new staker implementations; part of TGE is adding a new staker implementation to allow auction participants who have staked to exit their $AZTEC directly to the Token Vault beneficiary. For genesis sequencers, ownership of the Registry was renounced, so no new implementations can be added.

Identified issue

An issue in the staker implementation has been identified: currently, sequencers that elected to “Move with latest rollup” cannot delegate their Governance Voting Power away from the Rollup.

“Move with latest rollup” was automatically set to true when staking with the Staking Dashboard, so this applies to all sequencers. In practice, this means that the governance process is reduced to the Sequencer Signaling phase, since if a Payload receives sufficient support to become a Proposal, no one can re-delegate their voting power to vote against it.

The verified work arounds to the bug are as follows

  • If you don’t agree with a proposed governance payload, don’t signal for it.

  • Exit your stake and deposit the governance voting power and vote No. Then rejoin the queue to stake again.

  • Exit your stake and re-stake without following rollout upgrades (this requires you to restake every time there’s a rollup upgrade). This will require you to rejoin the queue.

Potential solutions

The Aztec Foundation discussed this with the Aztec Labs team who identified two separate fixes. They suggest that for auction participants, the staker implementation being added as part of TGE be patched to allow re-delegation to work as expected, with no action required. For genesis sequencers, they have devised a solution, but it requires a tweak in the rollup contract itself. Aztec Labs plans to propose an upgrade to the rollup after TGE with this fix.

5 Likes
2

Hi Koen - thanks for the thorough and thoughtful post. This is Amin from Aztec Labs - the authors of the Aztec L1 contracts and the Aztec client.

It is indeed not-ideal that genesis sequencer validators cannot delegate voting power. I’m commenting to clarify the motivations behind the moveWithLatestRollup and the rationale for the design of the Governance Staking Escrow.

Why do we need moveWithLatestRollup ?

Prior to having a GSE contract, all validators deposited stake with a specific rollup instance.

This created two major issues during governance upgrades:

  1. New rollups would start with zero stake

Currently Aztec deployments are migrations (think Uniswap v1, v2, v3 etc) and new rollups would initially have no validators, meaning no block production and no economic guarantees until stake migrated to the new rollup.

This was deemed to be operationally risky for the network and its users.

  1. Validators had to manually exit and re-enter

Validators on the old rollup had to manually migrate their stake to the new rollup, wait through exit delays, then rejoin a potentially long queue on the new rollup, interrupting validator operations, their ability to provide services to the rollup and their rewards as the old rollup may not have any reward balance remaining.

This was deemed bad UX for validators.

So instead the final design was such that validators deposit with the GSE contract and can elect to stake on the canonical Aztec rollup as indicated by the Aztec Governance (via the Registry contract) and not on any particular rollup instance.

If we look at how staking works on traditional consensus based blockchains such as Ethereum for example, the GSE is designed to mimic this. Stakers automatically start staking and producing blocks on the canonical chain, assuming they are using the latest client. They do not need to manually pick this chain everytime Ethereum hard forks. The GSE does provide the option for participants to stake to a minority chain, but this is intended to only be used in extreme situations like the Parity Fork on Ethereum.

What does it mean to stake on the canonical rollup?

When a validator opts into moveWithLatestRollup, they are explicitly agreeing to follow the rollup instance designated as canonical by Aztec Governance.

In practice this means:

  1. Validators are not opting into individual upgrades
  2. They are opting into the collective outcome of the governance process.

Since no proposal ever gets voted on unless 600/1000 validators signal support for it, any proposal that proceeds to the “voting” stage already reflects broad validator support.

Under this model, validators who choose moveWithLatestRollup are implicitly expressing alignment with the validator set’s signalling outcome.

Genesis Sequencers

The genesis sequencers are seen as a highly aligned set of Aztec stakeholders. Among their most important responsibilities is to help execute the will of the Aztec Governance which today is largely expressed through sequencer signalling.

From that perspective, voting “No” after a majority of sequencers have indicated support for a proposal can be interpreted as opposing the collective validator outcome.

That being said, genesis sequencers do retain agency:

  • They can withhold signalling support during the “signalling” phase
  • If a Payload fails to reach the threshold (600/1000), it never becomes a Proposal

Other validators (Post TGE / Auction participants)

For post-TGE validators, they don’t have Token Vaults and can immediately re-delegate voting power to any address of their choosing.

For auction participants, as Koen outlined, a staker implementation can be added to restore vote delegation functionality. To add this new staker implementation, a governance proposal is required which like all proposals must first pass the “signalling” phase. Once passed, all validators who obtained their Token Vaults via the auction would become able to explicitly vote “No” during the voting phase.

Aztec Labs is fully committed to making this new staker implementation available, now or at TGE, if there is broad support for this governance proposal.

Non-validators

Currently non-validators are able to vote No or Yes on governance proposals through the depositIntoGovernance function on the current staker implementation, which effectively delegates voting power to the beneficiary of the Token Vault.

Any token holder can deposit into Governance and explicitly vote Yes or No.

Even genesis sequencers can do this, today or anytime in the future, by:

  1. Exiting stake
  2. Depositing into the Governance contract
  3. Voting No

I realize this is costly (lost rewards + queue re-entry) but highlighting that even genesis sequencers are not blindly beholden to the will of the Aztec Governance.

Closing thoughts

While the current behaviour is not ideal, particularly for genesis sequencers, it stems from deliberate design tradeoffs made to preserve network continuity, validator UX and upgrade safety.

Aztec Labs fully agrees that delegation should work as users expect and we are prepared to build changes, as highlighted in the proposed fixes section of your post.

Thank you for driving this discussion forward.

3 Likes
3

Hi Amin, thank you for these post.
However, I think the “broad validator support” mentioned regarding the signaling phase needs to be put into perspective for the following reasons:

During the signalling phase, a single validator can signal multiple times. For example when it is elected as the proposer for multiple slots during the signalling phase.

So the 600/1000 threshold does not necessarily represent 600 unique validators, but rather 600 slots.
Now there is 2750 sequencers.

This technicality weakens the legitimacy of the signaling phase and reinforces the necessity of a distinct, fair voting phase. It’s ok we cannot do now differently due to this bug, but minimizing the voting period is not fair in my opinion

That’s not 100% true due to my point earlier. Voting “No” is a vital safeguard to ensure that the silent or less frequently elected majority can still express their disagreement.

Signaling phase is currently the only lever for Genesis Sequencers, as they cannot technically vote “No” now.

My point is simply to highlight that we shouldn’t minimize the importance of the voting phase; and I am lookink forward to see what will be the solution after the ATP ends after nov 2026. Thanks

2 Likes
4

Hi Koen

I have clearly been asleep since the token sale. I brought >200,000 token. Just went to stake some tokens on the dashboard… however every delegator seemed disabled when I tried to deposit. It said I could delegate max/min 1 token… however the deposit button was greyed out when I tried to do this. I then thought I would try and deposit into Governance, however this has pushed me below the 200,000 available tokens… The rest in the Governance Deposit.

Anyway, I assume this will all get sorted when TGE comes around. Maybe I will just have a delay in accessing my tokens…?