Token Curated Registries 1.1, 2.0 TCRs, new theory, and dev updates
Hi friends! This blog post is a collection of updates and random miscellanea related to token-curated registries as the idea has developed since the publication of the 1.0 paper. There is a lot in here, and if you are building a project around a TCR you should read this entire post!
Token-curated registries 1.1
The predominant concern raised by readers of the 1.0 whitepaper had to do with a behavior some took to calling “vote splitting.” Because there is no penalty for voting incorrectly, why should otherwise disinterested token holders not split their tokens in every vote and collect a steady revenue stream for doing no work? This amounts to a grief against diligent token voters, whose voting weight is diluted and so go home with less reward for their work. 1.1 TCRs contain a small but mighty update to address this concern: a new parameter called MINORITY_BLOC_SLASH.
MINORITY_BLOC_SLASH is the percentage of tokens in the losing voting bloc disbursed to the winning bloc, by token weight, as additional rewards.
Unrevealed tokens are slashed like losing tokens. If MINORITY_BLOC_SLASH is zero it behaves like a 1.0 TCR. It otherwise acts as a lever to discourage vote splitting and coin-flipping. It does then encourage vote memeing, but I think that healthy vote memeing in the form of delegated voting pools (where passive token holders proxy their tokens to expert, activist voters) will be more profitable tactically and strategically than mindless vote memeing.
In particular I would like to thank Moshe Praver for interrogating the issue of vote splitting thoroughly and pushing my thinking on it.
The TCRs 1.1 paper also better specifies procedures for a listing exiting a TCR with a new parameter EXIT_FREEZE, and includes reorganization of some prose for better legibility. It will be released soon.
New theory: the misbehaving inequality
The token holders of a TCR signal the TCR’s values on the basis of what they admit to and keep in the registry. In this way consumers can make assumptions about how listed entities will behave in any interaction.
Under what circumstances will an entity listed in a TCR take an action contrary to expectations given the TCR’s value signaling? More generally, what analysis will a listed entity make before taking any action? This is the question answered by the misbehaving inequality, which was formalized by Mark Beylin.
A rational, risk-neutral, TCR-listed entity will take some action if the value of that action (V_action) would be greater than the value of the product of their deposit in the TCR (V_stake) and the probability of losing that stake for taking the action (P_punish).
We can define P_punish as a function which takes an argument, action, and produces the probability that the action will result in the performing entity being removed from the registry (P_punish(action)).
The misbehaving inequality is therefore:
P_punish(action) * V_stake < V_action
For the set of actions where the inequality is true, the listed entity can be expected to take the action with the greatest V_action.
We call this the misbehaving inequality because it is useful for determining under what circumstances a listed entity may be bribed to take an action contrary to expectations given the TCR’s value signaling.
2.0 TCRs: Trust Pools
With the misbehaving inequality we realize that while P_punish is not strictly determined for any action, V_stake is strictly determined. In 1.0 TCRs, V_stake is determined by the MIN_DEPOSIT parameter, which must suffice to provide sufficient security against anti-social behavior for as many cases as possible without pricing out too many otherwise suitable candidates. What if the MIN_DEPOSIT parameter didn’t exist?
A candidate to a 2.0 TCR can apply for listing with a token deposit of any size. We call this their trust pool. The V_stake for any listee is equal to the size of its trust pool. Listees can maintain trust pools of any size between zero and the entire token supply. This enables subjectivity around the trust pool size necessary for a consumer to rely on a TCR-listed entity to be deferred to consumers rather than determined by token holders, and empowers listees to make a responsive market for trust. The sizes of trust pools in a single TCR are expected to be heterogeneous.
It is likely that one or more Schelling points will emerge around trust pool sizes which are considered sufficient for various applications of a given TCR. Considering the misbehaving inequality, smaller trust pools may suffice where a listed entity’s actions determine the fate of smaller amounts. Larger trust pools may be required where the listed entity’s actions determine the fate of a larger amount. Consumers can decide what risk they are willing to assume and specify an acceptable minimum trust pool size on the basis of their assessment of P_punish for any action contrary to the TCR’s value signaling, and the value at stake under the action.
As an added bonus, removing the MIN_DEPOSIT requirement simplifies the specification of token-curated registries by obviating the touch-and-remove edge case for challenges.
A 2.0 version of the token-curated registries paper will be published in the coming months.
Dev update
There is now a generic TCR repo forked from the AdChain Registry repo.
It has open issues and I would accept pull requests to close them! In particular the issues related to the test suite should be relatively easy to fulfill for new contributors.
PLCRVoting is a major dependency of the TCR repo, and it needs help too, particularly in regards to its test suite. See the open issues.
