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 to be understood that some topics may not be fully clear without prior context.
xGov Council & AF Meeting – (April 15th 2026) 
Attendees: xGov Council members & Algorand Foundation representatives
Overview
This was the first joint meeting between the xGov Council and the newly assigned Algorand Foundation point of contact for xGov, marking a fresh start in the council–foundation relationship. The session covered onboarding the new AF contact, process improvements for council–foundation communication, open-source contribution clarity, the node-funded treasury proposal status, proposed changes to the open-sourcing-after-approval policy, discussion–voting phase decoupling, and technical updates on committee automation. Discussions were exploratory; no formal decisions were taken.
Key Topics Discussed
1. Onboarding the New AF Point of Contact & Communication Process
The new AF representative joined the call for the first time in this capacity. The council walked through how the working relationship with the Foundation has historically operated and invited suggestions for improvement.
Key points discussed:
- The council holds bi-weekly internal meetings and monthly joint calls with the Foundation; the monthly call is the primary venue for surfacing issues, requests, and feedback.
- The council’s role is advisory — it can propose and suggest, but formal changes remain within the Foundation’s authority.
- Day-to-day communication runs through a shared Discord channel, with more formal requests sent via email with appropriate CC’s for matters requiring escalation.
- A suggestion was made to formalise all council-to-Foundation requests as numbered written proposals, creating a traceable record of what was asked, how it was responded to, and what changed as a result. This was seen as beneficial for transparency reporting and accountability.
- The council raised the need for better visibility into the Foundation’s internal roadmap, noting that the monthly call was originally created precisely because the council had no insight into what was being planned or worked on.
- The question of long-term ownership — what the Foundation intends to own vs. what should be community-led — was flagged as something requiring clarity, particularly as the ecosystem matures.
2. Node-Funded xGov Treasury Proposal & Treasury Top-Up
The council sought an update on two related items: the formal proposal for sustainable xGov treasury funding via Foundation node rewards, and an immediate top-up of the current treasury.
Key points discussed:
- The node-funding proposal has been circulated internally within the Foundation and has received a preliminarily positive reception from the executive team.
- A response from Foundation leadership is expected shortly, and the council will be updated as soon as one is received.
- A separate request for an immediate treasury top-up has also been submitted internally; no confirmation yet, but the process is underway.
- The council noted that if all plausible current proposals were to pass, the treasury balance would go into negative territory, making a top-up a near-term necessity.
3. Open-Source Contribution Clarity & Frontend PRs
A recurring friction point was discussed: despite the xGov frontend repository being open-source, there is no clear contributing guide, and pull requests have been rejected or left unmerged without transparent criteria.
Key points discussed:
- Smart contract contributions have been handled well — all submitted PRs have been reviewed, discussed, and merged after resolution.
- The frontend is where the problem lies: there is no published contributing guide defining what is in or out of scope, and different individuals within the Foundation have given conflicting signals on what will be accepted.
- The suggestion was made for the Foundation to publish a formal contributing guide at the root of the frontend repository, covering must-haves, should-haves, and disqualifying criteria.
- The council reiterated that frontend usability directly impacts xGov participation and retention — a hard-to-use platform reduces voter turnout.
- The Foundation acknowledged this is specifically a frontend issue and agreed a contributing guide should be produced.
4. Open-Sourcing After Approval — Proposed Policy Changes
The current ability to submit proposals with a commitment to open-source after approval (rather than upfront) was originally introduced as a special case for high-value projects with legitimate competitive-advantage concerns. It has since been widely used in ways that place significant follow-up burden on the council.
Key points discussed:
- Many smaller proposals are now requesting open-sourcing after the fact without adequate justification, creating ongoing council overhead to track, chase, and evaluate delivery.
- Several reform options were discussed and broadly supported by both the council and AF representatives:
- Setting a minimum ask threshold (e.g. 200,000 ALGO) below which open-sourcing after the fact is not permitted.
- Restricting this path to high-impact, high-demand, and publicly recognised projects rather than making it generally available.
- Requiring a council member to act as sponsor/chaperone for any proposal taking this route, acknowledging the extra post-approval work involved.
- Establishing a clear timeframe (e.g. 14–30 days post-approval) within which open-sourcing must be delivered, with the council’s veto power used to withhold funds if the commitment is not met.
- The AF representative expressed agreement with objective, threshold-based gates and affirmed that the veto power mechanism is the right enforcement tool.
- The council agreed to formalise these criteria into a written proposal to be submitted to the Foundation for incorporation into the updated terms and conditions, targeting the next proposal batch.
5. Proposal Amount Inflation & Council’s Role in Ask Adjustment
A trend of inflated funding requests was noted, with some proposals asking amounts disproportionate to the scope of work. The council discussed whether it should have a formal mechanism to adjust asks.
Key points discussed:
- The discussion phase was originally designed for exactly this purpose — to allow the community and council to push back on over- or under-asking before a proposal enters formal voting.
- The AF representative and Foundation technical contact both expressed reservations about giving the council unilateral power to reduce a proposal’s ask, preferring that the discussion phase remain the primary mechanism.
- It was noted that proposers can currently withdraw and resubmit if they receive strong feedback that their ask is too high, though this costs them time and their proposal deposit.
- The council pointed out that informal back-channel conversations (DMs) are frequently used by proposers to seek guidance, but these have no weight in the process — all meaningful discussion should happen publicly on the forum.
- The Foundation strongly recommended redirecting all proposer communication to public forum threads, mirroring the ARC process, so that discussions are visible and reviewable by the whole ecosystem.
- A previously discussed idea of a capped percentage adjustment (e.g. ±20%) by the council was acknowledged but not formally endorsed by the Foundation at this stage.
6. Discussion–Voting Phase Decoupling & Proposal UX
A significant portion of the meeting was devoted to structural improvements to the proposal lifecycle, with the Foundation’s technical contact sharing concrete plans.
Key points discussed:
- The current UX funnels users directly into opening a formal proposal (triggering the deposit, committee assignment, and two-week discussion clock) before any informal discussion has taken place. This is a design mismatch with the original intent of the discussion phase, which was conceived as a “last call” — a final check after substantive discussion had already happened elsewhere.
- The proposed solution is to decouple the UX: add a button to simply open a forum discussion thread (no deposit, no committee assignment) as a first step, with the formal proposal submission reserved for when scope and amount are already broadly agreed.
- This change would be frontend-only — no smart contract changes required.
- A second improvement discussed was batch-synchronising proposals into voting: rather than each proposal entering voting individually as soon as it is eligible, an automated process (cron job) would promote all eligible proposals to voting simultaneously, creating predictable voting windows. This was described as technically straightforward.
- Both changes were strongly supported by the AF representative and the council, and were noted as good candidates for near-term implementation.
7. Committee Automation — Technical Update
The Foundation’s technical contact provided an update on recent smart contract work.
Key points discussed:
- The committee selection and publication process is now fully automated. Previously, the publication step required manual intervention; this has been resolved.
- A double watchdog mechanism has been implemented: if the committee is not updated within four hours of the milestone block, an automated GitHub issue is opened and an internal webhook notification is triggered. If unresolved after eight hours, proposals are halted to prevent stale committees being assigned to fresh proposals.
- The tolerance windows (4 and 8 hours) can be recalibrated if needed.
- Active xGov membership currently stands at approximately 100, following recent inactivity-based purges. Further pruning is expected as the next batch of proposals processes through scrutinisation.
- Purged xGovs can re-enrol by paying the registration fee and resume voting on proposals they were already assigned to, though in practice most purged members do not return.
8. Proposal Payment Notification Process
The AF representative asked whether there is a formal procedure for the council to notify the Foundation when a proposal has cleared all conditions and is ready for payment.
Key points discussed:
- Currently there is no standardised process — the council tags the AF contact in Discord once the council vote is complete.
- The AF representative confirmed this is sufficient and asked to be kept informed of anything pending from previous cycles.
- One proposal (from the previous session) was identified as approved by the council but not yet paid; the AF representative committed to resolving it promptly.
Outcomes and Next Steps
The following action items were identified:
- Council to draft a formal written proposal on updated open-sourcing-after-approval criteria (minimum threshold, sponsorship requirement, delivery timeframe) and submit to the Foundation for T&C incorporation ahead of the next proposal batch.
- Foundation to produce a contributing guide for the xGov frontend repository, clarifying merge criteria and contribution scope.
- AF representative to follow up with Foundation leadership on both the node-funded treasury proposal and the immediate treasury top-up request, and report back to the council as soon as updates are available.
- Foundation technical team to proceed with the discussion–voting UX decoupling and batch voting synchronisation as near-term development priorities.
- Council and AF to begin informal Discord discussion on the upcoming xGov council election ahead of the next joint call.
- Outstanding proposal payment from the previous cycle to be processed by the AF representative.
Note: A short council-only discussion took place after AF representatives left the call; that portion is not included in this summary.