xGov Council Meeting #9 (January 7th, 2026)

*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 – January 7th, 2026

Date: January 7, 2026
Time: 4:00 PM UTC
Meeting Type: Regular xGov Council Meeting
Attendees: xGov Council members


Overview

The council discussed the current state of active xGov proposals, focusing primarily on proposal funding amounts, governance mechanics, and structural limitations of the existing xGov platform. A major theme of the meeting was concern over the increasing trend of proposals requesting the maximum allowable funding, and the lack of mechanisms to express nuanced support (e.g., “support, but for a lower amount”).


Key Topics Discussed

1. Status of Active Proposals and Preliminary Voting

  • Members reviewed early, informal voting results on currently active and upcoming proposals.

  • Feedback indicated mixed support, with many proposals receiving abstentions or “no” votes rather than strong approval.

  • Several proposals were viewed as valuable in principle, but overpriced relative to scope, impact, or current ecosystem conditions.

  • A recurring issue identified was that some proposals lacked:

    • Clear open-source repositories
    • Evidence of active maintenance
    • Demonstrated current (not historical) usage or impact

2. Proposal Amount Inflation (“Max Amount Trend”)

  • Council members expressed concern that many proposers default to requesting near-maximum funding amounts, regardless of actual scope.

  • This trend was seen as:

    • Creating poor incentives
    • Reducing credibility of the ecosystem externally
    • Making it harder for voters to assess value
  • It was noted that many voters rely on reputation rather than technical depth, making inflated requests more likely to pass unless corrected.


3. Limitations of the Current Voting Model

  • The current yes/no voting structure does not allow the council or xGov voters to express:

    • Partial support
    • Support at a lower funding level
  • This creates a binary outcome where proposals either:

    • Pass at full requested amount, or
    • Fail entirely, even if they provide meaningful value

4. Ideas for Improving Funding Evaluation (Exploratory)

Several conceptual approaches were discussed (no final decision reached):

  • Value-based voting models, where participants allocate a budget across proposals instead of voting yes/no.
  • Median-based funding outcomes, reducing the impact of outlier votes.
  • Council-issued funding guidance, published during the discussion phase to help voters and proposers calibrate expectations.
  • Optional advisory tools (e.g., calculators or frameworks) to encourage more rational funding requests.
  • Strong consensus that historical value alone should not justify funding without a clear plan for ongoing maintenance and impact.

The group emphasized the need to carefully consider game-theory risks, including:

  • Manipulation of metrics
  • Concentration of power
  • Perception of favoritism or corruption

5. Role and Power of the xGov Council

  • Members debated how much influence the council should have over funding amounts.

  • While increased council involvement was seen as beneficial given the technical expertise present, there were concerns about:

    • Over-centralization
    • Long-term governance risks
  • General agreement that transparency, documented rationale, and clear processes are essential to mitigate these risks.


6. Open-Sourcing the xGov Platform (Critical Issue)

  • The council reiterated that the xGov platform UI remains closed-source, despite prior commitments from the Algorand Foundation to open-source it.

  • Strong consensus that lack of open-source access to the xGov front-end and tooling is a major blocker.

  • The inability to:

    • Fix UI issues
    • Improve voting mechanics
    • Implement council recommendations quickly
      was described as significantly limiting council effectiveness.
  • The council noted that many of the issues discussed—such as abstention, funding calibration, and proposal evaluation—could be significantly mitigated through UI-level changes without requiring smart contract modifications.

  • Members emphasized that modern development practices allow rapid iteration, and that continued delays are unacceptable.


7. Expected Abstention Risk

  • The council noted that abstention is likely to remain a significant issue in upcoming votes.

  • Members reiterated that this concern has been raised multiple times with the Algorand Foundation, but no structural or UX changes have been implemented to address it.

  • The council emphasized that without meaningful intervention, abstention will continue to dilute signal quality and undermine the effectiveness of the xGov process.


8. Engagement with the Algorand Foundation

  • The council agreed that direct engagement with the Foundation is urgently needed, particularly regarding:

    • Open-sourcing the xGov front-end
    • Voting mechanics
    • Proposal lifecycle improvements
  • A meeting with the Foundation is planned for the next council cycle (Jan 21st), with open-sourcing UI and abstention risk identified as a priority agenda items.


Key Takeaways

  • There is broad agreement that the current xGov process lacks sufficient nuance for funding decisions.
  • The trend toward maximum funding requests is harmful and needs structural correction.
  • The council wants to play a more effective role but is constrained by tooling and governance design.
  • Open-sourcing the xGov platform is seen as the most immediate and impactful step forward.

Action Items

  • Engage with the Algorand Foundation to follow up on the previously stated commitment to open-source the xGov platform UI, with a focus on enabling faster iteration and community contributions.
  • Request concrete next steps and timelines from the Foundation regarding the UI open-sourcing effort.
  • Formally document council concerns around proposal amount inflation, abstention rates, and lack of nuanced voting mechanisms, and present them to the Foundation as part of the next coordination meeting.
  • Continue internal council discussion on alternative funding evaluation and signaling models that could better reflect partial support or value-based assessment.
  • Encourage proposers to provide clearer evidence of current impact, active maintenance plans, and realistic funding requirements during the discussion phase.
  • Monitor abstention levels in upcoming votes and assess their impact on proposal outcomes, given that no structural mitigations are currently in place.
2 Likes

very good session

Actually id does. For example in my proposal there was time like 2 or 3 weeks before the proposal went to vote. However MJ stated that he believes I should request 100k algo instead of 200k algo only after like week it was already in the vote. I understand that he might be on vacation, but I do not understand the 4 no votes for my proposal with noone other then MJ stated anything against it. I believe that developer support is the main thing the AF should fund and they made this retroactive grants to at least fund us same free work we do here that have and may have some impact, but without real discussion I am quite frustrated from this process. However i would like to thank to all xGov council members who voted yes for my proposal.

I though the maximum was 300k.. I went with 200k because the other proposal already requested 200k and I believed that .net sdk has higher impact then java implementation of falcon and i spent more time on it then they did i believe.

Why dont you state it clear that Folks has now 86% of all xGov voting power and they vote for their proposals and whatever xGov council approves? And then the reti pool owners has next 6%. Folks even voted with my algos in their protocol against my proposal which I dont like quite a lot.. Even thou xGov council voted only with 4 people out of 11 against.

Why is there btw delay between the xGov council vote and general voters vote? If every voter should act on the same information the xGov council should vote before them.

Also I did not notice any mention that the “No” vote can be currently expressed by not voting, and “No” and “Abstain”.. What are the plans to engage more people to vote or fix the requirement that x accounts has to vote even if majority of the xGovs does not vote?

The current model one anonymous Account per vote is quite strange.. Big players can split the algos to thousands of accounts and then folks might have the monopoly on stake level and account based level.

Thanks @scholtz for the thoughtful breakdown and for keeping the conversation constructive. It’s valuable to hear the proposer’s side directly.

The low engagement in discussion phase was likely to holiday timing playing a big role. Many xGovs (including some very large ones) simply didn’t engage deeply, and the 200k ALGO vote became a kind of “default safe” choice for most proposers, perceived as passable. A lot of people probably didn’t even register that the max was 300k - this was the point of max ask remark, not so much your ask in particular. That dynamic definitely amplified the outcome more than the actual perceived value of the .NET SDK work itself.

For the second part of the “council note” - Each of us on council does vote based on our independent assessment, sometimes it’s metrics, sometimes gut feel about impact/execution risk/timing, sometimes just “does this move the needle for Algorand right now?”. Yes, it’s subjective and can feel inconsistent from the outside, but that’s the tradeoff for having 11 different experienced voices instead of a single oracle or fully gameable formula as we’ve seen in the past. The system bets on the diversity of perspectives producing a reasonable signal overall.

We actually did mention in the meeting that roughly ~85% of the final voting power is in the hands of folks, but the summary omitted this in place of more generalized wording. It’s not ideal scenario, and we’re all aware of it. On the other hand if you don’t like folks voting with your algos you might wish to consider using reti pool with owner more aligned with your views (shameless plug for cosmic champs reti pool here: Réti Pooling). But i can understand why stacking folks points is better yield atm.

On the abstention front: the council has been (and will continue to be) very vocal with the Algorand Foundation about cleaning up inactive/never-voted wallets before the next committee rotation. That single change should meaningfully improve quorum reliability and make the voting power distribution less noisy. It won’t magically solve whale concentration, but it removes a big chunk of dead weight.

I won’t pretend council members don’t form opinions about whether something feels “appropriately scoped” for the requested amount. When multiple of us think the valuation is on the high side (for whatever reasons, e.g. ROI, competition with other priorities, etc.), it naturally shows in the notes and votes. That said, the ask amount is 100% your call as proposer. If you decide to re-submit after the inactivity cleanup (which I also think will make things more predictable), dialing it back a bit could help build wider support without undermining the project’s importance. But that’s just pragmatic advice, not a directive, the value judgment remains yours and xgovs are voting on it.

About the .NET SDK I personally see real long-term upside there too especially for onboarding enterprise devs who live in that stack. Cosmic champs reti pool and my personal delegated votes on valar platform voting yes was no accident :blush:

We’ll keep pushing hard on the council side for the structural fixes and improvements but at the end currently owner of xgov is AF.

Appreciate you engaging openly! This kind of back-and-forth is exactly how we level up xGov.

2 Likes