GP13 Governance Measures

Hi everyone, we would like to share the drafted governance period 13 measures with you for feedback.

The measures preamble summarizes our thinking about how to evolve post-rewards governance, and the three measures pose questions about creating a democratically chosen xGov council, as well as councilor and voter eligibility.

The governance portal will be updated about a week before the voting session opens.


The Future of Algorand Governance

As we prepare to introduce staking rewards and transition away from incentivized governance this quarter, it is time to consider the evolution of community decision-making.

Community governance is an important part of any decentralized blockchain ecosystem, and we see the sunset of governance rewards as an opportunity to improve governance as a whole.

Throughout the governance rewards program, governors voted to direct available funds to specifically targeted programs, such as DeFi rewards, Targeted DeFi rewards, and NFT rewards. This allowed our ecosystem to experiment with different reward mechanisms, encouraging collaboration and healthy competition. Governors also voted to direct rewards to the xGov pilot program, funding over 4M Algo of xGov approved community grants.

2025 and beyond

Node runners and xGovernors will become the core enfranchised groups within the Algorand community, responsible for determining the fate of potential protocol changes as well as increasingly broad operational and economic matters. This raises the question of what happens to “general governance,” where any Algo holder can vote.

We posit that general governance should be retained but, in the future, would function as national referendums do: ad hoc and reserved for matters that (a) broadly impact all Algo holders and (b) are not better resolved by node runners or the xGov decision-making processes. Changing the minimum staking threshold from 30K Algo to some other value may be a good example of something the community should ratify via general governance.

Next year, we will also implement the ability for the community to make protocol improvement proposals via the xGov platform, where xGovs will evaluate these proposals’ feasibility and upvote them for a general governance vote when appropriate. This mechanism will be introduced in a subsequent update after the new platform’s mainnet launch.

As voted in GP12, the new platform will launch with new eligibility criteria for the xGovs based on consensus participation. Every address that proposed a block during a predetermined monitoring period is eligible to be an xGov and will become an xGov, provided it signals its willingness to participate in the new xGov platform. The initial eligibility process is described here, and we will release further details of this methodology in the coming weeks.

Only addresses directly staking and participating in consensus are eligible. Therefore, addresses holding Algo deposited for Liquid Staking could become xGovs, and—similar to how liquid governance functions today—it would be up to participants in such arrangements to determine how voting power is allocated.

The measures below address open issues within the xGov framework as development work continues.

Measure 1 - Establishing the xGov council

While the Beta Version of the xGov grants funding framework represents a substantial step forward along our responsible decentralization path, several process stages remain manual and reliant on the Algorand Foundation’s involvement.

We believe that an xGov council, elected by the community, could help decrease the Foundation’s influence over time. Moreover, its intrinsic agility will increase the subjective quality and effectiveness of xGov decision-making and operations, filtering out proposals that do not meet the program’s eligibility criteria at inception. The discussions will be public, and the council members will be publicly accountable for the decisions.

You can read more about the proposed council framework in this document, but here’s a summary:

  • Community members with technical backgrounds and strong reputations can run for the council;
  • Council members are elected for a fixed term;
  • Council members perform required tasks during their terms.

The Algorand Foundation believes that electing representatives will be the right step in forming this council. If this measure passes, an ARC [Algorand Request for Comments] will be created to drive the discussions around the council qualification criteria, selection process, task management, length of term, and accountability criteria.

Measure 1: Should the xGov council be established?

A. Yes
B. No

Measure 2 - xGov Council Member Eligibility

Measure 1 in GP12 voted overwhelmingly that the new xGovs cohort should be composed of block producers.

Looking at the whole ecosystem, we must consider whether any community member who meets the experience criteria should be eligible to run for council and whether or not they are directly participating in consensus(1). A broader candidate base could help maintain openness by introducing perspectives outside the xGov domain.

(1) that a person who holds Liquid Staking Tokens may participate in xGov democracy indirectly (depending on the structure of the LST) but would not themselves be eligible to become an xGov. Option A therefore allows the possibility of a person who is not an xGov being a member of the xGov council.

Measure 2: Who should be eligible to be a council election candidate?

A. Any Algo holder with the required experience
B. xGovs only

Measure 3 - xGov Council Member Eligibility

The xGov council, if approved by the Community in Measure 1, will play a crucial role in xGov functioning and an important role in the Algorand ecosystem overall. It is, therefore, reasonable to ask whether the pool of those who vote on the composition of the council should be broad-based or restricted to xGovs. In the latter case, the natural choice could be represented by the governors participating in the new, rewards-free version of the general governance.

Measure 3: Who should be eligible to vote in the election of xGov council members?

A. Any Algo holder
B. xGovs only

2 Likes

@adri How can I vote in GP13, if I am now taking part in https://app.folks.finance/algo-liquid-governance?

1 Like

If 2(B) is chosen, who determines that eligibility criteria is met?

3 Likes

Great updates! I have a question on this part -

When you participate in a pooling solution (like Reti Pooling) the account that is actually participating is a contract account. The xGov voting power will need to be given to the owner of the pool - not the pool contract itself. I hope this can be accommodated so that Reti validators are able to participate in xGov.

2 Likes

DeFi platforms will likely offer different options, as it’s up to each platform to determine how/if they’ll implement it. We are sharing integration specs with them today.

TBD, pending ARC discussions if measures are approved.

Yes, pools will be able to set a voting address.

2 Likes

Agree with this 100%. It is important that we have a mechanism for pooling options like Reti to participate as xGov to counteract the potential for dominance by a few LST providers.

3 Likes

100%! I’m also keen to see options like Reti flourish.

1 Like

Thank you! Looking forward to seeing this new structure take shape.

1 Like

How will this voting address be set? If it must come from the block proposing addresses it means it must be part of the pool/LST contract.
These contracts are already live or in late stages of audit and should be non-upgradable. So is there some offchain way of identifying the owner of the pools to set the voting address?

1 Like

I had discussions w/ xgov people about this many months ago and at Decipher - and made it very clear that staking contracts can NOT be the ones pushing transactions for xgov. I was told this was well understood.
Reti has already been through an Audit and is immutable. It hasn’t been deployed to mainnet yet and could obviously be changed prior to that, but I don’t think changes should be made either way. XGov is an off-chain/on-chain solution already, and governance/xgov have both changed numerous times. This about-face on staking contract membership is a perfect example.

Staking contracts for consensus should be 100% immutable - they do not lend themselves to ‘send arbitrary transactions to an xgov contract that… will likely change in the future’

Reti however does intentionally have very clear, completely immutable, on-chain state that links proposal accounts to their single (validator) owner. All the data is there for xgov mechanisms to use to determine who owns the proposals for all of the pools of a given validator.

3 Likes

I strongly second what patrick is saying here.

2 Likes

We’re getting off-topic; this thread is about feedback for GP13 measures. Feel free to open a thread to discuss the xGov integration.

Apologies if the question was off topic, but this thread was the very first time I saw xGov being mentioned in the context of LSTs and these questions are very much related to the wording of the measures. In my opinion the measure should not mention LST if there is no possibility that LST holders would be able to participate in governance. I ask the question on the technical details of determining the eligibility and the voting address to understand if this is a possibility or not.

For reference, I am leading the work on Tinyman’s LST solution, which is due to go to mainnet next week.

3 Likes

I hear ya, Fergal, Cosimo is leading the tech discussion on Discord

My only concern with Measure 3 A is how easily the system can be gamed and that there should be guardrails (*) around it.

Thanks, @centrips; I’m interested in your views on how it could be gamed, if you’d like to share them.

The main issue I have with this is the ability to whitelist and blacklist projects from grants. I think it is really important that the all projects have the ability to apply for grants and be voted on by the community. That is the only way to allow, support, and encourage innovation and development. There needs to be open competition on production of deliverables and price points to stimulate opportunity on the network.

It’s not blacklisting, as the council’s job (and before the council the Foundation’s job) will be to verify that the proposal meets the program’s criteria. The proposal is rejected only if it doesn’t meet the criteria, that will avoid wasting xGovs and the community’s time. If the proposal meets the criteria, it will progress to the discussion and voting phase.