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.
Some helpful blogposts to explain the clr.fund project:
- https://blog.clr.fund/clr-fund-explained-pt-1/
- https://blog.clr.fund/clr-fund-explained-pt-2/
- https://blog.clr.fund/clr-fund-explained-pt-3/
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.
- Running clr.fund instance
- Providing matching funds
- How to tally votes
- How to verify results
- Running the subgraph
- Deployment
nvm install 12
nvm use 12If using the M1 chip in Apple products, you need to use Node v16.
nvm install 16
nvm use 16yarn
# Along with the dependencies, git hooks are also installed. At the end of the installation, you will see the following line after a successful setup.
husky - Git hooks installedcp contracts/.env.example contracts/.env # adjust if necessarycp vue-app/.env.example vue-app/.env # adjust if necessaryIn one terminal, init the hardhat node
yarn start:nodeIn a 2nd terminal you will need to run your graph node (more on this here)
# go to the thegraph repo directory and init the node
cd graph-node/docker
docker-compose upAnd finally, in a 3rd terminal
# this will complie and deploy the contracts + deploy the subgraph + build and run the vue app
yarn start:devyarn build:contractsyarn testyarn start:webyarn lintPrettier is executed on the staged files to keep a consistent format style across the codebase.
yarn test:format and yarn test:web is going to be triggered to ensure that
the code is in good shape.
As you can see, we are only checking the web (/vue-app) tests and not
the contracts ones. This is because there are not changes very often in the
/contracts folder. However, if you do make a change in /contracts don't forget
to run yarn test or yarn test:contracts.
/contracts/vue-app
As a recommendation, use the Vetur extension. It gives you some useful features for Vue like syntax highlights, autocomplete, etc.
Create a vetur.config.js file at the project root with the following content:
/** @type {import('vls').VeturConfig} */
module.exports = {
settings: {
'vetur.useWorkspaceDependencies': true,
},
projects: [
{
root: './vue-app',
package: './package.json',
tsconfig: './tsconfig.json',
globalComponents: ['./src/components/**/*.vue'],
},
],
}