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 %)
