Token Curated Registry (TCR) Design Patterns

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_A recent crypto-economic design pattern that I’m very excited about is the Token-Curated Registry (TCR). It’s simple…_medium.com

Curated Governance with Stake Machines_co-authored by Gautam Dhameja, Tom Debus and Günsu Pancar.direct or indirect intellectual input by Trent McConaghy…_medium.com

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_Methodology, Patterns & Tools. TE Series Part II._blog.oceanprotocol.com

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