clr.fund is a permissionless and trust-minimized Quadratic Funding protocol. It uses Minimal Anti-Collusion Infrastructure (MACI) to protect against various forms of bribery and collusion with the use of zk-SNARKs. To protect from Sybil attacks it can use BrightID or a similar identity system.
clr.fund runs a continuous sequence of Quadratic Funding rounds, where anyone is able to add public goods projects as funding "recipients", contribute funds to the matching pool ("matching funds"), and contribute funds to individual recipients. To ensure that only public goods are added as recipients clr.fund can use curation mechanism such as Kleros Curate.
While clr.fund aims to be agnostic to the source of matching funds, it specifically aims to enable contributions from the following sources:
- Ethereum protocol rewards (Block rewards, transaction taxes, etc)
- Known and anonymous benefactors
- Benevolent protocols (MakerDAO, Burn Signal, etc)
In order for their contributions to count towards matching, contributors must verify their uniqueness.
The clr.fund smart contracts consist of a factory contract that deploys a new contract for each round. All matching funds are sent to the factory contract, while contribution funds are sent to the current round's contract. There are four roles in factory contract:
- Owner: This address (initially set to deployer) can set the address of coordinator, finalize a round by transferring matching funds to the current round contract, and set the token and round duration.
- Coordinator: This address is responsible for running the zk-SNARK computation on contributions to produce the relative percentages of matching funds that each recipient should receive. The coordinator can quit at any time, which invalidates the current round forcing the owner to start a new round and users to submit new MACI messages for their contributions. Without some advancement in oblivious computation, this Coordinator is necessarily a trusted party in this system (this is discussed more in the Limitations section).
- Contributor: Any address that contributes tokens to the funding round.
- Recipient: Any address that is registered as funding recipient.
The clr.fund application can use any EVM-compatible chain as a backend. The application can be hosted on IPFS and can also run locally.
For more details, see the sequence diagram and clr.fund constitution.
There are various limitations in our current design; we discuss some of them here.
The need for several trusted parties is the biggest limitation in the current design. The owner could, and likely will, be replaced with a DAO or some other decision-making mechanism which could alleviate the trust concern for this role.
However, without some breakthrough in oblivious computation, the zk-SNARK computations must necessarily be done by some trusted party who becomes a prime target for bribery as they are the only participant who can know the details of each contributor’s contributions.
Several solutions have been suggested, such as having the operator’s private keys and computations happen inside of some trusted computing environment or wallfacer-esque isolation of the operator. But most just kick the trust-can down the road a little further.
For simplicity's sake in the contract, the zk-SNARK, and the user interface, clr.fund selects an ERC20 token as it's native token (set by the contract owner), which is the only token that the funding round contract interacts with. This is an issue given our goal of being agnostic to the funding source.
For example, block reward funding would be in ETH, while many users may want to contribute DAI or other ERC20 tokens.
In a future version, we plan to address this by routing ETH and token contributions in anything other than the current native token through a DEX such as UniSwap.
nvm install 12
nvm use 12
yarn
yarn build:contracts
yarn test
yarn start:node
and in a new terminal
cp vue-app/.env.example vue-app/.env # adjust if necessary
yarn start:dev
yarn start:web
yarn lint