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 “ ” for decentralized 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 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. Token Building Blocks blockchain design For a primer and warm up to TCRs I suggest: _A recent crypto-economic design pattern that I’m very excited about is the Token-Curated Registry (TCR). It’s simple…_medium.com City Walls & Bo-Taoshi: Exploring the Power of Token-Curated Registries _co-authored by Gautam Dhameja, Tom Debus and Günsu Pancar.direct or indirect intellectual input by Trent McConaghy…_medium.com Curated Governance with Stake Machines We should also read to be fully informed. arguments against 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 or . The applications of a TCR and interface layer are also important as shown in the following examples. signalling game mechanics Summary Actions: in/out Applications: an axiomatic basis for most TCR applications Feasibility: several are in development See, “ ” for feasibility and technical details. Token Curated Registries in Development 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 “swap” is proposed between (2) Jane and (3) Bob. It is accepted and the two are switched. smaller 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, “ ”. 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. Token Curated Playlists 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 in his post, “ ”, 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. Sebastian Gajek Graded Token-Curated Decisions with Up/Downvoting 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 in “ ”. Trent McConaghy 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 speak. This is also closely related to ’s work on “ ”. 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. graph / data structure Dimitri De Jonghe Stake Machines 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 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 , perhaps in order to grant access; i.e. I have 3 / 5 keys of a multi-signature wallet. piecewise completeness 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. _Methodology, Patterns & Tools. TE Series Part II._blog.oceanprotocol.com 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/@mattdlockyer twitter.com/mattdlockyer linkedin.com/in/mattlockyer #BUIDL Together Forever 🤗 Me in NYC with the team, CEO of (not taking sides) and anonymous Monero Fan(man)boy 0xcert bitcoin.com
