Token Curated Registry pattern

There is a need in lists and registers of items in decentralized world. From discovery lists to lists of people and items.

At the same time they need “governance”: some form of management and making sure that malicious, inappropriate.

There is a pattern of Token Curated Registry. It didn’t become much used on Ethereum as it was too expensive and not fully matching.

On NEAR there is more opportunity to use it.
Also there has been more innovation on governance in general. Let’s figure out how can we evolve TCRs in NEAR case.

Let’s start with that TCR has a governance token (further denominated as $TCR) of the registry that allows to add, update or remove items. In some form this is similar to a DAO where their goal is to manage the .

It’s important that this governance token can be just delegated, as it become clear that most people won’t actively be participating in the governance. It’s also pretty clear that governance pooling will be happening, where

Adding item

Submitting a new item to the registry requires staking some amount of $TCR token. $TCR token should be freely floating with some liquidity to make this a permissonless system.

There can be two ways:

  • Existing $TCR holders are voting to include
  • Existing $TCR holders “veto”

Either way, at the end the item either gets included or excluded from registry after some staging period.

Updating item

Can submit an update also with a stake. This can be done by anyone, not just author.
For author, this can be made cheaper.

Same challenge period waiting as for adding applies.

Removing item

Sometimes items expire and should be removed. Same thing as updating item - author can remove at any time, others need a bond and wait for challenge period.

Delegation

A $TCR holder can delegate their current full or partial vote to other members.
Because of the problems with computing 2 way delegation (computation is just too complex for on chain), if someone wants to be delegated to - they need to register as a “delegate”. Then they can be delegated to but delegates can’t delegate themself. Delegates can add meta data about themselves via name.near meta data contract contract which various frontend can show.

Delegates can be managed naturally either by individual account or another contract (on NEAR there is no difference). This for example can be multisig, DAO or any other arbitrary contract that decides for example based on results of previous vote.

Earning TCR

Authors of added items start to accrue the $TCR token. It’s similar to “liquidity mining” expect list mining.

Active delegates should earn $TCR themself, as they actually provide value to the registry. For example if explicit voting is required - $TCR is earned for participation (and lost if skipped voting?).

Factory

Ideally TCR can have a factory that allows to create new ones easily by any end user via UX.
Then there is a general UX for viewing/adding/voting and can be specialized UXs for managing a more specific versions (like NFT TCR that pulls more data about the NFTs into interface).

Questions

  • One token == one vote is clearly not great. Various delegation provides a bit better way to accumulate votes by more active members, but still presents potential dangers. Are there better ways to organize this?
  • Freely floating token can lead to speculators buying out all the supply and artificially increasing price. There is obviously always a way to fork the contract but as there is more state and integrations of TCR it will get harder and more expensive to do. Another way is TCR itself managing somehow the price of the token by either selling it off when price is too high or buying back?.. This sounds like stable coin mechanics %)
5 Likes

Nice! I think this is a super important primitive. I’m not 100% sold on the traditional incentives for TCRs though and I’m skeptical of token voting being the best method for governance.

I’ve been thinking in terms of reputation that curators can earn for participating in curation. In Everest reputation is how long you’ve been on the registry. Pretty simplistic. But if you have people that are inherently motivated to curate the registry it could work.

The issue with TCRs I think is that the friction of the traditional incentive model has been too high for the benefit. You have to do a lot of work in the hope that some day it turns into something useful but mostly it just turns into bad ponzis…

So for me I like approaching the problem from a perspective of assume you have this goal and people are inherently motivated to do it. How do you design a game that’s maximally simple that allows them to coordinate on achieving the desired results. And then I think of layering on bigger incentives at a meta layer…

Don’t really have strong conviction one way or another… but the main learning is the interactions have to be really simple and there has to be an inherent desire to curate the list.

4 Likes

Agree, I think starting with $TCR token non transferrable and treated like a reputation initially.

To allow for adding new items - instead of staking $TCR to add -> staking a bit of $NEAR (for anti spam) is enough - it’s actually naturally happens on NEAR to cover for storage.

Later, when this system is successful, governance can vote to allow transfers of the $TCR token if there is need in that.

2 Likes

Yes that sounds perfect. The goal of the reputation system should be assess who is contributing most productively to the list. We can assume to start that people are inherently motivated by reputation and in having a useful list. We should still assume that malicious people will seek to add their own bad items to the list though.

You can checkout the Charter we wrote for Everest. It’s a simple system but has proven quite effective. It has a listing fee, challenges, and supports delegation. I can share some improvements we’d make to make to the reputation system and rules.

It’s worth starting with a list that would provide ongoing utility to the crypto community and is relatively achievable. How about starting with a list of events? This could become the definitive event calendar for the crypto space, including meetups, conferences, etc.

3 Likes

There have been several centralised and decentralised token registries in the past.

The problem is many sided

  • Startups can’t get their tokens to MetaMask, because MetaMask team does not care and hides them by default
  • Uniswap tries to avoid legal responsibilities and going way by EtherDelta and securities laws violations by making the user to “choose youur token registry first”, leading to bad user experience
  • Wallets showing all incoming like Trust Wallet are super user friendly but get spammed by shit tokens
  • Parity on-chain decentralised registry never went anywhere
  • A lot of early projects are hurt by “gatekeeper fees”: wallets asking a listing fees to appear in their default token list - these fees can rank in $10ks - making the community appearing hostile towards newcomers

My conclusion is that all token curation efforts have been more or less failures, because they are solving the right problem wrong. Based on my experience working with 20+ token startups, having tokens showing in the wallet by default, how scammy or not, is much better option, in “the greatest good for the greatest number” philosophy. Very little real damage can be done by flooding wallets with useless token transfers or creating useless scam token.

Instead of having a registry, I suggest simply

  1. Having an indexer that indexes all created tokens - any token is free game like with Trust wallet
  2. Consider the risks in the curation- controversial tokens like SushiSwap does not show up because some people just hate the project and it will never pass any vote
  3. Consider the risk - user receives some worthless scam tokens - what bad it can do
  4. Instead of curating, focus on objective metrics what are good tokens and what not
  5. Standardise UX around wallets how NEAR tokens should be displayed, so there are baseline what users can expect

Good UX pattern from Facebook messengers: All messages are allowed, but a warning is displayed in the sender is not in your network. Copy this UX pattern to all wallets.

Use objective metrics to determine if the token looks legit. There are few hard to fake metrics

  1. Creation date
  2. Trading volume

If creation date and trading volume are below certain threshold display a standardised warning, with a FAQ link, explaining: this token looks very fresh - unless you expected a token transfer, proceed carefully. FAQ can then explain more information about scams and legit warnings.

Give guiding to the wallets that there should not be listing fees for any token to appear in their token list, as this is considered hostile practice. Anything within the above UX guidelines should be shown.

Here is my earlier discussion with NEAR team (Evgeny) regarding this topic: https://discord.com/channels/490367152054992913/510254340120903684/772523361283866625

2 Likes

Thanks for reply.

This is general pattern, not specifically for tokens though. E.g. events, projects, people, RPC nodes, and more.

What you are suggesting is more around what wallet should be using for displaying tokens, which indeed can be either a registry or just some UX that hides all the tokens you don’t care.

I like your suggestion around UX for the wallet that just suggests that this token fresh / should be treated carefully based on volume and date information. Volume can be a tricky thing but we can prob have something simple first and iterate.

Actually, I think your post deserves to be published as a separate discussion for UX patterns around tokens in wallets @miohtama

2 Likes

I also don’t see how TCRs can work at scale.
It’s a full time job to curate that lists, and the a distributed governance far from being efficient. So, it’s essential a job for marketing people (which makes sense).

I like @miohtama idea.
We could combine indexer with bunch of smart algorithms to help user adjust the ranking based on his preference. A standard ranking could be based on something like Page Rank - through the use in the blockchain and verified community off-chain resources. This means that the whole thing is mostly off-chain, but probably will deliver better results.

Not sure what scale we are talking - def won’t scale to 100k of records :smiley:

Any work must be paid. Proper governance / curation is work - so it should be funded itself.
I think this has been one of the key issues with scaling governance.

It’s similar how expecting high quality from Facebook feed vs New York Times.
NYT has editors on staff to actually do curation, provide guidance and also fund journalists to go out and do interesting pieces.

Mixing these two models: people permissionlessly adding stuff but paid editors / curators make sure the content is high quality I think is the best to get to reasonable scale.

So practically, this can be a set of delegates that others delegate their vote power to actually do governance decisions (liquid democracy), and this delegates are receiving reward from “bank” and usage fees.

There is an issue with TCR self sustainability around usage, because most usage is off-chain reads which are not paid in this model. I think this is interesting problem of monetization that should be figured out as well.

Agree, a quality output requires a quality work and payment.
Someone needs to pay for the curation to make sure we have a quality work. Otherwise it’s spam or marketing content.

@illia, very good example with NYT. It is a publisher. They don’t have a money printing machine - someone has to buy the content. If they produce crap, nobody buys it. They also have a sponsored content.

As you noticed, we have a problem with payment - who and when is paying?

Maybe a reputation system could work here? Only verified validators can curate the market. This requires some decentralized KYC system. We could print a money through a proof of work concept - if curators proof they work, they will have a money in an escrow. Once people will use it, and not mark it as a scam, they money will be unlocked.

Payment and incentives can work on a few levels:

  1. If the registry has a native token, this can appreciate in value. The downside of this approach is that holders and users have to take on currency risk which I think is undesirable.
  2. Listing fees go into a DAO and can get paid out to active curators. The DAO has to maintain reserves of listing fees to pay out successful challengers but listing fees paid by good entries can be spent on development / paying curators.
  3. Curation on The Graph. The Graph is the indexing layer for the decentralized web. Curators on The Graph get a cut of query fees. By building a subgraph for the registry and signaling on that subgraph, Curators can earn fees from the usage of the API they’ve helped to curate.

The Layer 1 blockchain gets its fees from transactions to the chain (distributed to the miners). The Graph gets its fees from queries (distributed to the Indexers and Curators).

1 Like

I wrote about it in a context of “money printing”. This approach is susceptible for being a scam. Adding a content can be done by robots. The difference to Yield Farming, is that with Yield Farming you need to put other assets, which you can easily print.

We kicked off with a Github repo for token list: https://github.com/near-clp/token-list/ for the NEARswap.
Please create a Pull Request to add your token there.