# xGov Council Meeting #9 (January 7th, 2026) **URL:** \ **Category:** xGov Council\ **Tags:** xgov-council-meeting\ **Created:** [January 16, 2026, 3:47pm UTC](https://forum.algorand.co/t/xgov-council-meeting-9-january-7th-2026/15130 "2026-01-16T15:47:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![simonb](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.algorand.co/simonb/32/2818_2.png) [@simonb](https://forum.algorand.co/u/simonb)\ **Post date:** [January 16, 2026, 3:47pm UTC](https://forum.algorand.co/t/xgov-council-meeting-9-january-7th-2026/15130/1 "2026-01-16T15:47:50Z")
\*_ **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: * * * #### 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: - 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: - This creates a binary outcome where proposals either: * * * #### 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: - 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: - 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: - 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. ---
**Author:** ![HMP](https://avatars.discourse-cdn.com/v4/letter/h/b38774/32.png) [@HMP](https://forum.algorand.co/u/HMP)\ **Post date:** [January 16, 2026, 7:01pm UTC](https://forum.algorand.co/t/xgov-council-meeting-9-january-7th-2026/15130/2 "2026-01-16T19:01:05Z")
very good session ---
**Author:** ![scholtz](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.algorand.co/scholtz/32/864_2.png) [@scholtz](https://forum.algorand.co/u/scholtz)\ **Post date:** [January 17, 2026, 10:20am UTC](https://forum.algorand.co/t/xgov-council-meeting-9-january-7th-2026/15130/3 "2026-01-17T10:20:24Z")
> [@simonb](#): > > - The current **yes/no voting structure** does not allow the council or xGov voters to express: > - Partial support > - Support at a lower funding level 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. > [@simonb](#): > > near-maximum funding amounts 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. > [@simonb](#): > > - Concentration of power 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. ---
**Author:** ![simonb](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.algorand.co/simonb/32/2818_2.png) [@simonb](https://forum.algorand.co/u/simonb)\ **Post date:** [January 17, 2026, 3:12pm UTC](https://forum.algorand.co/t/xgov-council-meeting-9-january-7th-2026/15130/4 "2026-01-17T15:12:05Z")
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](https://reti.nodely.io/validators/169)). 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 😊 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.