Questions on xGov Priority Areas and Impact Evaluation

Hi everyone,

I’ve been reading through the Council meeting notes and recent proposals and wanted to raise two questions that build on discussions the Council has already started around proposal quality and evaluation.

Priority areas

xGov proposals are submitted on a rolling basis, which creates flexibility for applicants. But I’m curious whether builders currently have enough clarity on the kinds of work the ecosystem wants to see more of.

For example, quantum readiness and payments seem especially relevant to Algorand right now. Could clearer categories help builders understand where contributions may be most useful?

One thing Optimism found in its retroactive funding experiments was that broad funding rounds made it harder for builders to know what kind of value the Collective wanted, and harder for reviewers to judge whether projects were creating the kind of impact the ecosystem needed.

Impact evaluation

This question follows from the first.

As xGov receives proposals from different categories, I wonder if it would help to have a shared way to think about impact. A quantum-readiness tool, a developer tool, and an education project can all create value, but the evidence for each one will look different.

Would it be worth exploring what strong evidence of impact looks like for different proposal types?

From my experience as a grants program lead, one recurring challenge we saw was making sure the funding process clearly communicated what outcomes the ecosystem wanted to see. When that was clear, it improved the kinds of builders we attracted and the quality of proposals we received.

Curious what the Council and community think about both questions.

Thank you for your proposal. Speaking from a personal perspective, I do agree with your points. At the same time, I also understand that, given the current state of xGov, it is quite difficult to move in that direction.

What you described is quite close to a managerial or strategic mindset—essentially, the idea of minimizing spending while maximizing outcomes. I personally share this view as well. One of the goals behind this thinking is to maximize the cost-effectiveness of xGov as a community-run funding mechanism, so that we can demonstrate to the Foundation that entrusting funds to the community results in responsible and effective allocation. In turn, this could help justify increasing the share of funds that the community is allowed to manage in the future.
However, there is another perspective as well. From that viewpoint, the amount of capital distributed through xGov is negligible compared to the Foundation’s spending. At the same time, the community is already not being adequately rewarded in terms of ALGO price performance. In that context, one could argue: if the Foundation itself has not been able to achieve sufficient efficiency in its own spending, why should only the community be the one expected to exercise restraint and reduce costs? From this perspective, the approach would instead be to maximize spending, and if the budget becomes insufficient, to request a larger allocation—thereby ultimately maximizing the amount of capital the community can deploy.

In the current xGov structure, most Councils members and xGov voters are themselves recipients of funds, which makes it difficult for strong incentives toward cost reduction to emerge. Long-term ALGO holders have already accumulated losses due to price fluctuations, and builders in the ecosystem have neither benefited from price appreciation nor received meaningful financial support from the Foundation. In that sense, almost everyone involved in xGov is operating under constrained circumstances. In such an environment, short-term personal incentives tend to take precedence over long-term collective development. From my experience over the past year, I find it difficult to meaningfully discuss “maximizing cost efficiency” without a stronger base asset appreciation or broader structural incentives.

I personally struggle with this gap between ideal and reality. Thank you again for putting this into a structured proposal format.

Thank you for starting this discussion here.

Regarding priority areas, I think we should not constrain them because blockchain as a whole is still searching for product market fit. By the time the community would agree on an area, that might already be out dated and/or the projects starting only after that has been defined would fall behind the rest of the space. IMO, the builders should find for themselves problems that people, i.e. future users, want to have solved. These users are not necessarily already part of the Algorand community, which is why if the funding direction were set only by the members of the Algorand community, it might not identify the needs of such users. In short, IMO the xGov program should support broad innovation.

Regarding the imapct, I believe that with the current retroactive approach, the shared way of thinking about impact is already there implicitly. But I agree that it would be useful to better communicate what proposals are exceptionally good. Perhaps we could have a featured section or give other kinds of additional exposure to such funded proposals.

Thank you @aper_nft and @uhudo for the additional context and feedback.

I agree these questions alone do not resolve the deeper challenges around incentives, trust, and builders feeling supported in the ecosystem. I also think that priority areas should leave room for builders to propose innovative ideas outside those areas.

I see priority areas more as directions that can help builders understand what the ecosystem currently needs, while giving the Council a clearer basis to evaluate the value being created.

Over time, that could also help xGov show what it is producing and give the community a stronger case to justify more capital allocated to builders through xGov.

@Hellen, thank you for your reply.

One point I’d like to add is that, when it comes to evaluating proposals, the Council is fundamentally in the same position as any other xGov. There are also concerns about Council members having disproportionate influence on governance discussions. Because of that, defining specific priority areas is not inherently part of our role, nor do we have the authority to determine them on behalf of the ecosystem. That said, Council members do have influence, and the importance of reviewing and assessing proposals carefully seems to be increasing. So I understand why some people expect the Council to play a more active role in providing direction or guidance.

@uhudo, while we are currently discussing the role, responsibilities, and expectations of future xGov Councils, I think it could also be valuable to invite broader feedback from the Forum community even before any formal proposals are developed.

I do agree that xGov program could benefit from more clarity on its objectives. But IMO, these are simply to support innovation that increases usage of Algorand.
Defining it in more detail would be difficult in my opinion, as usage metrics can be manipulated and their relevant type varies greatly depending on the usecase. E.g. for on-chain applications, that can be TPS, TVL, number of monthly active accounts, assets or smart contracts created, amount of MBR locked, etc. For off-chain applications its even more difficult, even more so on how to compare different projects. Here is where I see voting by the community as a sufficiently good aggregated metric.

Regarding the future of xGov Council, I fully agree that participation of the broader community in such discussions is welcome and highly beneficial.

This comment might be a bit off-topic, but the post title was too good to pass up!

We’re planning to submit a major xGov proposal, but we’re facing a structuring issue. The proposal is tied to a primary open-source repository that involves a directly dependent submodule repository (there’s actually a second submodule too, but it has already passed xGov voting). Additionally, there is another repository that isn’t a direct dependency, but it represents an integral part of the whole endeavor.

I’m mostly concerned about the T&C. Each repo already has, or will get, a PR on Electric Capital. However, I’m planning to create videos and other materials targeting developers and enthusiasts in a way that makes separate xGov proposals impractical — afaic a single, unified xGov proposal is a far better choice for the ecosystem.

Thanks for considering submitting another proposal.

Based on the description, I do not directly see a problem / do not fully understand the situation. Is the ownership of all the submodules with you and/or you have the rights to use them?
If that is the case, I do not see a reason why a joint proposal that relates to multiple repos would not meet the T&Cs. I would suggest to start a new Forum thread for the proposal, where we can then discuss any open points, while not necessarily opening the proposal yet on the xGov platform. Once everything is clearified, you can create the proposal on the platform, moving it to the mandatory “last call” discussion phase.

Thank you for your answer! Yes, all of the repos involved are under the custody of the same GitHub organization. I don’t feel creating a dedicated “non-official” thread is necessary - the only issue I had was that, across all the guides here, only the singular has been used to describe the “open source repo” connected to the proposal.

In this case, I don’t think that would be a problem. Just submit individual ones to the Electric Capital and that should be it.

You can still open a thread before creating the proposal.
xGov process was initially meant as such - first create a proposal thread, people discuss it, then create the on-chain proposal, where certain parameters like the ask size can’t be changed anymore. The on-chain discussion phase was meant as a “last call”. This process hasn’t come to the UI yet but the Council requested it to be implemented.
E.g. we at Valar did the same for the last proposal.

I’ll do that then, thank you!