Clr.fund instances for ETHDenver tracks

general
#1

Hey clr.fund folks!

I’ve been coordinating with the ETHDenver team about using branded/white-labelled instances of clr.fund to pay out the prizepool for this year’s hackathon BUIDLathon. Here is a quick overview of the current plan.

  • There will be a separate instance of clr.fund for each track in the hackathon (Open and Impact)

  • There will be two rounds of voting. The first is done by the judges, and is primarily used to reduce the number of projects down to the hard cap of 125 that each instance of clr.fund can handle. The second is a clr.fund round.

  • We will use the simple registry contracts and manually add both recipients and users, based on lists that ETHDenver provides. (we may need a script to do this in a timely, and less error-prone, manor)

  • We will be the coordinators of the rounds

  • The rounds will run concurrently and will each last less than a day

  • The native token will be “SPORK”, a yet-to-be-created ERC20 token that serves as an IOU for Dai. (This is necessary for KYC purposes, otherwise we would just use wxDai like in our current rounds)

  • SPORK will be distributed to the judges to confer their vote weight in the round.

  • SPORK may also be purchasable via a vending machine contract at a fixed price in Dai, so that other hackathon participants can contribute to the round.

@xuhcc & @spengrah, do you see any issues with this plan? Is there any additional information you guys need to help make this run smoothly?

1 Like
#2

Good plan. Except for this item:

They can do that themselves. Documentation showing how to deploy and coordinate rounds can be found here: https://github.com/clrfund/monorepo/tree/develop/docs

#3

It’s less of an issue of them being able to do it vs having someone with the bandwidth to do it. I’ll check with them and see if there is someone on their end who is both willing and able. Worst-case scenario, I can do it.

1 Like
#4

Perhaps we can create some tools to make management of instances easier?
I imagine there will be many of them, like there are many Moloch DAOs.

#5

Yeah, @spengrah and I talked about this on the community call earlier this week. I think it’s a really good idea and could definitely help to create a thriving ecosystem.

The two admin tools we discussed were:

Clr.fund Instance Factory

  • Easy tools and instructions to spin up your own branded instance of clr.fund
  • Easy tools and instructions to run your own coordinator
  • Analytics

Coordinator as a service

  • As the ecosystem of clr.fund instances develops, there will be an opportunity to run a coordinator-as-a-service (CAAS). This could be a revenue stream for clr.fund.
  • One way we might make this less trustful (or at least change the trust assumptions) is to create a coordinator locked in a TEE (trusted execution environment). So, assuming they trust the TEE, users can be sure that even the coordinator cannot know the votes.
#6

That could be a good starting point. I created the issue: https://github.com/clrfund/monorepo/issues/267

Ideally the party that provides matching funding should also coordinate the rounds. In that case incentives are well aligned and fancy anti-collusion mechanisms are not needed.

1 Like