What our labels mean
“Verified” is only meaningful with a definition, evidence, a timestamp and a scope. These are the rules the verification engine applies. They describe the evidence behind information, never the quality, legality, value or safety of an asset.
Status vocabulary
Working draftMatches a curated official source, within its freshness window.
At least one curated official source supports the value, no other source contradicts it, and it was observed within the field's max_age. Verified describes the evidence, not the quality, legality or value of the asset.
Last observation is older than this field's freshness threshold.
The value had support when observed, but now - observed_at exceeds max_age_seconds. Stale values are shown with their age and must not be treated as real-time.
Sources disagree. Held for operator review, not silently resolved.
Two or more sources report different values. Every candidate is returned with its source, and the item enters the review queue (FR-07). No candidate is promoted automatically.
No acceptable source. Value is null, never zero or 'safe'.
No curated source provides this field. The API returns null and the UI shows it as missing. Absence of data is never displayed as a default value.
A value exists, but it is not backed by a curated source.
The value comes only from non-curated sources (e.g. token metadata, community lists), or identity verification failed. A ticker or name match alone is never evidence.
Asset-level status
- 01If the contract address does not match the official or curated registry, the asset is unverified, whatever its name or ticker says.
- 02Otherwise, any conflicting field makes the asset conflicting.
- 03Otherwise, any stale field makes the asset stale.
- 04Otherwise it is verified. Unknown fields don’t downgrade a correctly identified asset, but they lower its field coverage and appear as known unknowns.
Cross-checks. On-chain reads (decimals, uiMultiplier) are compared with the official registry. When they agree, the field cites both sources. When they disagree, it becomes conflicting and goes to the review queue.
Source weight
- 1
Official registry
The issuer-published asset list behind the docs' Token Contracts table. Synced hourly with a content hash; additions, renames and delistings become change events or reviews.
- 2
Curated registry
An operator-reviewed entry linking a chain + address to an asset. Every change is audit-logged with actor, time and reason.
- 3
Official docs / issuer notice
Network or issuer documentation. Retrieved with URL, time and content hash.
- 4
On-chain read
Values read over RPC (e.g. decimals(), uiMultiplier()). Records block number. Proves what the contract says, not who stands behind it.
- 5
Block explorer
Useful context. Labels can be user-submitted, so never authoritative.
- 6
Community
Leads for research. Never sufficient on its own.
Open questions
PRD §20- Who is authorised to add sources or change the registry beyond the founding operator?
- How are corrections and disputes processed and communicated to integrators?
- Which claims, if any, deserve an on-chain attestation?