On-Chain Truth Oracle
Recorded addresses and observations give the agent a chain it can query.
Last verified against production: . See current limits and availability.
From a source to a usable fact
Fletch records the chain configuration and deployment addresses the builder needs in chain facts. The registry imports Robinhood's listings, checks contract metadata and stores observations from the chain. Discovery stores other tokens separately so appearing in a pool never turns a token into an issuer listing.
Jobs write their results and progress to Postgres. Pages, JSON responses, MCP tools and alerts read those records. A block number or timestamp travels with the observation; the interface can show when the value was read and whether the requested history is covered.
Where the data comes from
Scheduled jobs read chain and issuer sources into shared Postgres tables. Product pages, JSON responses, MCP tools and alert formatting use those stored records.
Inputs
- Chain: RPC calls, event logs and explorer responses.
- Issuer: Published asset lists and tracked documents.
Read and store
- Scheduled jobs: Sync, probe, index and record changes.
- Postgres: Keep records, source details and read times.
Shared readers
- Pages: Markets, tokens and registry views.
- JSON: Documented API responses.
- MCP: Tools that read the same records.
- Alerts: Registry and trust context for messages.
Each job has its own cadence and coverage. A stored read time describes that record; it does not guarantee the current chain state.
Give the agent the relevant facts
Every build receives chain configuration, contract guidance and short instructions for querying Fletch. A token or market question can fetch the relevant endpoint on demand. This keeps a simple app request from carrying a dump of unrelated pools.
Resolve the complete address, inspect the trust verdict and keep the observation time. For market data, also inspect stateCurrent and coverage. An unread price is a missing input; the agent must leave it empty or explain that its read is still needed.
curl --fail-with-body https://fletch.now/api/v1/status curl --fail-with-body https://fletch.now/api/v1/tokens/0x6bac06600d220ac5ac281ad1f504d2cf0f90f6e6
Identity, price and coverage answer different questions
The verified badge comes from listing and metadata checks. Stock Token beacon observations provide a separate canonical check. A feed answer and a DEX price describe different sources, and each can become stale. Complete rolling activity requires counted logs across the whole window.
A known name can therefore sit beside an unread price or a partial holder ledger. Follow the source and coverage rather than filling the gap with the current price from another pool. The registry reading chapter lists the actual jobs and their intervals.