In this post I aim to convince the reader that categorizing TCRs as a type of work token is incorrect. To be clear, I believe a distinct subset of TCRs should be restructured as work tokens. I will draw upon the Augur platform as a work token model and explore how we might use this model to design a work token protocol for objective lists. Finally, I propose that this restructuring deserves a category of its own and, for the sake of future standardization, a new name — Trustless Incentivized Lists (TILs).
I recently read Phil Bonello’s blog post on productive cryptoassets and appreciated that a taxonomy for utility tokens is slowly emerging. Ultimately, I believe this space will sort out the broad categories of utility tokens and it will become clear how and when to use a particular token model. We will also have open repositories with battle-tested smart contracts that allow developers to quickly spin up new networks. In fact, we are already seeing this with token-curated registries (TCR) that use Mike Goldin’s generic repos (aka “generic repo TCRs”). Interestingly, in both Phil’s and another classification (below), TCRs fall under the work token umbrella.
What is a work token?
A work token is a platform-specific token that gives the token-holder the right to perform work for the platform. In order to earn this right, a token-holder must stake their tokens in a smart contract (the “work contract”). There are two critical requirements for a work token:
- Token-holders who stake their tokens in the work contract are entitled to a proportion of cash flow generated on the platform equal to their fraction of total tokens staked. This is generally accomplished in one of two ways: a) the probability of being assigned the right to perform work for the platform is proportional to the number of tokens staked by the token-holder relative to the total number of tokens staked in the work contract or b) token-holders check-in at regular time intervals and, if there is no specific work to be done, they stake their tokens in a work contract to prove their participation.
- Token-holders who appropriately perform work for the platform are rewarded with cash flows in a non-productive asset (DAI, GUSD, ETH*).
By meeting both of these requirements, the work token captures the value of underlying work provided on the platform through a continuous revenue stream to the active token-holders. Work tokens can therefore be nicely modeled using a net present value model.
The most frequent example of a work token is Augur’s REP token (An ERC-20 token issued on Ethereum). Reporters on the Augur platform stake REP tokens to dispute the tentative outcome of prediction markets or stake tokens to purchase participation tokens. Each staked REP token entitles its holder to an equal portion of Augur’s market fees — currently denominated in ETH.
- ETH will, itself, become a work token after the move to PoS; however, it also has the potential to become a dominant store of value and medium of exchange.
Where do TCRs fit in?
“Generic repo TCRs” do not meet either of the critical requirements, as explained below:
- There are 2 ways to earn tokens in generic repo TCRs — win a challenge or be part of the winning voting bloc. Only one token-holder can win a challenge, whereas any number of token-holders can participate in a vote. The percentage of the spoils that go to the challenger is known as the DISPENSATION_PCT and is currently 60% in the Adtoken TCR. Effectively, 60% of all the cash flow goes to the token-holder who is the most aggressive curator and jumps on the opportunity to submit a challenge. This means that the majority of cash-flow does not map proportionally to token-ownership but to the single token-holder who is most engaged, aggressive and diligent. Note, that by setting the DISPENSATION_PCT to 0% (i.e. eliminating the challenge), 100% of the revenue does go to voters based on their percentage stake in the vote and the work token criterion is met.
- A “generic repo TCR” is a closed system in which the curators are motivated to increase the quantity and value of the platform token through judicious curation. It’s not unlike being paid in taxi medallions for driving a taxi. Work tokens are by definition an open-system in which the curators are motivated to earn fees in a secondary non-productive asset. Both models are backed by the desirability of the platform to users, but the TCR model introduces an unnecessary form of selling pressure on the platform token whereas the work token model does not.
“Generic repo TCRs” do not meet the criteria for work tokens.
Designing a Work Token Model: Learning from Augur’s Early Mistakes
In a recent post, the team at Multicoin Capital sensibly recommended a restructuring of TCRs as work tokens. They referenced the proposed Messari TCR as a model work token TCR. While the proposed Messari TCR is technically a work token TCR, the design is somewhat outdated given what we have learned from the REP work token model.
For the purposes of this discussion, I will highlight 2 modifications that the proposed Messari TCR makes on the original protocol: 1) Set the DISPENATION_PCT to 0 thereby replacing the challenge period with a direct voting round and 2) Replace the application fee with a non-productive asset (currently ETH). On the surface, this seems to resolve the critical ways in which “generic repo TCRs” fail to meet the work token criteria. Technically the voting round does effectively distribute cash-flows based on the percentage of total tokens staked. However, there is one curious distinction between the Augur work token model and the proposed Messari TCR: in the Augur work token model a single “designated reporter” is responsible for performing the work while the others monitor for nefarious activity, whereas in the proposed Messari TCR multiple token-holders actively participate in voting on every application.
Interestingly, the latter strategy was proposed and then abandoned by the Augur team. The original Augur white paper describes a method in which REP holders encrypt a reporting ballot which contains the outcome of all the markets which resolved over the previous 8 week period. At the end of the reporting period (if a minimum quorum of ballots are received), all the ballots from all the REP holders are compiled into a report matrix and compared using a consensus algorithm based on principal component analysis. The result of this algorithm determines the outcomes of each event as well as the final REP balance of each token-holder (based on their consistency with overall consensus).
A sample of an Augur ballot; Source: Original Augur whitepaper
This clearly was not the ultimate direction Augur chose — it was inefficient, computationally prohibitive and ultimately unnecessary. The Augur team realized that having multiple token-holders “vote” to achieve some algorithmic consensus was not necessary. Instead, if the outcome of the event was objective and publicly verifiable, it made sense for one token-holder to report on the outcome and have other REP holders take action only if the first token-holder acted dishonestly.
The lesson of Augur: when we design a work token model for objective lists, we should design a protocol that relies on incentives for a single token-holder to complete the task honestly and only utilizes the remaining token-holders as backup if nefarious activity is detected.
Life as a work token protocol
TILs: Trustless Incentivized Lists
I have previously written about the difference between subjective and objective TCRs. In general I think these are entirely different beasts and require completely different protocols to achieve the appropriate incentive structures. My intentions with this post are to push the community to start thinking about objective and subjective TCRs as completely different. We need to stop labeling subjective TCRs as work tokens when they are not. If we continue to call them work tokens, we will mistakenly start thinking about them as such and ultimately misuse them in our networks. Arguably this has already occurred. To clarify the difference:
The work token model only applies to tasks which are pure commodities. The task at hand must be objective in nature such that anyone (or any machine) reviewing the token-holder’s work will be able to determine if the task was performed appropriately. In the work token model, a single token-holder is primarily responsible for performing the next job on the platform.
This is clearly not the case with a subjective TCR like adChain. Rather the “generic repo TCR” model works quite well for adChain because the task is subjective and not verifiable. It would be nonsensical to assign a single token holder the task of adding a new applicant to the registry. Subjective TCRs require input from the broad community of token-holders. Indeed, when it comes to subjective TCRs, the challenge mechanism that strongly rewards the engaged, aggressive and diligent token-holder is a feature, not a bug. Let’s continue to call subjective TCRs: TCRs!
We need a new name for decentrally-curated objective lists. We need to stop calling them TCRs. I personally find that the word “curation” weakly applies to the process of adding items to a list using objective criteria.
I propose we call decentrally-curated objective lists: Trustless Incentivized Lists (TILs — give it some time). I initially played around with different names that retain the token/registry nomenclature, but I feel it’s actually necessary to strongly distance these lists from the TCR nomenclature.
If a project proposes building a TIL using TCR contracts it should be as clear that this is a technical oversight as it would be if a developer were using a hash in a situation that called for an array.
If we return to the Augur example once more we can see further similarities between Augur and TILs. The entire raison d’être of the Augur reporting system is to solve the trustless oracle dilemma. Smart contracts have no access to data outside the EVM and, in order to remain decentralized, Augur developed a trustless method that allows arbitrary objective information to be migrated from the real world to a blockchain. TILs are essentially a specific type of trustless oracle that allow structured data in the form of lists to be migrated to a blockchain. My other *hope* is that by reframing it in this way it will also push projects to ask the important question: why does my project need a trustless oracle to migrate a specific objective list to the blockchain?
In this post I have argued that subjective TCRs are not work tokens. We should stop calling decentrally-curated objective lists TCRs and stop using the original TCR design to incentivize the production of these objective lists. Rather, I propose we completely reframe these objective lists under a new name: Trustless Incentivized Lists (TILs). Finally, we should design a TIL protocol to incentivize the production of these lists using a work token model.
Spoiler: We are in the final stages of releasing this protocol design to be used for the first time in the MedX Protocol.