Funding Public Goods, Next Steps (Part 1)

Quadratic Funding has been a boon for the Ethereum ecosystem. But as it gains popularity, how do we stop it from being exploited and ensure it continues functioning as expected? In this post, we discuss how we are using MACI to tackle the problem of bribery and collusion.

Funding Public Goods, Next Steps (Part 1)

Collusion resistance in quadratic funding

This post assumes the reader knows a little about public goods, quadratic funding, and Gitcoin Grants, an experiment in using quadratic funding for public goods in the Ethereum community. If none of that sounds familiar: it’s an attempt to improve crowdfunding using a matching pool, giving more matched funding to projects that receive contributions from more people. So, a project that gets 500 individual contributions of $1 gets more matched funds than a project that gets 1 contribution for $500.

So far, the Gitcoin Grants experiment has been pretty amazing. Hundreds of thousands of dollars have been distributed over a handful of grant rounds, and the past few rounds have dominated Ethereum’s social media scenes. That being said, it’s still an experiment, and a long-term public goods funding mechanism probably looks a bit different from Gitcoin Grants:

Creating that long-term public goods funding mechanism is our vision for cl(ea)r.fund. There are a number of interesting challenges to address. In this first post, we’ll focus on collusion: the danger that not every individual contribution is an honest expression of that individual’s preferences.

In a quadratic funding system, if I can influence the way a bunch of other people contribute, by bribing them, for example, then I can game the system. I get the advantage of a large number of individual contributions, an advantage that should be inaccessible to a single person. Bribing people is clearly an abuse of the system, but what if I just send my friend some money that they can use to contribute however they want? This is a grey area:

It isn’t easy to decide exactly what should or shouldn’t be against the rules. So how can we address the problem of collusion in the next generation of quadratic funding systems?

Luckily, there’s a pretty clever way to help the system resist collusion: contributions can use MACI (Minimal Anti-Collusion Infrastructure, originally described by Vitalik Buterin here). A quadratic funding system using MACI can assure voters that their contributions are counted correctly, but it is impossible for them (or anyone else) to prove how much or to which projects they contributed.

If someone tries a bribe, there’s no way for the briber to confirm their bribe worked. The bribed donor can have their cake and eat it too: they are free to take the bribe and contribute however they like, free from outside influence. The only kind of collusion not impacted by MACI is fully trusted collusion: two friends who verbally agree to contribute to the same projects, for example.

Let’s look at the example from the tweet above: should two contributions from two different addresses that were funded by a single address count as a single contributor? This is a difficult question that doesn’t have an obvious answer in the current experiment, but with MACI, the two contributions can be safely counted independently, since you can be sure that any coordination between the two addresses was fair play.*

We’re using the MACI implementation built by Barry Whitehat in cl(ea)r.fund, and we hope to see other voting systems trying MACI out in the near future.


MACI is a new tool, and though it seems like it’ll be highly effective, it doesn’t yet cover every possible way to bribe someone, and it might be impossible to ever stop bribery completely. MACI also doesn’t address the problem of one person registering multiple accounts (i.e. a sybil attack). That problem requires a different solution and will be covered in another post.

* Note that with MACI, the two contributions must be counted separately, since there’s no way for anyone to tell if the two addresses in question contributed to the same project.