Oracle-based recipient curation

general
#20

Categories like ‘honest’ and ‘correct’ rarely apply in our use case because the answer to question about whether something is public good or not is mostly subjective. When someone submits a project to the TCR and another person challenges this submission we only have two opinions. In most cases both sides are honest. And Kleros is really good for resolving such disputes because it gives feedback immediately and the losing side don’t lose much.

Yes, in escalation game it is likely that one side will eventually give up, but not because they are dishonest or wrong but because there’s no certainty in arbitration outcome and they don’t want to lose a lot of money.

1 Like
#21

I’d argue that this is the mechanism doing it’s job correctly.
If you do not believe that arbitration will rule in your favour, then you shouldn’t play the escalation game.

Essentially, because of the arbitration option, there is a financial disincentive to set the outcome to anything other than what you believe arbitration would resolve it to. In the vast majority of cases, this means that the outcome is only set once, never doubled, and arbitration is never called.

More than likely, the nuance is in setting the arbitration price high enough that it justifies the gas cost, but low enough that it’s still affordable to most individuals.

#22

(Jimmy from Kleros joining the thread here.)

I agree that the more subjective your question is, the less well an escalation game backed by Kleros will work compared to just using a direct application of Kleros.

As I replied to Auryn on Twitter, we’re open to deploying a version of Curate on xDAI (with arbitration going straight to mainnet with no escalation game). It seems workable for clrFund because the rate of submissions being flagged for arbitration is not too high.

Our current mainnet<>xDAI proxy is using proxies specific to Reality.eth/omen use cases, but we can either customize them for Curate or generalize them. I’ll give you more details once we discuss it internally tonight.

When is the next CLR fund round?

2 Likes
#23

Great!

I guess it will start somewhere around March 5-7.

#24

My main concern with this approach is that the barrier to entry is still quite high because each submission needs a bond that is high enough to cover the cost of arbitration in the case that someone does challenge, otherwise there is an economic disincentive to challenge projects. At the time of writing, this means that each submission would need a bond worth several hundred dollars.

Reality provides a nice way to lower the barrier to entry as the initial bond just needs to be enough to disincentivize spam and incentivize someone to change the answer for projects that they don’t think meet the acceptance criteria. On a network with cheap gas (like xDai or a rollup) that bond could be just a few dollars.

#25

Moving Curate to xDai as-is would at least spare the grant creator and/or challenger the non-retrievable gas fees which are already close >$100 at a gas price of 150 gwei.

I understand the need to lower the initial bond but our experience and user research on “The Challenger’s Dillemma” shows that if the challenger bounty too low, and it would be too low starting with bond escalation , incorrect submissions will not be flagged for dispute.

We’re diving more into this dilemma in the “The Submission Challenge Bounty” section of this post and here.

We are of course currently working on selecting which L2 we would deploy our Court V2 on this year but it’s more likely to be a rollup than xDAI. So, in the meantime, the hybrid solution of Curate on xDai and Court on mainnet seems the most appropriate in the short term.

Let’s set up a quick call this week to discuss this more deeply if needed.

2 Likes
#26

But what is “too low”? My assumption is that there is some significant breathing room between enough to incentivize someone flagging for dispute and enough to cover the arbitration and gas costs (especially at the 100-1,000 gwei range of late).

There is no reason that the registry could not require a minimum bond size, even if Reality does not. So any attempts to add a recipient on Reality with a bond lower than the minimum would just result in the item not being added to the list.

#27

I’ve implemented the proposed optimistic recipient registry. There’s no UI yet, only contract. See PR description for details.

The process of reviewing recipient’s registration request may involve some formal procedure. For example, the decision can be made using a poll, and then the multisig will enforce the outcome.

Preparing for xDai funding round 05
#28

Oh nice! This is really cool.

It would be great if there was an updateRecipient() function, so that you didn’t have to remove and then add a new recipient to update.

A nice-to-have feature would be if there was a way for parties to resolve disputes before calling arbitration.

Recipient data storage
#29

This function can be added, but it won’t work for all types of registries. For example, Kleros TCR doesn’t allow updates.

For each request, there are only two parties: requester and registry owner. The registry owner is more like a gatekeeper than arbitrator.

I see this contract as a temporary solution until we find something better. It is deliberately made very simple, so that it could be used in Round 05.

#30

Actually, I had a call with the folks from Kleros late last week, they are planning to add this functionality very soon.

Yeah, I think that this is a fair compromise.

Kleros is planning an xDai deployment of curate, that will bridge back to mainnet for arbitration, via the AMB.

So perhaps this will be an option for round 6, depending on whether round 6 happens in xDai or a rollup. I’m hopeful that we can migrate to a rollup by then though, so we may still need a different solution, unless a similar Kleros curate setup is also deployed to whatever rollup we choose.

#31

I deployed a new recipient registry to Rinkeby: https://rinkeby.etherscan.io/address/0xd1bFd2Fe7C928e3C1E87c52832977dEde26B58D0#code. Deposit amount is set to 0.1 ETH and challenge period duration is 1 hour. The contract is verified on Etherscan so addRecipient() and executeRequest() methods can be called via their UI. Recipient ID can be found at ‘Events’ tab: it is the value of topic1 of RequestSubmitted event.

There’s a test round that will run for 1 day: https://ipfs.io/ipfs/QmfAJKeiUSmFU2quAYRM3rfKQXNS7B5qGWorzU7Cq4NCVG/

1 Like
#32

Started to work on a simple GUI for optimistic recipient registry: https://github.com/clrfund/monorepo/issues/295
In the beginning, it will be used as a place where recipients can submit their project for review. Over time it could evolve into fully featured GUI for interacting with different types of registries (e.g. Kleros TCR).

1 Like
#33

This is really cool!

I submitted an item to the list on Etherscan to test it out.

1 Like
#34

Clrfund UI now has ‘Registry’ page where anyone can add funding recipients: https://ipfs.io/ipfs/QmTfzXhVnfG6Txseh2eokQ1YMJTkRnHTtWtig8tdjrgX33/#/recipients

1 Like
#35

Nice work @xuhcc! Just tried submitting myself to the registry.

The information architecture doesn’t seem quite right to me. Is there a reason that you chose to make a “registry” page, rather than just including these items in the “projects” view?

It seems that the information on the registry page could be included in the modal that pops up when you hit the “submit project” button. That button could be on the “projects” page. And we could have some visual distinction, and/or filtering, for items that are pending / rejected / accepted.

Perhaps this should be broken out into another topic, but I wonder if we should reconsider the items in the left side navigation, since it’s getting a little cluttered over there now.

image
image570×1054 19 KB

@markop, what is your opinion on this?
We could probably move “about”, “blog”, “forum”, and “github” to somewhere else, perhaps a row of social icons somewhere on the page.

image
image1620×463 20.1 KB

#36

Pending and rejected items (which are actually registration requests) should not be displayed in the main project list because it is not possible to contribute to these projects. Removal requests cannot be presented as projects at all. In the future, there could be a third type of request, for updating project metadata.

I think only those projects that have made it through the challenge period should be shown in the main project list (we already do that for accepted Kleros TCR items). This will be implemented at some point.

1 Like
#37

I see your point about rejected items, but I do think that pending items could potentially be included in the list (visually distinct with an inactive “contribute” button).

Is this because you can’t removed a project from the current round?

I do see the value in having a feed-like view where you can see all of the past and pending state changes to the list. But like I said earlier, it currently looks a little cluttered and feels like it could be made more clear. Still not sure what that looks like, but I’ll think on it some more.

#38

FYI, Kleros Curate is now available on xDai: https://curate.kleros.io/tcr/0x2442D40B0aeCad0298C2724A97F2f1BbDF2C2615

#39

Oh nice!

Thanks for the heads up.

Not sure if we’ll run the next round on xDai or not, but if we do then maybe we explore reverting back to the Kleros registry.