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.
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:
So it turns out:
Following are several tips about how quadratic funding works:
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.
There are mainly 2 challenges we’ve seen.
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.
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.
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.
Following info will be provided in case the community's audit:
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.
No. QF provides an alternative way for the polkadot treasury spending which can bring benefits the OpenGov way lacks.
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.
A whale benefit most from QF because:
All in all, QF improves the rationalization of the polkadot treasury spending, restores the community’s confidence, and finally increases the value of polkadot.
Threshold
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.