xGov Beta Framework, Draft Version

Hi Community,
here you can find the draft of the xGov Beta Framework, which summarizes the technical solutions that we are going to explore in this first iteration of the Beta.
xGov Beta Framework
The Framework will also be discussed in detail in our next X space on Monday, Jun 24: X Space: xGov Technical Overview
See you there!

  • Proactive: Algorand Foundation (Dedicated Funds) * The Algorand Foundation expresses an interest in particular projects through an Request For Project (RFP); * The Algorand Foundation whitelist a particular project proposal to be eligible for the dedicated funds

So it seems like the foundation completely decides which proactive proposals are fine and which are not? Am i missing something or misunderstanding it? And no mention on who checks milestones for these type of proposals?

Have you thought about elected xGov members being part of this kind of decision together with AF?


Great work on describing the future xGov program.

I would like to suggest few points:

  1. When person requests grant please allow requesting also in stable currency like EURS or USDC. For example the grant #80 was requested when the price of algo was 15 cents, during the real work the price was around 30 cents, current price is 13 cents and price next month (after 2.5 months since the request of funding) will be perhaps 8 cents because of all airdrops from the xgov program finaly reaching the market. It is very unpredictable with the price of algo to receive and calculate any type of grant, and to my knowledge you force now every proactive work to be paid only after the delivery. How should one calculate the costs for audits for example where all price is dependant on external factor?

  2. I am missing in the state chart the information when the work should be in progress and also any milestone approval. If I assume right the work should be in progress when it is “Approved”. However from the Approved state it goes to “Blocked”, so someone does due diligence at the foundation when the work is in progress? Also its quite strange that from the Blocked state it does not go to funded state… There is no chance to fix the issues?

  3. Do I understand it correctly that 249k algo proposal will require at least 15% of xGovs to vote in that voting session, and 30% of those people have to vote for the proposal in order it to pass?

Please enable delegation of the voting power so that xGovs can use their voting power in delegated manner. Not everybody wants to pay attention and have time in detail study each proposal.

  1. Who is incentivized to pay 100 algo to become xGov and not receive anything in return? Or is there some incentivization in place? I believe every person should be paid for the work he is doing, including the xGovs. If there is not going to be any incentivization only proposers will register the xGov accounts and they will pass proposals for themselfs.

  2. Who controls xGov Payor address? Is it the multisig account of the 120 OGs in the algo ecosystem? At what stage can it veto the payment? Even after the costs has been paid for the development?

  3. Is there something else the “Council” can do besides Veto? When is the time when they veto the proposal? Do they provide feedback why they veto the proposal? Is it before or after the “Vote” ? Or is the “Veto” being cast on the milestone delivery? Is there any chance to fix issues if milestone is not accepted?

  4. What is the purpose of the xGov grants? Is it only software development, or does it include the marketing of the software? How are audits considered? If person asks to cover audit costs, can he work on something else meanwhile?


Good to see that all funding is retroactive from now on. This was something fisherman.algo was proposing. Reduces complexities associated wrt signing of contracts and then monitoring and managing funds.

1 Like

This means most of the projects will be retroactive. If AF or community come across a crucial project that needs initial funding, then they will be considered as proactive.I think this is added to mitigate any edge cases that comes in future. i think 99% is going to be retroactive.


still means AF has the power to determine whats worth it and whats not although xGov should be about the community imo

at the very least there should be general discussions with the community on what would be great so devs know what is needed


I think this is just beginning. Things can change as we move forward.

1 Like

i dont care about what things could be if it would be easy enough to make sure the community is included in any way right now


I think governance team should provide a clarification regarding the same.

  1. The framework says “xGov Voting Committees selection and the assignment of their voting power is performed by the Algorand Foundation, based on the selection criteria defined by ARC-0033.” However, ARC33 seems unchanged from what we had before. Thus, it is not really clear how xGov Voting Committees are selected.

  2. I notice that for the outcome of “Blocked” wherein a proposal is vetoed by the Council, visibility is only “AF, Proposer” as opposed to “Public.” Can you explain why vetos would not be made public? This seems like it is worthy of transparency absent good cause.

  3. With respect to the “voting outcomes”, I’m still confused as to how this works. So, do “null” votes count towards getting above the thresholds of both the 1xGov/1Vote stage and the Voting Power stage? (i.e. if 10% is the threshold and 6% vote approve, 5% abstain, and 5% vote no, is the threshold met because null + approve > 10%?) Also, the final section says that the proposal must receive a “relative majority of Approved over Rejected” notwithstanding null votes. So, does that mean they must pass that threshold of both the 1xGov/1Vote stage and the Voting Power stage? If so, it’s not clear from the document.

  4. Who makes up the council that can veto? I see a section talking about future iterations, but I don’t see anything about its composition now.

  5. Am I reading this correctly that the only time a deposit is slashed is when a proposal is passed and then vetoed by the council? If so, that seems odd. Why would those get slashed but one that gets rejected (and thus never goes to the council) not get slashed? It seems like proposals most deserving of being slashed would be those that are overwhelmingly rejected (presumably because they fail to comply with the rules or because they are poorly thought out grift attempts).


I am not sure how I feel about this either. On one hand, I will totally spend 100A to do this. On the other hand, without some incentives there are probably many who will not. More than anything, though, I question whether this is actually a Sybil deterrent. If I am a whale, spending 10,000 Algo to create 100 xGov bots might be worth it if it means I can extract at least that much extra out of the system. So, I’m not sure it really stops Sybil attacks (except maybe by non-whales), but it could dissuade real users.


i may spend 100 algo on registering as expert, however all my algos are locked in defi, so i will not produce any blocks… all blocks will be created by the protocols which allows the aggregated algos accounts go to online state…

even having algos in amm protocol is not efficient as it is better to use the fAlgo earn interest from the folks deposit of algos and have it in the amm earning two interests… when fAlgo deposits will be able to earn the rewards from the staking all algos will be on their accounts and folks will have more then 50% of blocks produced perhaps at the single account

One of the solutions for this i see the open system where people who are experts can register to be governors, they reveal their identity and some good delegation system in place…

In my opinon pure liqudid knowledge based democracy is the best form of government.

Pure - person can directly participate in each voting
Liquid - Person can delegate his voting power to another accounts, even fractionaly.
Knowledge based - Delegation is categorized, wisdom tree is generated in each voting

1 Like

I brought this up at Decipher and the only way I can see it working to prevent what you describe is if the Node rewards gained are less than the fee to sign up to a be an xGov…which is prohibitive. Obviously, I am against this under the current framework. If a more effective Sybil deterrent were devised then I would be in favor of compensating xGovs (though I think it should follow a similar example to the now-expiring system and use self-funding mechanisms).

1 Like

I would very much like to see a dApp created or an existing dApp (Folks/Pact/Tinyman) allow for xGov voting pools to be established where an xGov could delegate their voting power to another xGov (in a transparent manner) while maintaining their individual node rewards.

1 Like

We’ve discussed that the best mitigation strategy is keeping the proposals criteria to retroactive only with some proof of value metrics, then if a whale makes a proposal for something that does not meets that criteria, their deposit is slashed and funds are sent to the grants pot.

Sybil is more likely to occur for proactive grants where no value is delivered upfront.