Preparing for xDai funding round 05

I’ve deployed a new set of contracts to Rinkeby. This clrfund instance is configured to use simple user registry and optimistic recipient registry. The address of funding round factory contract is 0x65680422D10f16f2909A8805CB1CCb2eCAB8437B.

Important changes (since the previous deployment):

  • MACI 0.6 (more robust, includes several security fixes)
  • New zkSNARK circuits that can handle up to 511 contributors, 8192 messages and 125 recipeients.
  • Fixed issue with project registration being broken due to smaller block time on xDai chain.

There’s a test round running:


Here’s a list of things that need to be decided before launching round 05:

  • What recipient registry to use, dummy Kleros TCR (used in round 04) or new ‘optimistic’ recipient registry?
  • If optimistic registry is chosen:
    • How it will be curated? The registry owner will need to decide whether to deny registration request or not. Perhaps there should be some formal decision-making process, like voting or discussion on the forum.
    • What should be the size of security deposit and challenge period duration?
  • What xDai node to use? Currently clrfund uses the public node but it is not very reliable. Other options are and
  • What GunDB instance should be used? Currently clrfund uses one GunDB instance running on Heroku free dyno. It may lose data because it does not provide persistent filesystem.
  • Amount of matching funding. I’d recommend a smaller matching pool because of a major MACI/clrfund upgrade.
1 Like

I’d be open to trying out the optimistic registry this round. Assuming that the owner current owner multisig is the owner, then the trust assumptions are not really any different to the dummy Kleros TCR that we’ve been using.

I’d be in favour of leaning on the forum for this.
If you want to challenge an item, create a post in the #tcr category, including a poll on whether the project should be denied

Here is a poll template.

[poll type=regular results=always public=true chartType=bar]
# Should {recipient} be denied from the registry?
* Yes
* No

Ultimately, it will be up to the multi-sig owners to honor the results of the poll. But I think this is an acceptable compromise until at these values and until a version of Kleros Curate is available on xDai.

My suggestion for security deposit is ~$20, so that’s 20 xDai if we are deploying to the xDai network.
This is totally me shooting from the hip, but it feels low enough that it shouldn’t be a deterrent for legitimate projects while being high enough to stop spam and be a little sting for illegitimate submissions.
The challenge period should be 72 hours. That should give us enough time to notice the submission, run a poll, and execute the denial transaction.

I didn’t find the quiknode option to be much more reliable for processing messages, but it did seem to be more stable for running the round. I haven’t tried pokt network yet, but I’d be open to it. Ideal case would be to allow the user to select from one of several nodes, with the option to use a custom node.
With the latest EF grant, we have some funds to cover infrastructure.

Yeah, let’s set up a more persistent VPS for this. Again, the latest EF grant can cover this. That said, at some point I would like to find an option that doesn’t rely on us running a server.

I agree. Perhaps we drop it back to $1,000 for this round and shorten it to one week?

1 Like

Gun is a peer-to-peer distributed database, so technically it’s not a server but a “superpeer” that helps other peers sync with each other when they don’t know how to connect directly (for example if they are running in browsers).

GunDb readme suggests several options for easy deployment:

Yes I think that would be optimal.

1 Like

GunDb readme suggests several options for easy deployment:

@proofoftom, could you get a gun server up and running on now/vercel?

We’ll need a persistent server for this, now/vercel doesn’t support such anymore. Will take a look at using the 1 click Heroku environment.


I’ve started another round on Rinkeby ( Let’s test it one more time before running in production.

If there are no objections I’ll set up a clrfund instance on xDai, identical to the Rinkeby instance but with 20 xDai security deposit and 72-hour challenge period for recipients.

Perfect! Thanks @xuhcc.

Perhaps clrfund needs a removal policy document in addition to the listing policy. Some reasons for removal that I could think of:

  • Recipient does not meet the requirements of listing policy anymore (e.g. their project has been privatized).
  • Recipient does not want to participate in QF rounds.
  • Recipient wants to update project metadata (currently project needs to be removed and re-added with different metadata).
  • There is an evidence that recipient tried to bribe contributors.
1 Like