Category: token-metadata registry / challengeable token list / arbitration-backed badge system
Summary: Kleros Tokens Registry is best understood not as a generic token directory or wallet convenience list, but as a challengeable token-metadata and correctness registry with a separable badge layer on top. Its core move is to split token legibility into at least three surfaces that later token list discussions often flatten together: base metadata correctness (name, ticker, address, decimals, logo), optional higher-claim badges (such as ERC-20 compliance, stablecoin, or true cryptosystem status), and downstream schema export for consumers like wallets and DEX frontends. That makes it a useful comparison point for adChain Registry, Kleros Curate, token-list registries, and other list-admission systems: it shows how open listing can still concentrate power in listing policies, badge criteria, deposit sizing, court selection, and the consumer interfaces that decide which accepted claims actually get reused.
What it does:
Lets anyone submit ERC-20 token metadata to an open registry by posting a deposit and waiting through a challenge period
Accepts unchallenged submissions automatically and routes challenged claims into Kleros arbitration
Stores token information as structured metadata including name, ticker, contract address, decimals, and logo
Exports accepted entries in a Uniswap Token Lists-compatible format so downstream apps can consume the registry as infrastructure rather than only as a browser UI
Separates basic correctness claims from optional badge claims, with badges used for stronger assertions such as ERC-20 compliance or stablecoin status
Uses a companion Token Decimals TCR for tokens whose contracts do not return decimals() in the standard way, making metadata compatibility a distinct curation layer of its own
Key claims:
The official Kleros docs describe Kleros Tokens as an open and decentralized curated registry of ERC-20 tokens, positioned as a community-managed alternative to fragmented app-specific token lists.
The strongest reason to keep this entry separate from the broader Kleros Curate page is that the T2CR docs make a sharp distinction between correctness and quality: the base registry is for correct token information, while claims like bug-free, secure, decentralized, or non scam belong in separate badges with their own policies.
The T2CR documentation is especially useful because it shows how downstream compatibility standards become governance surfaces. Since the exported list follows the Uniswap token-list schema, decimals becomes mandatory and nonstandard tokens are pushed into a separate Token Decimals TCR.
The ERC-20 badge writeup makes the layered-control-plane design concrete: a token can be in the base registry yet still need a separate challenged claim for ERC-20 compliance, with its own deposit, challenge period, and court.
The official product page says the registry is already consumed by applications such as Uniswap, Sushiswap, Zerion, and Swapr, which matters because the real power of a curated list sits not only in admission but in which downstream interfaces treat it as canonical enough to import.
This belongs in the active corpus because it exposes a useful split that generic token lists and generic curated registries often hide: metadata correctness, standards-compliance badging, and downstream app reuse are distinct governance layers rather than one neutral listing surface.
Whitepaper: No canonical standalone Kleros Tokens Registry whitepaper or litepaper surfaced in this pass. The strongest primary materials were Kleros’s official Tokens product docs, the T2CR documentation README, the published listing-policy PDFs linked from that README, and Kleros’s ERC-20 badge writeup. See ../whitepapers/kleros-tokens-registry-primary-sources-2026-05-12.md.