Introduce quadratic funding to the polkadot treasury spending
This proposal aims to introduce a way to do quadratic funding(QF) in the polkadot ecosystem which brings an alternative mechanism for the polkadot treasury spending. In a QF funding round, projects will share a fixed public fund pool and the final distribution will be decided by the community votes which are calculated by weighted square root of voters' donation.
Problem statement
Treasury spending is one of the biggest topics in polkadot governance and there are dramas about it. Main problems about current OpenGov treasury spend model include:
- Whales are playing too important roles.
- Irrational votes.
- Possible collusion.
- Influence of Low token holders with high contributions is low.
- Lack of global perspectives, plans and budget about treasury spend.
So it turns out:
- Results of most referenda are finally decided by several whales.
- Community members may not vote against an unreasonable proposal because they may offend the proposer.
- Many community members complain about treasury spend, but what they can do is limited.
- Teams are proposing an amount that just depends on their own calculation, not under a global budget or spend plan. So teams don’t have to control their budget if their referenda can keep passing.
Quadratic funding
Following are several tips about how quadratic funding works:
- There is a public funding pool for a funding round.
- Different applicants(teams) share this pool by votes they received.
- Communities vote on a project by donating their assets to an applicant project.
- The more donors and the more funds an applicant project receives, the more a project will share the pool.
Here is an example. Projects A, B and C will share 10,000 DOT in total. Finally All of these 3 projects received 1,000 DOT donations, but A has 5 donors(200 DOT each), B has 2 donors(500 DOT each), and C has 20 donors(50 DOT each). Obviously C has broader support, so C shares the most of the pool.
We can learn more from gitcoin which is the biggest quadratic funding platform in the ethereum ecosystem.
Challenges
There are mainly 2 challenges we’ve seen.
- Sybil attacks. A project can create many accounts and donate assets to himself.
- Incentivisation. A community member will think it a stupid decision to give out their own money while there is a public fund pool, especially when the public fund is not spent reasonably.
For the first challenge, we will introduce voter weights. Each voter(donor) will have a weight calculated by history on chain behaviors and off chain data bindings. So if a voter has more on chain contributions and more off chain proof which can prove it is a real person, he/she will get a higher weight. Attackers’ weight value will be 0, no affection to the final result.
Some ideas can be used for donation(vote) Incentivisation. For example, if a voter donated 50 DOT, there will be a 50% possibility he/she can get 100 DOT as reward. Of course we can set a cap to each voter’s reward to encourage small donations.
How to do it in polkadot
- A bounty will be created to hold funding pool assets.
- Funding rounds will be created with a predetermined budget. Each round may have a topic for similar projects.
- Projects apply to join a funding round and curators will review them.
- Communities make donations in a funding round by transferring their assets(DOT) to the applicant project’s address.
- Quadratic funding platforms do calculation, audit and submit results to curators. Funds are distributed to applicant projects through child bounties. Rewards are sent to voters.
An off chain reputation system
Every address will have a voting weight in a funding round which will affect the final votes. An address' voting weight is decided by 2 groups of factors.
- History on-chain behaviors.
- Off chain social info binded to this address which can prove there is a real person or an entity behind this address.
Many tags will be defined according to upper factors, and each tag will have a score in a funding round. An address' score will be calculated based on how many tags this address has, and its final weight depends on this score.
Audit
Following info will be provided in case the community's audit:
- Final fund distribution through child bounties.
- All on chain transfers for donation.
- Detailed voting weight info of an address, including:
- Tags this address has.
- Score of each tag in a funding round.
- Off chain social info binded and related links.
Almost all actions or info can be verified by on chain data except the binded off chain social info, but in most cases these data can be verified by public social media links.
FAQ
1. Will QF take the place of treasury funding by OpenGov?
No. QF provides an alternative way for the polkadot treasury spending which can bring benefits the OpenGov way lacks.
2. Can a project apply for a treasury fund through OpenGov if get funded in a QF round?
Yes. QF works in parallel with OpenGov, but all the data is transparent and the community will take into account the funds obtained by QF in a OpenGov proposal review process. At the same time, QF will show the community's preference to a project by the donations.
3. I'm a whale, why should I support QF?
A whale benefit most from QF because:
- It improves the collective decisions of polkadot about treasury spending.
- Several steps of QF like bounty approvals, curators appointment, fund top up are still controlled by OpenGov, and your votes will still play important roles.
- Reputation system in QF encourages the community to make more contributions to the eco.
All in all, QF improves the rationalization of the polkadot treasury spending, restores the community’s confidence, and finally increases the value of polkadot.
Comments (6)
Proposal Failed
2
of 3Summary
0%
Aye
0%
Nay
Aye (33)0.0 DOT
Support0.0 DOT
Nay (38)0.0 DOT
Comments (6)
So where does the funds from the pool/bounty come from? The treasury? If so, how much of the treasury funds will be transferred to this new funding model bounty/pool? Quadratic funding on EVMs usually comes from direct donations and own funds so no native treasury is involved which is why these questions become relevant for Polkadot.
As for the implementation itself we don't like the social media auth as these companies by design require heaps of data, and profit from your data (when the entity is legit) and are opposite of what web3 should be like. So the weight increments for these sounds extremely detrimental for legit parties specially considering that including them won't penalize detrimental proposals/entities as these accounts can be created and verified easily while helping perpetuate these data gathering mechanisms for legit parties.
Additionally, the history of on-chain behavior must also be very well studied, debated and decided first otherwise we'll end up penalizing new or old participants or whatever combination of the factors that these on-chain activity requires.
The idea that "The more donors and the more funds an applicant project receives, the more a project will share the pool." will definitely translate to sybil attacks (specially the number of donors part) as we don't have robust ways to determine identity for on-chain activity yet. So ending at the amount donated directly sounds like the best approach. If there are identity mechanisms like the passports of EVMs that are meant to be applied to Polkadot we should be discussing those first instead of jumping to sybil risk mechanisms with a large amount of treasury funds right away. Preferably, ways of determining identity that are native not invasive, voluntary or leak-risky. Also, don't give these options a high weight as these are still prone to errors.
Considering these issues which Gitcoin took years to iron out only to circle back to a centralized approach to identity verification, we'd like to also hear about the idea of this being tested extensively first on Kusama so that we can see an operational QF mechanism for the treasury first instead of jumping straight away on Polkadot's runtime and start fixing issues on the way.
As much i'd love to see quadratic funding in action, i still agree to the points mentioned by @Saxemberg Governance. Would love to see it first being experimented on Kusama, getting some hands-on experiences before thinking about bringing it to Polkadot
So where does the funds from the pool/bounty come from? The treasury? If so, how much of the treasury funds will be transferred to this new funding model bounty/pool? Quadratic funding on EVMs usually comes from direct donations and own funds so no native treasury is involved which is why these questions become relevant for Polkadot.
As for the implementation itself we don't like the social media auth as these companies by design require heaps of data, and profit from your data (when the entity is legit) and are opposite of what web3 should be like. So the weight increments for these sounds extremely detrimental for legit parties specially considering that including them won't penalize detrimental proposals/entities as these accounts can be created and verified easily while helping perpetuate these data gathering mechanisms for legit parties.
Additionally, the history of on-chain behavior must also be very well studied, debated and decided first otherwise we'll end up penalizing new or old participants or whatever combination of the factors that these on-chain activity requires.
The idea that "The more donors and the more funds an applicant project receives, the more a project will share the pool." will definitely translate to sybil attacks (specially the number of donors part) as we don't have robust ways to determine identity for on-chain activity yet. So ending at the amount donated directly sounds like the best approach. If there are identity mechanisms like the passports of EVMs that are meant to be applied to Polkadot we should be discussing those first instead of jumping to sybil risk mechanisms with a large amount of treasury funds right away. Preferably, ways of determining identity that are native not invasive, voluntary or leak-risky. Also, don't give these options a high weight as these are still prone to errors.
Considering these issues which Gitcoin took years to iron out only to circle back to a centralized approach to identity verification, we'd like to also hear about the idea of this being tested extensively first on Kusama so that we can see an operational QF mechanism for the treasury first instead of jumping straight away on Polkadot's runtime and start fixing issues on the way.
As much i'd love to see quadratic funding in action, i still agree to the points mentioned by @Saxemberg Governance. Would love to see it first being experimented on Kusama, getting some hands-on experiences before thinking about bringing it to Polkadot