Design a Token Curated Registry (TCR)

Problem statement

Design a token curated registry : a publicly readable list (trusted crypto projects, legitimate ad domains, certified newsrooms, validated map anchors) whose membership is decided not by an admin key but by token holders who put their own stake at risk. An applicant deposits registry tokens to apply. During a challenge window anyone may dispute the application by posting an equal-or-greater deposit. A disputed entry enters a commit-reveal vote among token holders; the losing side forfeits its deposit, part of which pays the winning side's voters. Unchallenged applications are whitelisted automatically when the window expires. Listed entries can be re-challenged and removed later, so curation is continuous, not one-time.

The brief requires four functional cores: the list object structure with submission and challenge flow (FR1), token staking for listing and challenging (FR2), a voting or adjudication mechanism (FR3), and reward distribution for correct challenges and correct voters (FR4). It also requires security against manipulation and sybil infiltration (NFR1), timely vote deadlines despite low average latency needs (NFR2), scalability under many concurrent entries and challenges (NFR3), and a UI that shows each listing's status and full challenge timeline (NFR4).

Why this problem is distinctive

A TCR is not a database with a queue in front of it. The source of truth is a synchronous, global, adversarial state machine executing on a chain: every transition is a transaction, every bug is permanent, and every participant may be an attacker holding tokens. The off-chain system (indexer, API, UI, notifier, keeper, bridge) exists to make that truth legible and timely without ever becoming authoritative. A strong answer separates four planes: (1) the contract plane (registry, parameterizer, PLCR voting, ERC-20 token), (2) the projection plane (indexer, caches, search), (3) the experience plane (applicant, challenger, voter, watcher UX and notifications), and (4) the economics plane (deposits, dispensation, reward pools, quorum, parameter governance). Most weak answers collapse plane 2 into plane 1 and then cannot explain reorgs, stale UI, or missed reveal deadlines.

Public operating baseline versus design assumptions

The pattern is operationally real. MetaX's adChain Registry, a whitelist of publisher domains staked with the ADT ERC-20 token, went live on Ethereum mainnet in April 2018 as the first production TCR [[20]]. ADT is explicitly an ERC-20 used for governance, staking, and participation in the adChain protocol and registry [[19]]. Kleros deployed six token-curated registries for token listings in 2019, escalating subjective disputes to staked PNK jurors [[62]]. UMA's Optimistic Oracle, the direct evolutionary descendant of the TCR challenge pattern, resolves about 99.8% of requests without escalation and has secured over $30B in total transaction value, including Polymarket resolution [[39]][[83]]. Civil is the cautionary case: its October 2018 token sale raised only $1.4M from 1,012 buyers against an $8M minimum and was refunded, and its registry never acquired the participating stake its quorum rules required [[105]][[102]].

For capacity planning this answer assumes a mature registry: 40,000 currently listed entries, 260,000 historical applications, 350 applications/day steady and 1,500/day peak, a 5% challenge rate, 12,000 token holders, and canonical deployment on an optimistic L2 with an L1 token anchor. Unless tied to a citation, every number is a stated design assumption, target, or budget.