This AI-generated summary covers xGov Council meetings, which are unofficial and independently organized by the council. It offers a transparent view of their work and initiatives of xGov council to enhance the xGov program. These notes are provided as-is, and it’s understood that some topics may not be fully clear without prior context.
xGov Council Meeting – (18 March 2026) 
Attendees: xGov Council members
Overview
This was a council-only session held on 18 March 2026. The Algorand Foundation was not in attendance, as their scheduled all-hands meeting was brought forward, resulting in AF representatives cancelling. The council proceeded independently and covered several standing topics: the voting behaviour of a major delegated stake holder (“Folks”), a formal proposal for node-based funding of the xGov treasury, governance housekeeping around council members voting on their own proposals, and a review of how xGov voter eligibility and committee mechanics currently operate. All discussions were exploratory; no formal votes or binding decisions were taken.
Key Topics Discussed
1. Folks Finance Voting Behaviour and Delegation Concerns
The council discussed the implications of a large delegated stake holder casting votes across all proposals without apparent differentiation, and what this means for the integrity of the xGov process.
Key points discussed:
- Evidence suggests the entity voted yes on all proposals in the recent session, rather than following council guidance or abstaining on borderline cases.
- Concern was raised that if a single entity with majority voting power votes uniformly, the xGov process effectively becomes unilateral rather than community-driven — particularly for smaller proposals that only need a basic attendance quorum.
- One perspective was that, given proof-of-stake principles, large holders are entitled to vote as they see fit — and that the better solution is improving transparency from that entity’s side.
- Options discussed to rebalance voting power included: the entity sub-delegating votes to individual accounts or community representatives; a Galgo-style aggregation model; or introducing a counterbalancing whale via a foundation-operated node whose votes are separately delegated.
- The node rewards proposal (discussed below) was floated as a potential vehicle for introducing such a counterbalancing stake.
- The council noted it lacked clarity on how this entity intends to vote going forward, as AF was not present to provide context. This topic was flagged as requiring a foundation conversation.
2. Node Rewards as a Funding Mechanism for the xGov Treasury
The council discussed a proposal to request that the Algorand Foundation lock a quantity of Algo in a dedicated node, with staking rewards flowing directly into the xGov treasury — providing a degree of self-sustainability over time.
Key points discussed:
- The foundation has asked the council to submit a formal written proposal for this node model. A top-up of the existing treasury (discussed in the range of 2–3 million Algo) is also being considered separately and should proceed regardless.
- Several sizing approaches were discussed. One view framed the need in headcount terms: approximately 25 builders at ~$50k USD annually each would require around $1.25 million USD per year. Another approach referenced a 65–100 million Algo node, which at ~5% APY would yield roughly $250k–$500k USD annually at current prices.
- A conditional, capped top-up model was proposed: the foundation would commit to topping up the treasury to a defined minimum (e.g. 1–1.2 million Algo) on a monthly basis only when the balance falls below a threshold (e.g. 500k Algo). This avoids the foundation carrying a fixed recurring liability on its books.
- 100 million Algo was suggested as an opening negotiating position for the node size, with 50 million as a minimum landing zone.
- A comparison was made to the Chess.com node agreement (reportedly ~700k USD / year in rewards), raising the question of whether xGov builder funding should be at least comparable in scale.
- A concern was raised about community perception: adding a large node to the stake pool would dilute individual node operator rewards. The council agreed this should be surfaced as a consideration in any formal proposal.
- The longer-term vision is for node rewards to eventually replace direct foundation top-ups; in the near term they would supplement them.
3. Treasury Sizing: Proposal Volume vs. Available Budget
A broader question was raised about whether the xGov treasury should always exceed likely proposal demand, or whether constrained funding creates healthy competition between proposals.
Key points discussed:
- One view favoured keeping funding lean enough that only the strongest proposals win budget — creating a competitive selection dynamic.
- A counterpoint was that if budget is too low, legitimate proposals could be crowded out with no clear basis for preferring one over another.
- The council noted that with a cap of ~1–1.2 million Algo in the treasury at any time, two or three well-sized proposals per session could be funded without strain — which was considered acceptable.
- The broader question of whether xGov’s scope should expand (e.g. to fund protocol development or elect working-group contributors) was raised but not resolved.
4. Council Members Voting on Their Own Proposals
The council discussed whether members who have submitted active xGov proposals should abstain from the final council confirmation vote on those proposals.
Key points discussed:
- A proposal was made to formalise this as a written rule or at minimum an agreed norm: council members should disclose when their submitted proposals are tied to their council membership, and should abstain from the final confirmation step.
- It was noted that, given the council currently has 11 members, the absence of even one or two voters meaningfully changes the threshold required to pass — which complicates strict abstention rules.
- An option to include an explicit ‘abstain’ mechanism in the smart contract was discussed, so that abstentions can be formally recorded rather than requiring absence.
- The concern about conflicts of interest also extended to public commentary on proposals: members noted that expressing opinions on proposals in the forum can invite retaliatory negative votes against their own submissions. This creates a chilling effect on council engagement.
- One view was that insulating council members from needing xGov income (by compensating them separately) would allow more candid participation in proposal discussions.
- No formal rule was adopted; the council leaned toward a lightweight written agreement rather than a hard governance requirement.
5. xGov Committee Mechanics and Voter Eligibility
The council examined how the current smart contract handles xGov voter eligibility across overlapping committee periods — particularly the effect of the absentee purge on active proposals.
Key points discussed:
- Once a committee is defined, its membership is fixed for the proposals created within that period. If a voter is subsequently purged (for missing five consecutive proposal votes), they can technically still contribute to quorum counts but cannot vote unless they re-register and pay the 100 Algo fee again.
- The five-missed-vote purge threshold was described as potentially punishing in cycles with a high volume of smaller proposals — a participant could be ejected after missing just one two-week window.
- The council noted this is a meaningful design flaw if xGov moves toward higher proposal frequency. A suggestion was made that the eligibility rule should be based on activity within the committee period overall, rather than consecutive individual votes.
- The recent absentee fix was credited with improving passage rates. The recent session saw a notable uptick in voter participation.
- Batch or scheduled voting windows were suggested as a way to make participation more predictable and reduce the risk of accidental purges.
6. Council Engagement with Proposers and Proposal Quality
The council discussed whether it should take a more active advisory role in guiding proposers to better calibrate the scope and budget of their submissions.
Key points discussed:
- A view was expressed that the council could do more to help proposers understand what constitutes a well-proportioned ask — not as a gatekeeping function, but as informal guidance to improve success rates.
- A concrete example was cited: a proposer whose first submission was rejected revised the scope and budget, resubmitted, and was approved — demonstrating the value of direct engagement.
- Concern was raised that if the council’s note on proposals became more opinionated rather than neutral, it would concentrate decision-making power in the council — undermining the broader xGov ethos.
- The blowback risk of public commentary was acknowledged: members who voice critical opinions can attract retaliatory no-votes against their own proposals. This structural tension was seen as unresolved.
7. Specific Proposals Under Discussion
The council briefly exchanged views on two proposals currently in the voting period. No formal council position was established; the discussion was purely deliberative.
Key points discussed:
- Concerns were raised about proposal quality — notably AI-generated documentation that was considered insufficient. The underlying product was not disputed.
- A second proposal was more divisive. Some members voted yes on the basis that the ecosystem needs as many builders as possible. Others voted no or abstained due to code quality concerns (one member noted an independent analysis flagged significant issues), a partly proactive rather than retroactive framing, and a high ask relative to demonstrable traction.
- The broader question was raised: if a major delegated stake holder votes yes on such proposals regardless of the council note, the council’s role in shaping outcomes becomes limited. This circled back to the Folks voting behaviour discussion.
- A view was expressed that the council should not reject a proposal that has legitimately passed the xGov vote solely on TNC grounds, as this would effectively slash a proposer’s funds after community approval — which was considered a serious action requiring a clear threshold.
Outcomes and Next Steps
- The council agreed to schedule a joint call with the Algorand Foundation the following week to progress the Folks voting behaviour question and the formal node funding proposal.
- The council will prepare a written formal request to the Foundation for a node-based xGov treasury funding mechanism, specifying a target Algo stake amount (100 million Algo was discussed as an opening position) and framing it as a conditional, capped top-up model.
- The separate treasury top-up (in the range of 2–3 million Algo) should be progressed independently and in parallel.
- The question of abstention rules for council members voting on their own proposals will be carried forward to the next meeting, with a view to agreeing a lightweight written norm.
- The council will monitor participation levels and voting behaviour in the current session to gather data on the absentee mechanics issue before proposing changes.
- Proposal quality and council advisory engagement will continue as an ongoing discussion topic; no structural change was agreed at this stage.
Note: Several agenda items were prepared in coordination with Algorand Foundation staff for a joint call that was postponed. Those items — including council election vote design and formal discussion of the Folks delegation question — will carry over to the rescheduled joint session in a weeks time.