xGov Platform Evolution

I want to share a collection of initial thoughts, some of which affirm elements of AF’s proposal and some of which would modify it:

Guiding Principle

  • No up-front or milestone payments. Payments should always be after a promised outcome is fully delivered. This rule is elegant because it applies equally to retro and forward grants, and it makes the program have a strong bias toward retro. Fisherman made an excellent point in this thread which I have made in the context of xGov-80: if an intermediate milestone is not usable on its own, such as a smart contract without a UI, it will be extremely difficult for the council to verify if the work was completed properly. The best case scenario is that milestone verification creates more work for the council and they become complacent. Perhaps once the system is humming along smoothly it can be enhanced to support milestones.

Expert Governor Eligibility

  • xGovs should be participating in consensus. This is absolutely critical to the security of the network. I expect delegation schemes for consensus could fill the gap for people who want to participate but can’t run a physical node.

  • xGovs should have some minimum stake. We just uncovered a botnet that is performing a Sybil attack on the current xGov program by creating thousands of accounts, presumably to farm potential future airdrops. The xGov minimum stake should be equal to whatever the new incentivized consensus protocol sets. This will make any Sybil attack prohibitively expensive.

Terms & Conditions

  • Open source code I have a strong bias toward open-source for xGov. It is ridiculous that previous major apps and grant recipients have not opened their source code and, in some cases, that has left users with stranded funds. Can we agree that all Algorand-related deliverables must be open source under some license? If you want to be closed-source, talk to some investors who could profit from your proprietary IP.

  • Single active proposal per entity. There should be a strict limit on active proposals per entity. This limits the work the council and voters need to do (see xGov Session 3 with 49 proposals and some entities submitting 3-5 separate proposals), and it also ensures that grantees are focused.

Proposers

  • Up-front KYC. KYC is absolutely required to stay compliant and, in my view, should be enforced before proposals make it to voting. When usable DID arrives, we can evaluate another approach.

Discussion

  • Standard discussion period. I think all proposals should have a 2 week discussion period so that this timeline is easy for everyone to remember.

Payments

  • USDC Conversion At Spot Price. The current program converts at a 30-day average price which could work in someone’s favor but this should not be a gamble. If the conversion is done at spot, the recipient can immediately convert back to Algos if they want without the chance that they were effectively forced to sell low and buy high. I appreciate that this could go both ways, but the system should be modified to avoid this negative scenario from ever occurring.

Voting

  • Separation of powers. I think the council members must be prohibited from voting on proposals to establish a separation of powers. The council has the power to approve payment upon delivery, so this needs to be independent of passing the proposal. This kind of segregation of duties around payment approval authority is standard practice in any institutional context.

  • Simple voting mechanics. The voting threshold is not clear. The given example of an exponential decaying curve i.e. x(-x/5) looks like the below. How does that map to proposals? Anyway, this is too complex. Thresholds should be intuitive for anyone to understand–perhaps simple majority of active xGov stake.

8 Likes

Initially posted my thoughts on the Discord channel. So just posting it here as well.

Thanks @Loedn for kicking this off and inviting the community for feedback.

See many great things already discussed and some of them are also in the one below, so see it as an endorsement of the idea :wink:

  • T&C and xGov role should include a note that it’s prohibited to vote on your own proposal. I know this is difficult to uphold without transparency, but at least naming it means people who do break rules / are being unethical.

  • Ditch milestones (if we don’t want to go full on retroactive). With the new funding timelines, this shouldn’t be necessary anymore. Just put in a new proposal for the follow-up. It simultaneously enforces proposers to keep their proposals effective and make an impact after each and every proposal.

  • Proposal categories should include an USDC max value per category as well (or at least cap it to cover the volatility part). If Algo jumps in price, even the smallest category will then become quite substantial. So let’s say: ‘50k or less than 20k in dollars’ (if legally possible)

  • Does AF has enough manpower to perform KYC on proposals before they passed (until it’s automated)? As it means 2x or 3x the amount of KYC might be needed vs the amount that actually passed (and make it worth it).

  • I’d propose a cool down period for a legal entity/individual after a proposal is handled. To ensure entities don’t create back to back proposals and first deliver value after the last proposal passed. Could be 4 or 8 weeks, or depending on the previous proposals size. Can be managed from the UI itself (so no manual interference).

  • What happens when a proposal passes, but the treasury wallet is empty and the top-up takes another month? Payout delayed?

  • Do xGov members need to vote on all proposals? At any give time? Meaning, every week they need to at least process one or multiple proposals (given the smallest category)? Kind of a big ask, looking at the previous xGov period with 49 proposals.

And of course my vote would also go to retroactive funding like @fisherman.algo is vouching for. Which in my opinion also simplifies the grants system, less prone to being gamed and simply forces to deliver first and get follow-up funding after.

4 Likes

interesting idea, and proposal. I’d like to see the final proposal go up against other supported finalized proposals (like Fishermans) using Algorand governance voting. Do governors really have a say on important decisions? or are measures designed by the Foundation the only choice we get to vote on?

1 Like

On second thought, @Loedn has a quite balanced proposal and I like it in theory. The major problem with prospective funding is assessing risk:

  • There is great uncertainty of risk in proactive funding in comparison to traditional vetting processes. The counterparty, its capabilities and aspirations are difficult to measure at a distance. @fisherman.algo has a point in stating that assessing those risks adequately might be a fools game.
  • A fluid council will vary widely in effectively assessing proposals. One would typically prefer to lock-in motivated experts providing support in their given fields to counteract uncertainty. Applying a rapid rotation of three months could conflict with the complexity of the task. One might favor a more meritocratic approach.
  • A proactive approach requires a lot more upfront effort und cost to tame uncertainty. One of the main reasons proactive funding results has been lacking is likely that it requires a more restrictive, strategic framework under which decisions can be made. Proactive incentives on blockchain have difficult to manage counterparty risk when not streamlined. When looking at Optimism, missions and such are categorised under an umbrella of strategic goals set for the ecosystem, effectively providing a framework easing uncertainty and providing direction.

Marrying proactive and retroactive approaches under one framework might over time result in growing accidental complexity in these processes, draining disproportional time and effort, marginalising its efforts and probably resulting in overwhelming, probably conflicting monolithic structures that might make it difficult or even discourage people from contribution. Retroactive Funding, because of its reactive nature, doesn’t need as much rail guards as proactive funding. Proactive funding, in my opinion, needs an effective framework that is streamlining processes as much as possible. It requires much more upfront effort to mitigate risk.

A retroactive approach would put the risk on the participants and there is good reason to favour this approach at his time.

  • Algroand itself is infrastructure that should inherently offer a value proposition based on its tech. Entities building on Algorand should be enticed to do so because the infrastructure offers competitive advantages for their businesses. It is difficult to see value in projects that are effectively disconnected from the real world economy. At the end of the day businesses need to generate cash flow based on tangible goods and services and can not rely on fluffy digital trends and promises that can only be sustained by speculative narratives living inside their own echo-chamber, driven by venture capital that is, honestly, mostly not interested in long-term positions but short term gains by exploiting said narratives. As we have painfully experienced over the years.

  • Incentives should be focused on the major parts of the infrastructure that are critical to its operation and provide a strong foundation to build upon, to me these are to date: Network security and decentralisation (node incentives) and critical tooling like wallets, explorers etc. We are very reliant on few providers. If, for example, there happens to be a critical exploit on the Ledger HW, this would result in catastrophic effects for a signifiant portion of participants. With retroactive funds, projects that are important to Algorand, but not to date self-sufficient (or by its nature difficult to monetise but still important), like Algoexplorer and NFTexplorer, are able to operate under the goodwill they harnessed over time judged by their impact.

  • The major contributor to a productive community is its culture. No matter what one might think about Bitcoin, its culture is strong and incentivices itself. Fostering culture is not merely a matter of one singular program and is likely impossible to precisely influence proactively. Retroactive funding supports the growth of culture just where it happens. The approach taken with AlgoKit, making it easy to engage with and contribute to Algorand, reducing friction and fostering action by means of usability and therefore inclusion, is likely the general proactive approach to take across the board. Fostering a strong culture ultimately fulfils promises that cannot be fulfilled by xgov alone. We probably should explore ways to further community engagement across the board.

Still, proactive funding is important and should not be dismissed entirely, but I would propose to compartmentalise its structure, based on the following naive assumptions:

Enthusiasts: People enthusiastic about Algorand, contributing by tooling or other means for the sake of community, learning and discovery, can be effectively supported by retroactive funds. These funds may snowball into long-term support for these tools/projects by continued funding of milestones. It is these people who demonstrated persistence who are most likely to develop valuable tools and projects over time, in comparison to startups acting merely on financial incentives with no particular convictions to Algorand or its community itself.

Businesses use Algorand because of its underlying characteristics, like TravelX, Quantoz, etc. Their reason to choose Algorand is because it provides them with competitive advantages. Strategic funding for businesses like Hesab Pay, offering significant impact and PR opportunities, is essential.

Institutions are interested in a CP systems that are secure, persistent, and have excellent finality.

Retroactive Public Goods Funding Program

We could marry the proposals by @Loedn and @fisherman.algo by simply removing the proactive part, concentrating on “I have done X, it has benefited the community because of Y metrics, I would like to receive Z”. Since proposers are known by having already contributed to the ecosystem, it minimises uncertainty and counterparty risk, while at the same time incentivising and fostering meaningful contributions. So, instead of randomly airdropping rewards for certain projects, enthusiasts who established themselves can apply for immediate funding for their milestones judged by their activity/impact/importance.

Stategic Proactive Funding Program

On the other Hand, I would welcome a separate proactive funds program on the condition that it is very much streamlined and focused on the most important categories we consider mandatory for Algroands strategic growth. Instead of receiving a magnitude of proposals from a diverse set of themes unfiltered (which are mostly handled by the retroactive program), we might discuss the themes and missions that are most important to us to achieve and create a program spanning multiple domains, offering funds by means of milestones to qualified, KYCd candidates in tight cooperation with the foundation. This would also streamline community engagement by effectively providing an overview of said categories, their importance and weight, their status and progress made, and foster continuous discussions about strategies, categories and projects over time. By categorising and streamlining our needs to select categories of importance, reached by discussion, and provided with extensive due diligence, we gain flexibility to adjust to critical conditions, improve overall assessment capabilities, and decrease uncertainty by handpicking the most promising applicants applying per category. In my mind, strategic proactive funding should be as regulated as possible, providing the same due diligence and safeguards as applied in traditional practices. It would allow the community to engage in tandem with an expert council to allocate funds based on precise evaluations and impact assumptions. Basically quality over quantity.

This might strike a balance worth considering.

1 Like

Lots to unpack…

xgov
Imo xgov is a good thing, and the next iteration is a big step in the right direction. We should keep evolving xgov for proactive means of funding projects that would otherwise simply not build on algo.

Why? Pretty much every big player(i’m not talking about nft projects, but services like nfdomains, dexes, bridges…) in algo at this moment only made it thanks to generous grants from AF(or investments via borderless, arington etc. - on behalf of AF - although lines here are a bit blurry) when they were starting. Many failed despites funding sure, but there are many reasons why a startup might fail - incompetence/bad intentions are not always the reason… we had a shit**y bear years, lack of liquidity in the ecosystem, lack of users… being profitable in this environment is next to impossible. and pelase don’t point to dexes…they are “profitable” atm thanks to the defi incentives from af and not because ther business model is such next gen thing - not trying to diminish all the hard work they did, but objectively speaking i think it’s hard to disagree…

retoractive grants
I agree there are individuals and teams that contributed a lot to the ecosystem without such grants so retroactive grants should be a thing too(if that was a thing, nftexplorer would still be a thing imo etc.). But my honnest oppinion is, while retroactive grants are great for rewarding people that already built stuff, it could simply be replaced by a one-time “retro-grant” distribution by AF to all “worthy” right now. Because once you rewarded these people, retroactive grants going forward are not going to have big impact/drive on the ecosystem development in the short term…and we nee dshort term boost or are we looking to miss the bull yet again, we cannot afford this.

The xgov future vision as to my understanding is that it will be used to make other decisions about algorand in the future, so it is in our best interest to make it better and not simply looking at replacing it. Or are we all happy with how current governance framework is functioning - i’m not, i would much prefer xgov to take it over - so let’s make it as robust as we can.

4 Likes

@Loedn I am in favor of having two paralel grants programs in place.

One that @fisherman.algo proposed and one that AF proposed.

Competition is good and the only question is weather AF is willing to give funds to be distributed on the multisig account of the 115 people in the fishermans list.

I dont agree with the point that retroactive grants should be the only way to distribute algos, but please give people chance to proof themseves they can build alternative grants program.

2 Likes

Will removal of milestones hinder bigger projects from being built via xGov funding? I do think so.

Many of the current bigger and impactful projects on algorand might not have been possible if there was no funding.

We have to fund projects that is creating maximum impact along with new ideas that will create max impact in the future. Blockchain is a fast evolving technology…

Onething we can make mandatory is a proof of concept.
xGov will only fund projects that have a POC. This will make sure that the applicant has made enough effort and there is a proof of work which the xGovs can go through before voting.

Another suggestion is to divide the total allocation into two parts one for retrospective funding and other for milestone based funding.

2 Likes

I think we should separate the concept of funding milestones—which represent unfinished work—from funding large or ambitious projects.

The way the process is being redesigned to allow grant proposals at any time means that the slow quarterly cycle goes away and a project could make a subsequent proposal after a previous one is completed.

That said, in my design each proposal must deliver a standalone outcome for the community, such as a usable product or feature or measurable impact. We should not be funding unfinished pieces of things nor do we have the capacity to manage the complexity this brings.

The recent discussion of xGov-80 has already demonstrated that milestone delivery verification and when to request the next milestone is going to be a mess.

POC

I think this is a great idea as one way to help the council and xGovs understand what they’re considering.

3 Likes

I wouldn’t think about retroactive grands as a way to shower already profitable projects with additional Algo, but as a platform entities that proved their impact can turn to for additional funding for e.g. milestones or to bridge difficult times with subsidies because of insufficient liquidity in the ecosystem. Especially in times like these, those allocations might prove very handy especially in supporting projects with importance and impact but lacking in sustainability, like e.g. Algoexplorer/NFTexplorer.

Proactively funding projects solely on monetary incentives (grant-farming) on an illiquid chain doesn’t magically improve liquidity and the sustainability of said projects. In my mind, the only way to safeguard against this and improve liquidity is to target entities that not solely rely on Algorand itself for the sake of it, but who’s target is to leverage Algorand to improve or innovate on their existing goods and services, e.g. real world assets - or make them accessible to us indirectly, like cross-chain projects.

1 Like

I got your point. So each proposal should deliver something that is useful for the community. This is a good thought process.

I have another suggestion that I have put forward in the discord.

If proposal deliverables is not open source, the proposer should provide the explanation for the same in the proposal. This will help xGovs to take informed decisions.

1 Like

No up-front or milestone payments. Payments should always be after a promised outcome is fully delivered. This rule is elegant because it applies equally to retro and forward grants, and it makes the program have a strong bias toward retro.

Wouldn’t his effectively transform all grants into retrospective grants? I see where you are coming from. Farming grants proposal after proposal and leaving behind an unfinished product should be avoided. I guess you make a distinction on forward and retro programs based on the state of the project. So an applicant applying for a forward grant is proposing to build a product, and an applicant applying for a retro grant proposes to receive a grant based on impact. But from the perspective of active funds though, both receive funds after the fact. If we define retroactive grants simply as an option for grants by measure of impact, it could allow for projects that already established themselves to get continuous funding by applying for retroactive funds to further their development based on milestones. Since these entities are already known, they already offer significantly reduced counterparty risk.

2 Likes

Yes.

In my view, this basically blends the best of both approaches.

The risk of forward grants is derived from paying before delivery, such as any kind of up-front payment or intermediate milestones that haven’t achieved any outcome.

If xGov only pays for outcomes, the program could have two proposal angles:

  1. You already achieved an outcome, and you are requesting a retro grant award for impact already demonstrably achieved.

  2. You propose to achieve some new outcome, and you will work toward it and only get paid if you achieve it.

I think this basically solves the biggest problem with xGov.

3 Likes

Evolving the idea based on the gigabrain feedback in the thread -

Xgov could turn into a proactive crowdfunding DAO. When I say crowdfunding, I mean users and the Algorand Foundation, or whoever wants to contribute, could put up ALGO for projects that are looking to get funding prior to launching a product (proactive funding).

The current infrastructure of Xgov could work for this with some modifications. The ALGO that gets put into the proactive crowdfunding DAO each quarter by the Algorand Foundation could be distributed based on a vote of the Xgovs. However, any Xgov is also able to personally contribute to any of the particular projects, meaning they are personally investing into this project’s future and will receive the upside and downside of doing so.

If a project turns out to be successful, then the retroactive DAO (Impact DAO) could reward the project with RPGF, and those funds can first go to pay back the investors in the proactive DAO (AF and users who personally contributed) including interest, and excess funds go to the project. Why this makes sense is because the Impact DAO rewards measurable impact on-chain and in the community. If a project makes it to mainnet and has an impact, then they will receive RPGF for this impact, and those funds can go towards rewarding the early investors who made the project possible.

How Xgovs are selected and vote should change-

Instead of the stake being derived from the amount of ALGO you have locked in governance, it should instead be every Xgov is KYC’d and has a minimum stake of x ALGO that they’re willing to deploy into projects each quarter. This is still a credibly neutral criteria for Xgovs meaning anyone is able to participate (unless you’re from a restricted country, which I personally don’t agree with but will concede on this point for expediency).

The Xgovs must deploy X amount per quarter of their personal ALGO or they are kicked from Xgov. This will ensure we have actual investors in Xgov (when you have to spend your own ALGO you’re all of a sudden a lot more interested in seeing these projects succeed).

Every Xgov should get an equal vote on how the AF funds are deployed. For example, if the AF puts 2m ALGO per quarter into the proactive DAO, each Xgov gets 2m ‘votes’ to distribute amongst the proposals. They must distribute all 2m votes, but there will be an abstain bucket for excess votes not looking to be allocated, and an ability to vote 0 on a project. The distribution should be done using the median result of the Xgovs votes, + any personal allocations from Xgovs. The Xgovs are responsible for tracking milestones and disbursements of funds. This voting structure is easy to understand, and using the median removes any of the extreme votes. The 0 vote is also highly impactful when using the median. This voting mechanism would be very similar to the proposed Impact DAO voting mechanism.

This sets up a really healthy dynamic where not only do the Xgovs have ‘skin in the game’, but they also benefit from the upside of emerging products. It allows for there to be a funding mechanism for proactive grants, but shifts the risk from 100% AF treasury funds to maybe 25-50% (depending on how we set the parameters of Xgovs contributions, as well as how much the AF contributes per quarter). It also is much more likely that we get higher quality allocation of capital which is exactly the focus we should have when looking to give proactive grants.

TLDR - Impact DAO funds retroactively and is funded every quarter by the AF treasury
Proactive DAO (modified Xgov) funds proactively, and is funded every quarter by AF treasury as well as Xgovs personally.
Changes to voting will remove the ability for whales to vote their own proposals through while also removing any outliers (by everyone having an equal stake in how AF funds are spent, and using the median).

A massive thank you to every single one of you contributing thoughts and ideas here. Please DM me on twitter your NFD and I’ll send you a Poof. I believe we’re making progress towards a beautiful, meaningful funding mechanism for the community.

2 Likes

Crowdfunding

I think this is diverging too far from the objective here, which is devising a program to deploy the AF treasury’s funds for the good of the ecosystem, which is the Foundation’s mission.

1 Like

That is still the goal, but now with qualifications for being a part of the team who decides how to distribute it.

1 Like

Why not contemplate following the idea of collective grants from Optimism, based on missions and collective intents? It seems a very effective idea to incentivise decentralised but targeted and strategic development, with tangible impact measurements. I also like the idea of “alliances”, allowing for flexible working groups. No matter if proactive or retroactive, I think we need a framework that better streamlines intent into actual productivity. The idea of collective intent and missions fits very well with retroactive funding, but still allows for specific, targeted proactive funding where necessary. I think something like a global community roadmap, that is at the same time targeted but flexible enough to accommodate different modes of operation is quite useful in fostering community culture on Algorand by directing effort that has, to date, been scattered all over the place.

I am not much of a fan of the crowdfunding idea on second thought. I would prefer proactive funding to fall under specific “intents”. At the same time, I think proactive funding should be specialised in nature, allowing for time and proper due diligence to reduce counterparty risk, also utilising for example an experts/developer council. I think we learned that getting drowned in naked proposals is not a good idea. Like above, I think it would be a good idea to streamline proactive grants. Honestly, I think most projects are well served with the retroactive method. Proactive funds in my mind should be allocated for very strategic and specialised purposes and not comprise the main method of funding.

Also, while I share your enthusiasm, I would prefer for us to take our time in this discussion and not rush to vote about it prematurely.

What about starting with minimum features and then slowly converting it into a DAO after the workflows has become efficient?

Hello all. I generally agree with all of the RPG improvement ideas, but here are some practical steps that can be taken to improve the xGov platform immediately:

  1. Cap the amount requested per proposal. While xGov is in the pilot stage, proposers should be discouraged from submitting proposals that have very little chance of passing, simply because of the total available algo vs the requested amount.

  2. Cap the number of proposals per session. There are a finite number of xGovs and they should not be required to review an unlimited number of proposals.

  3. Cap the number of milestones per proposal to one. Most projects that have experience with grant proposal writing will generally want to submit a 3 milestone proposal. Logistically, this is probably not feasible for the Foundation or xGovs to handle in the pilot period.

  4. Cap the total amount requested to like 2x total available Algo. So if there are a total of 2 million algo in the session, total amount available to be requested would be 4 million. This would obviously have to tie in to a ceiling on the amount per project so you don’t have 4 projects requesting a million each and taking up the entire session.

  5. Limit the number of proposals per team to 1. Currently a “team” or project can submit an unlimited number of proposals for “separate” projects. But honestly, all the funding received will go in the same account and ultimately benefit the same group of individuals, so this should be done to prevent proposers from obfuscating their total requested amount by requesting it via seemingly unrelated projects. Now I’d like to note that I am not criticizing anyone who has submitted multiple proposals already, honestly right now it’s probably the best strategy to get proposals to pass. But going forward it needs to be eliminated entirely.

  6. Penalize xGovs who engage in automated vote spreading. This is more of a step to discourage bad behavior than one that can be practically enforced. But it’s the best way to prevent platform abuse.

  7. Strongly penalize xGovs with undisclosed proposals. If an xGov or an xGov-affiliated project has a current proposal in the session, that xGov should be required to disclose that relationship. This is the most practical way to prevent self-voting. Just require disclosure. If they want to still vote for their own project, they can’t actually be stopped from doing so, but at least they will have to own that vote.

There are many other things that can be done to improve the xGov program, but for now, in the pilot stage, these are some very practical and very easily implementable steps to improve the UX for all involved in the pilot program - the Foundation, the xGov voters, and the proposers.

1 Like

What would be your cap? The idea right now is that proposer has to calculate how much votes he can receive, what is his competition, and that is his cap. See that #168 proposal… the second wealthies person in xgov seems to propose #167 and #168 accoding to strenght of his votes, and because he did not receive support from the other xgovs only the smaller proposal got passed.

If you own 6% of xgov votes, you can create proposal that drains the xgov budget by 6%… Math is simple.

For the record next gen xgov platform will have yes/no voting for every proposal, so this will not be possible to do.

I dont think that it is good to limit number of people that may request grants. More competition is better.

Yes, current system is not very good in milestones.

Next gen xgov will be better as i hope that multisig of 20 people will be able to release the funds.

Current cap is 1x of total available algo. I dont see any reasoning in this point.

If you propose request to have more algos then there is possible voters for your proposal there is zero chance it will pass.

This is bad in my opinion. I dont want the Aramid team to be harmed because i take grant for Biatec DEX.
In real world there is term legal entity. So perhaps if you want to propose this, it might be reasonable to propose it per legal entity.
In this case I also do not like it as any project may have multiple ideas to be developed and xgovs can decide what they really want to fund and build.

I dont know how you want to track or enforce this.

Self voting is not illegal. We are living in the decentralized way, and even if I dont like the proposal #168 passing i admire that Michal has put a lot of money to the algorand ecosystem and in my opinon we need more people like him.
The fact that the xgov system can be used this way is not his fault, but it is is fault of the proposers of the system, and the fix for this is going to be next gen xgov where each proposal is going to be voted for yes/no by whole xgov community.

I dont get it why there is no discussion regarding this.

If there is going to be 50 votes per quarter randomly each week I dont think this is good to do without ability to delegate the voting power.