From the beginning, CLRFund was always intended to be a medium for allocating funds to Ethereum’s public goods, which also mirrored some of the core values of Ethereum: credible neutrality, decentralization, permissionlessness, trustlessness, and pseudonymity.
With this in mind, we’ve periodically run relatively small rounds over the past few years as a handful of contributors continue iterating on the full stack of systems that constitute CLRFund (form MACI, to BrightID, to Kleros Curate, to our own optimistic registry, subgraphs, and frontend). We’ve received an incredible amount of support from the Ethereum Foundation, Gitcoin DAO, MolochDAO, and the broader EThereum community, without which the project would not be where it is today.
Along the way, we’ve also been deliberate about building CLRFund in a way that makes it relatively easy for anyone to spin up an instance of CLRFund to allocate funds towards whatever category of public goods they like. We’ve seen rounds run to fund public goods in Honduras, allocating the prizepool at ETHDenver, and of course allocating 350K Dai to the Ethereum Staking ecosystem.
The latter of which brings me to my point.
We’ve been quite deliberate about scaling the value distributed in CLRFund rounds relatively slowly, since it sits at the confluence of several radical new technologies, many of which are unaudited and have not yet been battle-tested.
However, the 350k matching pool in the staking round marks roughly an order of magnitude increase in the funding trusted to the mechanism. Assuming all goes well with the round (no reason to expect otherwise at this point), this also feels like as good a mark as any to push CLRFund into its next phase.
To date, CLRFund has made a best effort to be credibly neutral, permissionless, and to be pseudonymity friendly. However, it is far from decentralized and is still quite trustfull.
With the staking round as a proof-of-concept for CLRFund being viable on an Ethereum L2 at a relatively large scale, now feels like the right time to push towards the canonical instance of CLRfund operating under the control of a truly decentralized and trust-minimized DAO, with the goal of fulfilling the original CLRFund constitution.
The goal of the instance of clr.fund described in this document is the allocation of funds to public goods that benefit the Ethereum Ecosystem according to the preferences of the Ethereum Community.
Below, I’ll outline my current vision for what that might look like.
Governance of what?
There is a canonical instance of CLRFund, that we hope can continue to grow as a schelling point for allocating funds to Ethereum’s public goods. This canonical instance of CLRFund has several
onlyOwner() functions and assets (like clrfund.eth) that must be controlled by a trusted address (to date, those functions have been controlled by a multi-sig of early contributors to CLRFund).
In practice, this means that the DAO must be able to own Ethereum accounts on whichever networks it holds assets and wants to run rounds (currently mainnet Ethereum and Arbitrum) and be able to trigger them to make any arbitrary function calls.
Proposed DAO Design
I’d like to start by acknowledging my obvious bias. I am about to suggest a design that is constructed of several pieces that I helped to design and/or build.
Consumptive Quadratic Voting seems best aligned with CLRFund’s outcomes. The most practical way to build this kind of QV in a way that can account for ETH consumed on multiple networks (initially mainnet, arbitrum, and optimism) is using a combination of Gnosis Safe, the Zodiac Reality Module, Poster, and a custom Snapshot strategy.
Consumptive Quadratic Voting
With the stated goal of the canonical instance of CLRFund being the allocation of funds to public goods that benefit the Ethereum ecosystem, Quadratic Voting (QV) feels like the natural choice to align incentives with the Ethereum ecosystem as a whole.
I say “consumptive” QV because, as I understand the mechanism, QV best reflects voter utility when the voice credit is money and is consumed by voting.
For the initial version of this, I would suggest that “consume” means to burn ETH. While I’d obviously like to reallocate that ETH to public goods, I think it’s safer initially to burn it so as to ensure there is a cost to capturing governance (if consumed ETH is collected by a contract that is ultimately controlled by governance, then a well capitalized attacker could potentially capture the DAO with close to no cost). A later version of this could be designed to reallocate consumed ETH.
On-chain, this could be implemented as a simple contract with one payable function
vote(string proposalId), where the
consume() function would burn any ETH received and call
post() on the Poster contract to emit the proposalId string as an event to be consumed by a subgraph and ultimately used as part of a Snapshot strategy.
While far from perfect, Snapshot has become one of the most widely used tools for aspiring and established DAOs. One reason for this is the ease of developing voting strategies.
For our purposes, we would want to build a Snapshot strategy and setup that:
- Weights votes quadratically
- Leverages BrightID for Sybil protection
- Reads data from multiple subgraphs to aggregate consumed ETH and vote preferences on each supported network
- A custom Snapshot plugin adds UI to consume ETH to be used as vote weight on a given proposal.
- Takes a snapshot at the close of each poll, to allow time for voters to consume ETH for a given poll.
Alternative DAO Design
It’s worth noting that one of the main reasons that most projects adopt Snapshot is because there is no gas cost to vote. Given that the above proposed design requires voters to spend gas to consume ETH for their vote weight, it someone negates the benefit of using something Snapshot, along with introducing complexity in the Reality module.
An alternative option could be to use some on-chain implementation of Quadratic Voting, like the Usul’s Member Quadratic Voting Strategy. The only constraint being that this would limit participation ot one network, which would almost certainly have to be an L2 in order to be cost effective.
I’d be open to pursuing either of the above options, keen to hear other opinions and suggestions on this.
It’s worth noting that in both of the above proposals, vote preferences would be publicly visible. To mitigate collusion, CLRFund has obviously spent a considerable amount of time ensuring that this is not the case for our QF rounds, so it is a shame to not take the same precautions for governance of the canonical round.
Ultimately, I would very much like to use a version of consumptive QV with similar collusion resistant properties as our QF rounds (more than likeey built on MACI). But in the interest of speed and practicality, I think this should be a goal for a future iteration of CLRFund DAO governance.