Published in


Token curated playlists #2: throughput & fitness, use cases, UX

📋 Navigating tradeoffs in the world of skin-in-the-game curation (or “can TCR tokens be seen as work-tokens”?).

🔍 Outlook

1. 🔀 While you were offline…

  • Trent McConaghy’s The Layered TCR formalised the notion of stacked TCRs, drawing analogies with APLS Architecture (Age-Layered Population Structure), and laying down a path for “shades of grey token machine[s] where agents can increase their rank (layer), and with it, their rights and responsibilities”.
  • Robert Clark’s Framework-based TCRs (fTCRs) introduced the idea of voting on various metrics and weightings (frameworks) that ultimately decide the fate of applicants and listees, removing “direct oppose-challenge voting” from the mechanism.
Slide from De Jonghe’s presentation.

2. 📏 Considerations on throughput and fitness

The scalability trilemma in the context of TCRs. Heavily inspired by Trent McConaghy’s work on “The DCS Triangle.
Messari and TruStory arguably optimise for security, where security = how much does it cost to make the list diverge from its focal point?
Would you agree that adChain is near the center, after distributing tokens via an ICO + strategic media/partner allocations?

3. 👐 Towards more inclusive registries (as paradoxical as it sounds)

  • Voluntary dilution rate: staking protocols need circulating tokens to work. Sometimes, people who don’t have access to capital simply can’t play (even though they may be able to provide some value). New tokens can be minted by staking value also not in the form of money (quoting Simon, on the Curation Markets Gitter room). If all the people in the game agree, new tokens can be minted for entrants that have no capital, but commit something else (e.g. prove their identity). Livepeer is arguably tackling this very same problem by allowing any ether account to MerkleMine its tokens (basically, to generate some LPTs effortlessly).
  • Staking towards other items & delegating: if there was any incentive for token holders to be actively staking (= new tokens minted for stakers), it’d make sense to permit staking towards any listee, as a means of signalling the value of given items in the list. If I do that with an item that gets delisted, I lose my stake alongside it; if I stake towards reputable items, I “secure my stake” (my right to a share of rewards) and increase the cost for challenging the items I’m “betting on” (increasing the total stake backing them). If I don’t want to deal with that complexity at all, and just want not to be diluted by inflation, I could also just delegate_Stake all my tokens to a curator I trust (or I pick from a list), who’s allocating my capital, and whose staking “results” will be publicly auditable in the same place where I first chose him (performance = share from inflationary rewards + share of earnings from propose-challenge games).
  • Natively incentivising participation: curatorship expertise is sometimes counterintuitively valuable. Take the curation of videos — that on which one has to discern between what’s copyright infringing or not. YouTube pays ~10.000 people to manually review millions of flagged views, every month. Professional curatorship, be it human or machine-driven, is expensive. Relying on propose-challenge redistribution mechanisms to pay for it may, in the case of distributed networks, not be enough. If one assigns value to the job (as the real world seems to do), it’s conceivable to think of this value being captured by a staking token that confers the right to perform such work, prove it (if your stake is still there, you’ve done good curation; if you lost it via the underlying game dynamics, you’ve done bad), and compete for inflationary payouts / block rewards. If YouTube laid off its “moderation” team and deployed a token with centralised monetary policy for paying distributed curators this way— assuming an average current salary of U$36K/year — that could translate to roughly U$1M every day in minted tokens for “reviewers” to compete for. For reference, that’s twice what Monero’s been paying out daily for miners.

4. 💭 Use cases for TCPs

Token curated playlists are proposed means of categorising media upon distributed curation, that can spawn unprecedented monetisation models.

4.a. 🎯 Segmentation for content promotion and advertising

2 leves of TCPs under a mother-TCR, with their native tokens A, B, C, and fictional entities that could be interested in each of the 3 lists (colours analog to the chart above).

4.b.🏆 Decentralised Oscars

Oscars may be just tradable memes. Which they are, a bit, already.

4.c. 🔋 DAL (Decentralised Autonomous Lists, a.k.a. Autonomous Publishers)

Self-paying lists of on-demand delivered content. You get the idea.

4.d. ⏰ Smart programming / temporary playlists

5. 🔧 On making lists (UX and “market fit”)

Can deploying a TCP become as easy as making a list of issues on Github? If you have any suggestions, please email 📧
By adChain.
Sketches for what a TCR of videos could look like, by @pedrocasa.

6. 🚪 Conclusion

  • TCRs are originally designed for low-throughput lists whose focal point is very objective, application has a reason to be costly, and curation expertise is valuable or somehow scarce.
  • Modifications such as a voluntary dilution rate, minting rewards to active stakers and the ability to add_stake towards listed items can make room for higher-throughput, though potentially less secure, lists.
  • TCPs allow for multi-level categorisation, complementing the unflexible nature of the original TCR design.
  • TCPs reduce local entropy, while increasing global entropy — the very definition of work, one of the reasons why their “mother token” can be seen as a work token.
  • TCRs, originally, are “more valuable” when incomplete (meaning there’s still room for new applicants to demand tokens to join and push prices upwards). TCPs aim to balance incentives for curators to judicate over (and deploy) both “incomplete” and “complete” lists.



Decentralising video and putting revenue in control of content producers.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store