How the registry reads the chain

The Registry daemon runs these 33 jobs against mainnet, chain 4663. A cadence is the delay after a run finishes. Jobs run independently, so a long scan can overlap another job while its own next run waits. The status page shows each job's last run, last success and available coverage.

The table uses the scheduler's base intervals. With a dedicated RPC, dex-state ticks every 30 seconds; its active-pool eligibility and published freshness threshold still use the 10-minute base interval. A faster tick works through due pools sooner. It does not reread every pool every 30 seconds.

• Read job status and coverage

A separate 15-minute service imports Robinhood's published Stock Token list, checks bytecode at listed addresses and refreshes ERC-20 metadata when due. Successful metadata reads are normally reused for seven days. Bridged assets come from a configured set of Ethereum tokens checked through the gateway router.

For an active Stock Token, the canonical job reads the EIP-1967 beacon storage slot and checks whether it points to AccessControlsRegistry. It also records the bytecode hash and the registry's recorded implementation address. The trust badge has its own listing, symbol and decimals checks, described on the trust page.

Lookalike discovery searches the first Blockscout results page for each tracked ticker. New candidates receive a beacon read; discovered DEX tokens can also supply folded-name collisions. Unicode normalization catches selected Greek and Cyrillic lookalikes and invisible characters. The result describes an address and matching labels; search coverage remains bounded.

• Read the trust decision rules

Chainlink answers carry the feed's update time. The reader uses a 24-hour heartbeat to mark an answer stale and keeps the previous successful observation when a call fails. Robinhood's quote comparison multiplies the bid/ask midpoint by the recorded token multiplier before comparing it with the feed.

The transfer ledger commits holder balance deltas, activity and block progress together. Newly tracked assets need their own historical coverage. Concentration and supply snapshots wait for their required scanners to catch up; a successful skipped run can still leave a figure unread.

The holder ledger stays 300 blocks behind head. A deeper reorganization is logged for investigation and its applied balances are not automatically reversed. Control-plane and supply scanners use separate hash checks and a 2,000-block rewind. Watch uses the different rollback path shown on its product page.

Holder labels combine known addresses, bytecode reads and mint-pattern inference. Blockscout holder counts remain a separate measurement. Daily history records available observations for the current UTC day, so an earlier missing day remains a coverage gap.

Pool discovery reads supported v3 and v4 events involving tracked assets or quote tokens. State reads select at most 1,000 due pools, reserving one slot in four for the oldest backlog. Active pools become due after ten minutes and quiet pools after a day; dormant state is refreshed on demand. Failed reads retain the previous observation and defer retry.

Token metadata uses batches of up to 40 and a 45-second work window. Successful reads become due after a day; failed reads retry after an hour. Pool-state and demand reads have daily allowances of 40,000 and 4,000 RPC methods and also consume the shared 200,000-call bucket. Other readers have their own pacing and limits.

The swap reader records raw token legs and block hashes, then measures coverage for each rolling window. Historical USD valuation remains unavailable. A v3 depth reading uses that pool's quote balance; v4 depth is a one-percent price-movement estimate bounded by the shared PoolManager's quote holdings. Read the displayed timestamps and coverage alongside the figures.

• Explore Markets

Bridge flows come from the configured L2 gateways. Escrow compares an Ethereum gateway's token balance with the stored L2 supply reading, which may have a different timestamp. Withdrawal waiting time is derived from recorded events and the configured challenge window; a claim still needs its own transaction.

Issuer document tracking compares linked-document headers such as ETag and Last-Modified. Issuer page tracking hashes cleaned page text. These observations help identify changed source material; they do not establish what a document's legal terms mean.

• Read issuer observations

Each job records its start, finish, result and available error. Failed jobs retry with increasing delays capped by their normal interval. Partial reads can retain earlier values, so a successful job run alone does not make every asset current.

A job is late when its last success is older than twice its base cadence, with a minimum one-minute allowance. A history scanner more than 10,000 blocks behind is filling; if its checkpoint stops moving beyond the larger of 30 minutes or twice its cadence, it is stalled. Missing figure timestamps are unread. Token metadata can remain filling while due or failed entries remain.

The Registry daemon reports every 15 seconds. After a minute without a heartbeat, its overall status is stale. Live permits jobs that are still filling; degraded includes failing, late, stalled or never-completed jobs. The separate observer records those verdicts and changes every minute without advancing a job's own timestamps.

The status API includes checkedAt and ages measured from that reading, and caches the same reading for ten seconds. Read the verdict in the response body: stale data can still return HTTP 200. Per-figure newest times describe the newest recorded observation, so use asset timestamps and scanner coverage for a particular token.

• Inspect freshness and unread figures