Token Decimals TCR primary sources — 2026-05-13

What I reviewed

Key takeaways from primary sources

  • The strongest source signal is the repeated caveat in the T2CR docs and README: the public list follows the Uniswap token-lists schema, decimals is mandatory, and tokens whose contracts revert on decimals() are excluded unless they are accepted in the Token Decimals TCR.
  • That makes Token Decimals TCR a compatibility sidecar for downstream discoverability, not just an obscure add-on. Inclusion in the broader list can hinge on this narrower registry.
  • The Kleros Tokens docs show the main registry already stores token name, ticker, address, decimals, and logo, while challenge/arbitration handles correctness. Token Decimals TCR reveals that one metadata field is problematic enough to deserve its own fallback governance path.
  • The T2CR docs also note that the example view contract returns 0 when a token does not implement decimals(). That is analytically useful because it shows the failure mode is not only missing metadata but also consumer-side ambiguity in contract-reading pipelines.
  • The public list endpoint itself is useful evidence that the output target is a schema-bound machine-readable token list consumed by external apps, not a purely human-facing registry.

Specific source signals worth retaining

  • The T2CR quick-start/docs page is the clearest source for the field-level dependency: no accepted Token Decimals TCR entry means exclusion from the main list for tokens with unreadable decimals.
  • The Kleros Tokens docs are the clearest source for the broader framing: open token submission, challenge periods, Kleros arbitration, and token-list discoverability as shared infrastructure rather than app-specific gatekeeping.
  • The public list endpoint is the clearest source for why this sidecar matters in practice: it emits a concrete token-list artifact with mandatory decimals fields for each included token.

Why this entry belongs in the corpus

  • It gives the token-list and curation cluster a narrow but reusable comparison point for metadata fallback governance.
  • It helps separate token identity, metadata correctness, schema rigidity, app compatibility, and dispute-backed overrides instead of flattening them into one generic token listing decision.
  • The durable insight is that discoverability often fails not because assets are absent, but because one required field cannot be sourced cleanly from the contract and some actor must become authoritative for the override.