Kleros Tokens is not best modeled as a generic token list. The useful split is between a correctness registry for token metadata, separate badge registries for stronger claims, and downstream schema export that makes accepted entries consumable by other applications.
The T2CR README is the most important source because it explicitly says the registry enforces correctness of token information, not broader judgments like security, decentralization, or scamminess. Those stronger judgments are pushed into separate badge policies.
The same README exposes a second control surface that generic curated token list descriptions usually hide: compatibility with the Uniswap token-list schema makes decimals mandatory, so nonstandard decimals() behavior gets routed into a separate Token Decimals TCR rather than silently flattened away.
The ERC-20 badge article makes the layered-claim structure concrete. A token can already be in the registry yet still need an additional challenged claim for ERC-20 compliance, with its own deposit, challenge window, and court.
The official docs are useful because they tie curation to actual downstream consumption rather than just ideology: the registry is presented as something imported by wallets, DEX frontends, and analytics interfaces, which means list reuse is part of the control plane.
Specific source signals worth retaining
Product docs: best concise statement of the registry’s purpose as an open, decentralized, community-managed ERC-20 list and as an alternative to fragmented app-owned token lists.
T2CR README: best source for the sharp distinction between metadata correctness and optional badges, plus the Uniswap-schema / Token Decimals TCR nuance.
Badge-policy links: important because they show that stronger claims are governed by separate primary documents rather than being smuggled into the base list.
ERC-20 badge blog post: strongest concrete source for how the badge layer works in practice — separate submission deposit, challenge period, court choice, and downstream integration claims.
Why this entry belongs in the corpus
It gives the corpus a more precise comparison point than either token list or generic Kleros Curate coverage alone.
It makes a useful governance split explicit: token metadata correctness, standards-compliance badging, and downstream app import are distinct layers with different policies and chokepoints.
The durable insight is that open token discovery does not eliminate gatekeeping; it relocates it into policy documents, badge criteria, consumer schema requirements, and the interfaces that decide which registry outputs matter.