Registry & Markets
Find the right contract, compare recorded pool facts and understand freshness and coverage.
Last verified against production: . See current limits and availability.
Listings and discovery
The Registry follows Robinhood's published asset list and preserves when each listing was first seen. Bytecode and metadata checks establish whether the contract matches the listing. Discovered tokens are stored separately; a factory event or user-submitted address does not create an issuer listing.
DEX discovery reads events from recorded Uniswap deployments. Metadata comes from token contract calls. Pool state, swaps, holders and transfer history are separate indexing jobs with separate coverage. Discovery of a pool can precede a usable price or complete activity window.
Search and compare
Search Markets by ticker, name, token address, pool address or full v4 pool ID. An unresolved token can still have an address page. Similar-ticker notices group collisions so you can compare contract addresses and the pools associated with each one.
Volume sorting uses measured current volume where available, with depth and swap activity as the documented fallback. Missing or stale volume remains empty. Read the ranking note before treating an order based on depth as a volume leaderboard.
A stale or unread search result and a token-page view can queue a bounded refresh. This work is rate limited and shares a small worker budget. A page request can therefore return its existing recorded state while the refresh waits.
Tiers and coverage
The status panel reports newest counted block, lag, pool enrollment and complete windows per tier. Today's newest counted block alone does not prove every pool has 24 hours of history. Separate tail and backfill jobs keep those claims distinct.
| Tier or reading | How to use it |
|---|---|
| Active | Pools selected by recorded depth or activity receive priority sampling and live swap work. Check each pool's actual reading time. |
| Quiet | Lower-activity pools receive a slower background cycle and lower-priority historical work. |
| Dormant | Individual state and metadata reads are demand-driven. A stored pool can remain unread until needed. |
| Live tail | Counts recent canonical swap logs. Its newest block and lag describe how close the indexer is to the observed head. |
| Historical coverage | Records which block ranges were counted for a pool. A complete rolling window requires the entire interval, not just a recent swap. |
Read the numbers
DEX price is derived from pool state. Feed price is a separate reading from a recorded feed. Depth semantics depend on the pool: v3 uses observed quote-side holdings, while v4 uses a bounded estimate where per-pool reserves are unavailable. Read the field's label and API description.
Pool state older than ten minutes is stale for current price and depth. Invalid or future observation times also fail the freshness check. Historical observations retain their real timestamps. Exact rolling swap and transaction counts require complete canonical coverage and a current metrics reading.
A missing USD volume, market value, change percentage or feed premium stays a dash. A readable token name does not supply those measurements. Inspect the API's null values, stateCurrent, stateCheckedAt and coverage fields before using a result.
The token page
Listed token pages show the contract, issuer listing, available on-chain state, feed readings, pools and historical sections. Stock Tokens retain the issuer's multiplier semantics; apply conversions according to the field description. Bridged-asset pages may show origin and escrow reconciliation when those reads exist.
Holders and transfer history have their own ledger checkpoints. A partial holder table describes the indexed portion. First seen is the first recorded observation, while checked-at timestamps describe later reads. Discovered tokens use address routes so a ticker collision cannot claim a listed token's symbol URL.