# Voting Power Delegation on the Staking Dashboard **URL:** \ **Category:** Governance\ **Created:** [December 19, 2025, 4:56pm UTC](https://forum.aztec.network/t/voting-power-delegation-on-the-staking-dashboard/8239 "2025-12-19T16:56:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![koenmtb1](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/koenmtb1/32/2660_2.png) [@koenmtb1](https://forum.aztec.network/u/koenmtb1)\ **Post date:** [December 19, 2025, 4:56pm UTC](https://forum.aztec.network/t/voting-power-delegation-on-the-staking-dashboard/8239/1 "2025-12-19T16:56:50Z")
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](https://europe1.discourse-cdn.com/flex013/uploads/aztec/original/2X/b/b06643b586e85c0a35fa0156e90196bab24d26ce.png) 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 - Move with latest rollup - Propose with lock - Staking with a Token Vault ### 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. ---
**Author:** ![amin](https://avatars.discourse-cdn.com/v4/letter/a/8e7dd6/32.png) [@amin](https://forum.aztec.network/u/amin)\ **Post date:** [December 22, 2025, 2:11pm UTC](https://forum.aztec.network/t/voting-power-delegation-on-the-staking-dashboard/8239/2 "2025-12-22T14:11:31Z")
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. ---
**Author:** ![niceday](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/niceday/32/2697_2.png) [@niceday](https://forum.aztec.network/u/niceday)\ **Post date:** [January 22, 2026, 12:58pm UTC](https://forum.aztec.network/t/voting-power-delegation-on-the-staking-dashboard/8239/3 "2026-01-22T12:58:20Z")
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: > [@amin](#): > > 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. 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 > [@amin](#): > > voting “No” _after_ a majority of sequencers have indicated support for a proposal can be interpreted as opposing the collective validator outcome. 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. > [@amin](#): > > 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 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 ---
**Author:** ![MrMerge](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@MrMerge](https://forum.aztec.network/u/MrMerge)\ **Post date:** [January 24, 2026, 4:53pm UTC](https://forum.aztec.network/t/voting-power-delegation-on-the-staking-dashboard/8239/4 "2026-01-24T16:53:43Z")
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…?