Is it time to make a DAO to own the canonical instance of CLRFund?

general
#1

CLRFund DAO

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.

TL;DR

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.

Snapshot

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.

SafeSnap

Snapshot is an off-chain voting tool. In order to trustlessly bring those results on-chain, we can use SafeSnap (the combination of Snapshot, the Zodiac Reality Module, and a Gnosis Safe).

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.

Anonymous Voting

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.

1 Like
#2

Since a few folks have independently pointed out some confusion, I just want to be very explicit.
This is not a proposal to change anything about the way that clrfund works. The software stack wouldn’t change; it’s still MACI under the hood.

The proposal is to create a DAO that can more meaningfully decentralize the address that is set to owner on the funding round factory of a canonical instance of CLRFund.

There is also no suggestion of creating a token for this DAO. It is proposed as an Ethereum ecosystem DAO, and the Ethereum ecosystem already has a token, ETH.

1 Like
#3

Gnosis Safe is a good option, snapshots don’t require gas fees and can be abused unless we have our own governance token, which of course is another issue.

#4

Appreciate you Auryn. Glad you’re thinking about reducing trust requirements & pushing for CLRFund’s sustainability.

A few questions about this proposal…

1) What actually is the “canonical instance of CLRFund”?

Are you referring to smart contracts that have already been deployed? Are you talking about control of the CLRFund GitHub repo? I understand many contracts are Ownable & you’re referring to who is the “owner”… but ultimately anyone can fork & deploy CLRfund, making them the owner of that given factory (& by default the rounds deployed from that factory).

2) What kind of proposals do we expect to see?

What will community members spend money to vote on?

  • Adding/removing address from the owner multisig?
  • Deploying new factories to new networks (e.g. new L2s)?
  • Deploying new rounds from existing factories?
  • Initiatives with / priorities of further dev of the CLRFund protocol?

Given that anyone can fork the stack & deploy their own instance, what gives the DAO power? Controlling funding rounds that are endorsed by orgs who contribute matching funds?

3) Why burn ETH?

Perhaps this would reduce the risk of governance capture - no token treasury to take over - but what about the risk of no incentive to govern at all?

Why do we think people will be incentivized to contribute in governance? There’d no token treasury to allocate anything towards. Is it projects (funding recipients) who are motivated to see more rounds run? Or do you expect a DAO treasury to develop, e.g. by CLRFund participating as a recipient in funding rounds?

Why not issue a governance token to the community? Would previous round recipients/users/contributors make better shepards of this project moving forward than any ETH holder? ETH burn may be easier to set up but ultimately seems to be a similar risk to capture than a fungible governance token (i.e. whales can buy power). As long as QV is applied it seems distributing voice credits based on previous proof of participation seems like a decent start.

4) Why multi-chain?

Could we start the DAO simpler, e.g. on a single L2? If the governance power is ultimately about addresses controlling the owner multisig, wouldn’t the list of addresses transfer across networks? Or each network must be independently configured?

My gut suspicion is the work/complexity to support multi chain from day one is overkill. It’s unproven how much interest there will be in burning ETH to impact governance over the canonical protocol. Again, everything here is forkable at the end of the day.

I think there is a case to be made on establishing a multi-chain approach from the get-go so I’m open to arguments here.

#5

@Daodesigner also raised a good point in the Telegram group - what about the Colony DAO? Is the Colony not fit to handle this? Or is part of this proposal to terminate the Colony DAO?

#6

When I say “canonical instance of clrfund”, what I really mean is an instance of clrfund deployed to fulfill the clrfund constitution. In practice, that means the the instances that have been run, and will presumably continue to run, at clr.fund / clrfund.eth.

To date, those deployments, the ENS name, and the matching funds have been controlled by a multisig. What I’m suggesting is that it might be beneficial for governance of this instance to be more decentralized.

Of course!

I am confident we’ll see a diverse ecosystem of clrfund instances, each with their own identity, focus, configuration, and governance.

I don’t think this DAO could, nor would I want to, have any control over those other instances of clrfund.

My intuition is that this DAO should be mandated with essentially being the owner of the funding round factory and the matching pool, so taking on or delegating any associated responsibilities. I don’t think this involves deciding how to spend any money or allocate developer resources. But, as you suggested, it could include things like:

  • deploying new rounds
  • deciding on which network/layer to run rounds
  • setting an allowance from a matching pool wallet to the funding round factory
  • adding funding sources to the funding round factory
  • appointing coordinators
  • deciding on recipient acceptance criteria and recipient registry type
  • deciding on user registry type
  • deciding which version of the app to use
  • Updating ENS content
  • delegating control of some functions (for example, the DAO might delegate control of executeRequest() on the optimistic recipient registry to some faster moving sub-group that can handle incoming requests in a timely manner)

This is a tricky one! Obviously I’d prefer for it to be reallocated to public goods, but burning feels like a safer first step in this direction (simply because burned ETH is a guaranteed cost to any attacker). Practically, burning is similar to proportionally reallocating to all ETH holders. Although it’s perhaps a little harder to swallow :sweat_smile:. That said, EIP-1559 has probably warmed a lot of people to the benefit of mechanisms that burn ETH.

One common objection that I have heard to this type of consumptive QV (regardless of whether on not it is reallocated) is that people operate under the assumption that they must burn significant amounts of ETH to be impactful. Similar to how we inform people that even a small contribution (a dollar or less) to a project you value in a QF round will have an outsized impact on the outcome of the round, a small amount burned in QV will have an outsized impact on the outcome of a vote.

The amount you contribute in QF / consume in QV should be proportional to your utility in changing influencing the outcome.

Assuming consumptive QV, the incentive to govern (the amount of ETH you’re willing to burn to cast your vote on a given proposal) should be proportional with your utility in the outcome of that proposal. In theory, this should align the DAO with Ethereum’s public goods.

They would definitely be one group of motivated participants. I’d suggest that anyone who is motivated to participate in a clrfund round in any way (recipient, contributor, matching pool donor, and really anyone interested in perpetuating Ethereum’s public goods) would be similarly motivated to participate in governance of this DAO.

I’m not confident that this would align incentives well with Ethereum’s public goods. Rather, it would probably align incentives with the public goods of those token holders.

Ultimately, I think this should be governed by stakeholders in the Ethereum ecosystem, and I think that group is much larger that the group of people that have participated in previous clrfund rounds.

Consumptive QV with burned ETH feels to me like the most reasonable way to distill the preference of stakeholders in the Ethereum ecosystem into a relatively simple vote weight.

Yes, I think we could start with a simpler design. I thought about this immediately after writing out the Snapshot design, after realizing that there is less benefit to using Snapshot if you must still consume gas to cast a vote. This is why I also included the “alternative DAO design” which would presumably run on an L2.

The case for multi-chain was really to allow users to chose which network they wanted to consume their ETH on. But I think it’s perfectly reasonable for the DAO to be opinionated on this, since it’s relatively easy to move ETH between networks / layers. So I think I lean more towards a simplier design at this point.

That said, this DAO probably still needs to be able to control assets on multiple networks, but that’s relatively easy to build and is probably out of scope for this thread.

The codebase is forkable, but there are a bunch of pieces to this that are not so easily forked. Things like the matching pool and network effect of an established instance. People should absolutely spin up other instances of clrfund for whatever reasons they want, but I don’t think that negates the benefit of establishing sound governance over the canonical instance.

I see the colony as fulfuling a different purpose to the DAO I’m proposing here. I’m definitely not proposing that we terminate the colony.

The colony’s function is to reward and incentivize the people building the clrfund protocol, app, and community.

The function of the DAO I proposed in this thread is to govern a canonical deployment of clrfund in accordance with the clrfund constitution.

Perhaps “canonical” is just the wrong word for what I’m describing here. The intent is not to king-make this instance or to discourage other instances. It’s simply a conscious acknowledgement that QF rounds benefit from network effects and that some parts of an instance of clrfund are not easily forkable. So, again, when I say “canonical instance of clrfund”, what I really mean is an instance of clrfund that we (the Ethereum ecosystem) has decided is fulfilling the constitution and is worth rallying around.