Summary: clr.fund is best understood not as another grants frontend, but as an attempt to turn quadratic funding into a credibly neutral protocol by hardening the most manipulable surfaces: collusion, bribery, sybil attacks, and recipient curation. Its reusable mechanism is the combination of MACI-based private vote aggregation, modular identity and registry layers, and a round factory that separates matching-fund custody, contribution flow, tallying, and recipient admission. That makes it a useful comparison class for Gitcoin-style quadratic funding, Octant, Kleros-curated registries, and other systems where the hard question is not whether quadratic funding sounds good in theory, but what trust assumptions remain once a real operator has to run it.
What it does:
Runs a continuous sequence of quadratic-funding rounds where contributors fund individual public-goods recipients and matching funds are added separately to a pool
Uses MACI to hide contribution details during the round and reduce bribery / collusion opportunities through private message aggregation and zk-SNARK-based tallying
Requires uniqueness verification for contributions to count toward matching, with BrightID named in the docs as the reference anti-sybil system and room for similar identity systems
Supports recipient-admission and curation layers, including Kleros Curate-style mechanisms and an optimistic recipient registry in the contract stack
Separates roles across owner, coordinator, contributor, and recipient rather than pretending a single contract fully removes governance or operator power
Lets approved funding sources provide matching funds via ERC-20 allowance, making the protocol compatible with DAO treasuries, benefactors, or other recurring funding sources
Can run on EVM-compatible chains and be hosted on IPFS, positioning it as deployable funding infrastructure rather than one fixed canonical instance
Key claims:
The monorepo README describes clr.fund as a permissionless and trust-minimized quadratic funding protocol for public goods, explicitly naming MACI, zk-SNARKs, and anti-sybil identity checks as core design elements rather than optional extensions
The constitution is analytically important because it states the project’s ambition in governance terms: credible neutrality, permissionlessness, trustlessness, decentralization, pseudonymity, and resistance to collusion, bribery, blackmail, griefing, and sybil attacks
The same constitution also narrows scope in a revealing way: this instance is aimed at allocating funds to public goods that benefit the Ethereum ecosystem, but the protocol is intended to be deployable by other communities as their own allocation rail
The protocol architecture still exposes a real trust bottleneck. The README and tally docs make clear that a coordinator is responsible for decrypting MACI messages, generating the zk tally, and finalizing the round pipeline; the project explicitly acknowledges that this trusted role remains a prime bribery target without better oblivious-computation tooling
The funding-source docs show that matching-fund logistics are not abstract. Approved funding-source addresses grant ERC-20 allowance to the ClrFund contract, which then pulls funds into the matching pool at round end; this is a concrete treasury-integration mechanism, not just a donation button
The tally-verification docs are a strong primary-source signal that clr.fund is trying to make operator trust auditable even if not fully eliminated: only the coordinator can tally, but anyone can later verify the published tally.json
The README’s limitations section is worth preserving because it is unusually candid: clr.fund openly notes both the trusted-coordinator problem and the single-token constraint, showing where the protocol is still operationally narrower than its neutrality ambitions
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official site, the monorepo, and the constitution; see ../whitepapers/clr-fund-primary-sources-2026-05-09.md.