ARC-0007: Stake-Weighted Governance on Aleo

[snarkworld]

ARC: 0007

Title: Stake-Weighted Governance on Aleo
Authors: @snarkworld
Discussion: #99
Topic: Network
Status: Draft
Created: 08-18-25

---

Abstract

This ARC introduces a standardized, stake-weighted voting framework for Aleo governance. It replaces informal processes with a transparent, auditable system where votes are signed, verified against stake at a fixed snapshot, and results are publicly reproducible.

The design prioritizes simplicity and auditability today, while laying the groundwork for trustless, on-chain voting in the future.

Key Principles

• Parameters (vote window, snapshot height, thresholds) are fixed once a vote opens.
• Validators sign structured payloads signaling their vote.
• Delegators automatically follow their validator’s vote but may submit one override during the voting window.
• Final tallies are computed against stake at the snapshot block and published with all artifacts.

---

Motivation

Governance on Aleo should be secure, open, and grounded in decisions that can be independently verified. This ARC introduces a governance process that is easy to adopt now, with room to evolve into more advanced designs.

• It ensures decisions reflect real stake.
• It builds trust by being auditable by anyone.
• It provides a flexible foundation for future upgrades.

---

Specification

Proposal Lifecycle

1. Draft – GitHub Discussion or Issue to collect feedback.
2. Formalize – Submit via GitHub template with required fields.
3. Voting Phase – Validators submit signed votes; delegators may override.
4. Snapshot & Tally – Record stake, tally votes, publish artifacts.
5. Finalize – If passed, execute the action and archive artifacts.

Proposal Format

Each proposal must include:

Field	Description
proposal_id	Unique identifier
voting_window	Start and end block heights
snapshot_height	Block used to lock voting power
quorum	Minimum participation threshold
pass_threshold	Stake percentage required to pass
domain_string	Signature domain (e.g., aleo-gov-v1)

All parameters are fixed once voting begins.

Voting Model

sequenceDiagram
    participant V as Validator
    participant D as Delegator
    participant M as Maintainers

    V->>M: Submit signed vote
    D->>M: Follow validator OR override (one-time)
    M->>M: Verify eligibility & signatures
    M->>All: Publish snapshot, tallies, receipts

Loading

Roles

Role	Description
Proposers	Submit a proposal using the GitHub template.
Validators	Identified on-chain; vote off-chain by signing structured payloads.
Delegators	Stake to validators; follow validator’s vote or submit one override.
Governance Maintainers	Facilitate: review proposals, run snapshot/tally tools, publish results.

Phases

• Vote Start → Voting opens
• Vote End → Final vote deadline
• Snapshot Height → Locks voting power

Snapshot Behavior

At the snapshot height:

• All bonded validators and their delegations are recorded, only staked ALEO will count towards the vote.
• Delegators automatically inherit their validator’s vote unless they explicitly override.
• The snapshot defines final vote weights used in tallying.

flowchart LR
    %% Snapshot
    subgraph Snapshot
        S[Snapshot Block]
    end

    %% Sources
    S --> V[Validator stake]
    S --> D[Delegator stakes]

    %% Validator path
    subgraph Validator path
    direction TB
        V --> VV[Validator vote]
    end

    %% Delegator path
    subgraph Delegator path
    direction TB
        D --> DO{Override?}
        DO -->|No| VV
        DO -->|Yes| DV[Delegator choice]
    end

    %% Tally
    subgraph Tally
    direction TB
        VV --> Y[YES]
        VV --> N[NO]
        VV --> A[ABSTAIN]

        DV --> Y
        DV --> N
        DV --> A

        Y --> T[Global totals]
        N --> T
        A --> T
    end

    %% Styling
    classDef box fill:#f6f8fa,stroke:#333,stroke-width:1px,rx:6px,ry:6px;
    class S,V,D,VV,DO,DV,Y,N,A,T box;

Loading

Tallying Process

Final tallies must include:

• Total stake for YES / NO / ABSTAIN
  • Decision requires quorum to pass
• Quorum achievement requires at least 2/3 (66.667%) of network stake
• Pass/fail status
• Validator and delegator vote receipts
• Signed payloads & snapshot
• Reproducibility toolkit (CLI/script)

Results are published in canonical JSON format to GitHub.

---

Aleo Network Foundation’s Role in Governance

The Aleo Network Foundation participates in governance as any other validator, subject to the same stake-weighted rules. Its vote is guided by internal governance policies and community feedback.

This approach ensures that people who contribute to the network, even if they don’t stake, still have a meaningful way to influence outcomes through the Foundation. The ANF serves as a bridge between community input and the formal, stake-based governance system. Its participation makes the process inclusive while keeping everything transparent and auditable.

By folding ANF’s voting power into this model, we keep things aligned with stake-weighted governance while honoring the values and input of the wider Aleo community.

Dependencies

For this ARC to work smoothly, a few things need to be in place:

• Validator info at snapshot time – We need a clear record of validator and delegator stake at the snapshot block height.
• Key infrastructure – Validators should be able to sign structured messages with their validator keys.
• Basic tooling – A lightweight CLI or script is needed to take snapshots, check signatures, and tally results.
• GitHub setup – GitHub Discussions and the ARC template will serve as the official home for proposals and records.
• Voting platform – A place to surface the vote and manage participation (e.g., a simple web interface or dashboard).

Backwards Compatibility

This proposal does not change anything at the protocol level.

Final Remarks

This ARC defines a clear and auditable governance process that can be built on going forward.

Potential future iterations may:

• Move vote collection fully on-chain
• Use zero-knowledge proofs for tally integrity
• Enable auto-triggering of protocol changes
• Introduce encrypted voting with delayed reveal

All upgrades can be layered without disrupting current design.

This ARC introduces the foundation for validator and delegator responsibilities, defines the timing and mechanics of voting, and sets requirements for publishing key artifacts (including signatures, snapshots, and tallies). Proposals that reach consensus become enforceable outcomes on Aleo under this governance framework.

[AleoAlexander]

Shouldn't miners/provers be added as well, considering they are also required to stake now?

[snarkworld]

Provers/miners would be delegators in this case.

[vicsn]

I understand that they may be delegators, or they may simply be independent non-delegating users.

Or is voting only possible with accounts who have tokens staked during the voting window? If yes, does this proposal require the tokens to be staked during the entire voting window to be valid?

Regardless, it's worth clarifying in the text above, given the significance of miners in the ecosystem and their interest in the matter!

[snarkworld]

Yeah, good clarification. For the record, only staked ALEO will count towards the weighted vote. I've updated to reflect this distinction in the proposal.

[raychu86]

How should voting be done for this particular ARC?

[snarkworld]

This proposal will move to a community vote on August 20th at vote.aleo.org, using the existing governance framework. If approved, it will be implemented, and the site will be updated with a dedicated web interface and dashboard reflecting the framework defined in this ARC.

[MarioMoreschini1992]

Hello, guys you arer again missing a very important point. you do not see the overall numbers (strange). let me remind you: Validators are 33 and owns 1.3 BIL ALEO staked, miners are just now staking BUT our production its around 120 mil. per year, now we are forced to stake 60/70% of our production, it means in a year time we may reach 120 mil staked (!!!!) that is 10 % of all validators staked ALEO.
the first 5/6 validators togheter already own >51% voting power.
this is an Oligarchy. You should change the ARC to allow Validators to vote with a 1/100 factor at least.
Can we please start doing things right? i never see in any ARC that i was able to analyze a simple mathematical check. or please tell me that i am wrong and that Coinbase 1/2/3 alone cannot decide wich ARC will go in effect and which not. thanks

[MarioMoreschini1992]

Hello, thanks - picture its a bit different, i mentioned Coinbase to make the point. if you sum up the first 10 validators, then you have 69% of voting powers. this control the overall Aleo development, this is simple not correct and i will make clear why:

1. delegators sum up their staken token with validators node, as i already explain - and this is pure math - the yearly production of all miners combined its 120 mil. aleo, out of that we may assume 60 mil will be staked over a year - out of 1.3 bil its 5% more or less. We have NO voting power and we ll never have
2. some ARC may impact validators business model, other ARCC impact just technical moment (development language, upgrade and so on), other ARC impact provers./miners - EACH ARC should be classified for its impact and allocated for vote to the stakeholders this impact to.
   to make an example that is near to our heart and mind, the ARC 46 impacted only (in negative) miners business model - it was voted by validators and other subjet with voting powers, NOT by any of miners BUT, even if we have voted we ll have got 1-2% of voting powers.
   So the ARC generated a price increase (good for validators) and a lock in for miners (decreasing our profitability and looked in for 2 years time with no understand of whats going in the future) - who should have vote this and with which voting power ratio?
   To make a corresponding example, its like we miners promote an ARC that will decrease Validators rewards from 10% to 1% and increase rewards for provers. and we ll vote only Provers and we ll exclude Validators from this. How it sound?
   So, to avoid it:

• ARC should be classified for their impact on different stakeholders
• based on the impact of the ARC a matrix ratio will be defined to make voting power equally right and that should make sense for everybody respecting the business model of each of us (ARC 46 should have been voted by provers and NOT by validators for example or with a diluting ratio of 100).
• another example, i just came by the ARC43 proposal, its clearly affect Provers mainly, who should be voting it when and if it will go in approval stage?
  its quite simple.
  thanks

[snarkworld]

You can’t cleanly silo “who’s impacted.” Most ARCs have cross-effects (economics, security, UX). Splitting franchises decouples governance from the stake that secures the network and creates veto games. Proof-of-Stake aligns rights with risk: more skin in the game → more say.

Delegators—not validators—own the vote. Validators surface a default, but any delegator can override and vote directly. “Top 10 validators = 69% control” only holds if every underlying delegator blindly follows. They don’t, and they’re not forced to.

Calling out Coinbase missed the point and the math. A coordinated 66.7% of stake (not “top validators”) is what moves proposals.

[MarioMoreschini1992]

Thanks, seems i fail to make the point. let me try again
Validators-Delegators and provers have 2 different business model.

• Validators and Delegators earn on staking, so their interest is: long term value increase and possibility to unstack and liquidate their Aleo when its possible or at least part of it, secure network and transaction, have the rewards from staking not fall vertically
• Provers earn rewards on mining, so their interest is to have more rewards for each $ invested in term of value generated by Aleo, then sell or stake its at discretion of Provers, secure network and transaction, have the rewards from mining not fall vertically
  I hope on this we can agree.
  Now, and this is simple calculation, in the option you have mentioned about Delegators, let s make the Worst assumption that all the provers staking are delegate to Validators:
  Provers account over one year on less then 5% of the total validators, it means that even if all Provers (means each of us having 5000 Aleo staked) will vote to override "our"validator vote, we can move only 5% of the Vote at the current algorithm that is implemented (and this will happen in 1 year time - as of today i guess we are at 1/2%
  i hope on this we can agree. If you think i am wrong, please justify with numbers.
  So, even in the worst case, the Oligarchy of Validators will always decide wich ARC to promote and which not - 10/15 validators or mixx of them does not really matter - their interest coincide becasue their business model its the same
  During the discussion on ARC46 (discussion 97 and 98) it was clearly stated from Aleo team (@vicsn ) that - yes the voting mechanism has to be review because allocated to Validators too much power. please check related discussion.
  About your point of ARC that cannot be classified, i am not with you at all and the perfect example its ARC46
• the goal its to improve the ecosystem - this is valid for each ARC
• how you reach the goal? ARC46 obliged the Provers and only the provers to stake up to 60/70% (and i am afraid up to 90%) of their rewards for 2 years time. Validators are obliged? NO - even if at that time all the provers togheter has voted no, we had reach at best 1% of the voting power. but arc was approved with 43 unique vote "i am for", none of the were from Provers i assure you. but the ARC put only on Provers the ownership of the cost to implement it. so your assumption that we cannot make silo for me its wrong.
• if you do not agree with me, please comment on the specific example and make the point why ARC46 affect validators.
  We can make example of other ARC that effect only validators or ARC 43 that if i do understand correctly may impact our current hardware and make it obsolete, this impact only provers. and there will be arc that are cross everybody.
  then if we want to have a voting mechanism then it has to make sense to all the stakeholders. When you vote if you want to build a new park in a city, you do not make this vote at national level - u make it at city level.
  if you want to change the tax rate, you make it at national level because it impact everybody.
  your position about more skin in the game → more say its simple wrong because impact different business model and different stakeholders, ALL top validators are company so they have the money and resources to stake millions of Aleo, you want each of us to invest 100k USD in aleo staking just to have a voting power in ARC discussion? this is not serious - go to each Validators name and company as i did and look to their portfolio - Aleo Stake its minimal part of it - expect probably for Aleo Foundation but i also assume they got it for free, these companies have multimilion investment.
  i am open to your critics when supported - and let me add also a point, why make a Github open discussion if we are always wrong? lets put aside all this politically correct.
  If we have this GitHub discussion is to challenge ARC then this as to be a real challenge. not a pro forma Q/A where nothing change. if so what is the sense at all to put ARC out for discussion to all?
  ARC46 was again a perfect example, i think as group of Provers we had argument solid and convincing and we had a lot of push to at least make some improvement in the voting mechanism and in review the ARC limit. What we got from Aleo team at this stage is opening a mining channel in discord and Vic (the only one) trying to answer some of our concern. thats it.
  How we can build a bright project if you do not have the Provers community backing u up i really do not understand....

[MarioMoreschini1992]

#98 (reply in thread)

[MarioMoreschini1992]

I hereby want to congratulate for approving another ARC that it make sense only among Validators and Foundation with an impressive 43 unique voter! of which 32 validators! . No answer to any logical critics, not number evidence, just silence. Your ARC could have been a good way to re-structure the vote logic and give order in an Oligarchy, that just keep being an Oligarchy. Any open discussion in Github its a just a lost of time to type on the keyboard and a showoff for all of Aleo team that has to go true a politically correct discussion in which u do NOT accept any challenge - i do understand our cultural difference in term of facing critics and logic discussion - but this is an absurd., all of you are absolutely not interested in other opinion of all the stakeholders out there. And even do not start that Delegators override Validators. i already made the numbers clear and i assume you agree - if not u ll have bring on the table convincing argument to demonstrate the opposite. You guys are a full delusion. Invite all that came across every discussion to think 10 times before even getting involved into mining as unfortunately we have done.

[evanmarshall]

This seems like a pretty standard proposal and in general I support it. One thing we should think about though is for ambassadors and other people who have perhaps maybe a smaller economic interest than some of the validators and delegators but have been important to shape the network as it exists today. How can we make sure that that their voices are still heard and that they're still actively participating in the governance process?

[snarkworld]

Thanks, Evan. I agree, ambassadors and others with smaller economic stakes should absolutely be considered. In alignment with this ARC, the Foundation will host a community and ecosystem vote to help guide how it casts its validator vote. This ensures that even those who are not delegating still have a voice, with participation facilitated through Discord and other community channels.