Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Token Curated Registries (TCRs) are a building block of decentralized applications based on fungible tokens (FTs) and digital scarcity. They are fast becoming one of the hottest âToken Building Blocksâ for decentralized blockchain applications. The use cases for TCRs are far reaching, everything from a simple whitelist to full blown decentralized governance. In this post I discuss some design patterns for TCRs and potential use cases. I am not purporting to know the Schelling point parameters, nor have I built these TCRs. This is for design thinking and use case exploration to spur innovation in the community.
For a primer and warm up to TCRs IÂ suggest:
- City Walls & Bo-Taoshi: Exploring the Power of Token-Curated Registries
- Curated Governance with Stake Machines
We should also read arguments against to be fully informed.
TCR Basics đ
TCR Diagram courtesy of Dimitri De Joghe
Conceptually, a TCR is a registry of listings generated by token holders. Listings can be anything from names to hashes of full blown records stored in IPFS. A holder stakes a portion of tokens to perform an action, i.e. adding a listing. Token holders can vote on whether to accept or reject the action using their tokens. A majority wins the vote and the action is accepted or rejected. The list is updated and should become more valuable given the improved listings and staked tokens are now out of circulation. Perhaps it is a finite list of exclusive members who have access to VIP services?
Token holders, acting in their own self-interest will produce a valuable list by obtaining and staking a finite supply token. The more listings staked, the scarcer the tokens; the more valuable the list, the more valuable the tokensâŠ
TCR Examples
In the following 5 examples, I will be referring to the elements of a TCR as âlistingsâ, and often referring to TCRs as âregistriesâ or âlistsâ for shorthand. Some examples expand on the cryptoeconomic mechanism design of the registry mechanics themselves, while others rely more heavily on the application layer interpretation of the registry.
1. Unordered TCR
An unordered TCR is where things begin. These can be finite or infinite. As explained in the basics above, there is a stake to perform an action: adding or removing a listings. If a user chooses to remove her own listing that was previously accepted, the stake is returned. Parameters such as stake amount, minimum votes to accept or reject and the amount of stake slashed (usually paid out to other token holders) if the action is rejected, are still open questions for many development teams.
Domain expertise will be important in determining Schelling point parameters, since the purpose of lists is often related to signalling or game mechanics. The applications of a TCR and interface layer are also important as shown in the following examples.
Summary
- Actions: in/out
- Applications: an axiomatic basis for most TCR applications
- Feasibility: several are in development
See, âToken Curated Registries in Developmentâ for feasibility and technical details.
2. Ordered TCR
The ordered TCR adds an index to each entry in the list. These lists could serve as queues, rank or instruction sets. In the above example: Alice, Jane, Bob and Ted are already accepted to the list. Perhaps someone paid a premium to stake Alice and Bob in the first 2 positions? A âswapâ is proposed between (1) Alice and (4) Ted. It is rejected. A smaller âswapâ is proposed between (2) Jane and (3) Bob. It is accepted and the two are switched.
Real world examples could include fans using their tokens to set the playlist of their favorite DJ at a music festival as Felipe suggests in his post, âToken Curated Playlistsâ. Whatâs interesting is that the fans donât need to be present to participate in the voting and can watch the resulting performance live on YouTube. In the playlist example, being the number one song on the list is less important than a songâs position relative to other songs. In this case the stake and swap vote mechanics are entirely different than a âTop 40â music list.
Summary
- Actions: in/out, swaps
- Applications: instruction sets, governance procedures, playlists
- Feasibility: add index to listing data and additional functions to stake and swap indexes
3. Graded TCR
Courtesy of Sebastian Gajek post on Graded TCRs
The graded TCR proposed by Sebastian Gajek in his post, âGraded Token-Curated Decisions with Up/Downvotingâ, is like an ordered TCR at first glance. However, each listing does not need to occupy a unique index, but instead contains itâs own mutually exclusive rank in the form of some points. This is analogous to 2 reddit posts having the same amount of upvotes, or 2 users having an equal number of karma points for reputation.
- Actions: in/out, upvote/downvote
- Applications: reputation systems, ranking content
- Feasibility: add rank to listing data and funtions to upvote, downvote and challenge rank by staking and voting
4. Layered TCR
Originally posted by Trent McConaghy in âThe Layered TCRâ.
The layered TCR is an interesting and useful construct from Trent. Essentially, a listing must make the first registry via some criteria; the bar could be low or high (membership staking). In order to promote to the next layer, the listing must meet some sort of criteria. This could be stake, time spent in a previous layer, or value added actions performed. The listing only lives in 1 layer at a time.
The above example design differs from the original post. However, there are no right or wrong ways to design something that is 3 weeks old đ, yet. Weâre simply sketching, experimenting and simulating at these stages. As mentioned above, the ideal Schelling point parameters to make these systems game theoretically sound are difficult to discover and may be domain specific.
Summary
- Actions: in/out, promotion/demotion
- Applications: ACLs, reputation, identity, player leveling, quality assurance
- Feasibility: can add promotion / demotion functions to any TCR in order to move listings from registry to registry
5. Nested TCR
In a TCR of TCRs, listings are âpointersâ to other TCRs or primitive listings often referred to as âleaf nodesâ in graph / data structure speak. This is also closely related to Dimitri De Jongheâs work on âStake Machinesâ. By allowing our listings to represent other TCRs, we have created the ability to represent any type of graph, hierarchy and network. There could be restrictions on what listings or pointers can be added, based on what already exists in the âuniverseâ of a particular TCR. This would create limitations on the graph types and data structures that can be represented. Like prescribing the correct staking parameters, discussing the restrictions and types of graphs that suit the TCR model is domain specific and beyond the scope of this post, though applications are incredibly interesting. Imagine a tree based chat dialogue in a video game created by fans.
Summary
- Actions: in/out
- Applications: decision trees, hierarchies, networks
- Feasibility: can be implemented as an unordered TCR with an optional âparentâ data attribute per listing for building relationships
6. Combinatorial TCR
A TCR may have the ability to stake combinations or permutations of items in a single listing. These designs allow for token holders to define acceptable sets, ranges and parameters collectively and in a piecewise manner. In examples a) and c) order matters, and therefore a higher stake is applied to the index of the item that will have the most impact as part of that listing. In example b) order does not matter, since the logic applied in the application of the TCR is only concerned about set completeness, perhaps in order to grant access; i.e. I have 3 / 5 keys of a multi-signature wallet.
Using TCRs in this way provides the ability to decentralized application and game mechanics. Many rows can be added to a combinatorial TCR, forming the recipes of acceptable business logic in the implementation. The complexity cannot be understated. So once again, I warn protocol and token engineers to proceed with caution when determining the mechanism design of ⊠decentralized mechanism design.
Summary
- Actions: in/out; in/out; in/out; âŠ
- Applications: function parameters and ranges, game mechanics, governance
- Feasibility: each listing can be implemented as an array of items
All Together Now đ€Ż
There are a lot of ideas presented in this post and none of them are intended to be mutually exclusive. Each design was axiomatically built up on top of a basic TCR through adding more complexity in the cryptoeconomic mechanism design of the TCR or placing emphasis on the application layer interpretation of the registry structure. Combining 2) Ordered TCRs with 5) Nested TCRs may yield some benefit to a specific protocol serving the applications that can be delivered to businesses and end users. However, as mentioned in 6), it cannot be understated how complex these systems will become. It is always better to prove out a small focused use case and layer on complexity as you go. The following post on Token Engineering may be useful for putting some of these designs into practice.
Towards a Practice of Token Engineering
Summary
Building blockchain protocols is all about designing âput your money where your mouth isâ networks. In this post I have presented several design patterns for Token Curated Registries (TCRs). These are an important Token Building Block with several applications. I encourage teams to seek domain experts from the specific field they are solving for. The parameterization of TCRs or any other token building block requires careful mechanism design to ensure parameterization aligns incentives. Experts that understand stakeholders and sociology-economic factors involved in a domain can assist greatly. Always be testing and stay cryptoeconomically safe đ.
Did you enjoy the post? Did I miss anything? Please comment below.
Thanks to Trent McConaghy, Dimitri De Jonghe, Simon de la Rouviere, Mike Goldin, Felipe GaĂșcho Pereira, Robert Greenfield IV, Max Bronstein, Brian Flynn
medium.com/@mattdlockyertwitter.com/mattdlockyerlinkedin.com/in/mattlockyer
#BUIDL Together Forever đ€
Me in NYC with the 0xcert team, CEO of bitcoin.com (not taking sides) and anonymous Monero Fan(man)boy
Token Curated Registry (TCR) Design Patterns was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.