Let's talk about recipient curation mechanisms

[xuhcc]

This won’t work well unless metadata format is enforced by ENS dapp. There will be too many mistakes as with image size requirement. Also ENS names are not free, so this would create another hurdle for recipients.

But we can add optional ENS name field to Kleros registry. That would be much better that twitter handle.

[xuhcc]

@xuhcc

If we want to protect clrfund against this, the ranking mechanism is needed. We can implement our own or use something like Conviction Voting. Unfortunately it will make it a bit harder to become a valid recipient.

I think the most important metric for ranking public goods is amount of funding received via QF. Ideally this data should come from clrfund itself, so we need to implement our own ranking mechanism (which will work independently from curation mechanism such as Kleros TCR).

The very basic version of ranking mechanism was implemented in SimpleRecipientRegistry contract and is currently used in production. It divides projects into two categories: valid and invalid (removed). When the total number of projects in the registry reaches the limit and the owner adds a new project, the smart contract replaces one of invalid projects by reassigning its index to a new valid project.

We can use this logic to create a ranking mechanism that uses the amount of funds received during the last N rounds as an input.

1. New project replaces old project that didn’t collect any funds during the last N rounds. It’s easier to implement but at some point all non-receivers will be removed and it will be impossible to add new project.
2. New project replaces old project that received the smallest amount of funds during the last N rounds according to on-chain data. Such mechanism can work indefinitely, but it requires on-chain sorting which is hard to do and gas-intensive. I think it requires some advanced data structure like binary search tree. Example of solidity library: https://github.com/saurfang/solidity-treemap.
3. New project replaces old project that received the smallest amount of funds during the last N rounds according to the oracle. In this case the sorting is done offchain and to replace the least popular project someone needs to submit a replacement request (usually it is someone who wants to add a new project). The replacement request can be disputed in decentralized court and if jurors rule in favor of the requester, the project gets replaced.

I think option 3 is the best but it’s probably not necessary today. If we increase the vote option tree depth in MACI by 1 it will allow 625 recipients which should be enough for the foreseeable future. For now we can use a simpler ranking mechanism that relies only on validity (similar to SimpleRecipientRegistry, but integrated with Kleros TCR).

[auryn]

@xuhcc

There will be too many mistakes as with image size requirement.

It’s really only an issue currently because of the friction of changing it. If we use text records on ENS domains, then it’s trivial for users to change those records if they make a mistake or something renders poorly. At some point, we can even build this into our UI.

@xuhcc

Also ENS names are not free, so this would create another hurdle for recipients.

This is valid, but given that there are a number of places where you can get free ENS domains I don’t think it’s really that much additional friction.

@xuhcc

But we can add optional ENS name field to Kleros registry. That would be much better that twitter handle.

Perhaps we add an ENS field and make the address field optional as well, but require that at least one of them be filled. I’d prefer for an ENS name to be the default.

[xuhcc]

We can use TCR as a fallback data source. If there’s an ENS name, we’ll try to fetch project description from it, otherwise we’ll read it from TCR. This would allow projects to easily update their descriptions without removing and re-submitting their entry to TCR, while they will not be forced to buy and configure ENS.

@auryn

Perhaps we add an ENS field and make the address field optional as well, but require that at least one of them be filled. I’d prefer for an ENS name to be the default.

Yes, that makes sense.

[xuhcc]

@xuhcc

A simplified version of TCR could have API similar to Kleros Generalized TCR but actually be a simple registry managed by a trusted party. For that simplified version of TCR we can create an adapter which we can later reuse with real TCR on mainnet.

The adapter will be a simple registry integrated with Kleros TCR. To add recipient someone will need to call addRecipient() with TCR entry ID (this method can be called by anyone). The registry contract reads recipient data from TCR and decodes recipient address, then it assigns a vote option index to recipient. If the number of recipients reaches the limit, a simple ranking algorithm is used to find a place for a new recipient:

@xuhcc

The very basic version of ranking mechanism was implemented in SimpleRecipientRegistry contract and is currently used in production. It divides projects into two categories: valid and invalid (removed). When the total number of projects in the registry reaches the limit and the owner adds a new project, the smart contract replaces one of invalid projects by reassigning its index to a new valid project.

This adapter is designed to work with Kleros TCR on mainnet but on xDai we can deploy a dummy contract that pretends to be a Kleros TCR and use the same adapter with it.