Why crypto data discovery needs a knowledge layer
The crypto data ecosystem now includes hundreds of APIs, indexers, RPC providers, market data feeds, on-chain data APIs, and emerging agent-facing interfaces.
For developers, the challenge is evaluating coverage, reliability, pricing, and integration fit. For AI agents, the challenge is harder: discovering sources, understanding capability boundaries, and comparing providers without hallucinating unsupported claims.
PubFi Discovery is designed to solve both problems with the same knowledge layer: a source map that humans can browse and retrieval systems can read safely.
Discovery is not just a directory
Most API directories are optimized for human browsing. PubFi Discovery is structured for both human navigation and machine retrieval.
Every page is designed around reusable evidence:
- Canonical URLs for search and citation stability.
- Structured entity relationships between sources, chains, categories, comparisons, and topics.
- Status boundaries that separate public facts from callability.
- Agent-readable exports for retrieval systems.
- Retrieval-friendly summaries for crypto API comparison.
The goal is not only helping users discover blockchain data APIs, but helping AI systems retrieve source facts safely.
Discovery is published in multiple formats
PubFi Discovery is available through several public surfaces:
- HTML pages for developers comparing crypto data APIs.
- llms.txt for lightweight discovery.
- llms-full.txt for retrieval systems that need the full Discovery corpus.
- agents.md for capability boundaries, public resources, and agent-readable documentation.
These formats serve different readers, but they point back to the same claim-safe Discovery records.
How PubFi Discovery organizes the map
PubFi Discovery separates broad API discovery from source-specific evaluation so each page has a clear job.
| Page type | What it helps answer | Example |
|---|---|---|
| Source | What is this API source and what is its status? | Subscan API |
| Chain | Which sources fit one ecosystem? | Polkadot data APIs |
| Category | Which source type fits the workflow? | Market data APIs |
| Comparison | How do two choices differ? | Subscan vs SubSquid |
| Topic | Which capability-first question should be explored? | MCP crypto data APIs |
Topic pages answer workflow-first questions
Not every discovery question starts with a provider. Many teams start with a capability question:
- Which crypto APIs support MCP?
- Which providers expose agent-friendly interfaces?
- What data sources fit x402-style payment flows?
Topic pages are designed for these workflow-first questions. They help teams compare the shape of demand without claiming that PubFi exposes every capability as a live gateway route.
Claim-safe status matters
Many AI systems treat documentation, blog posts, and landing pages as executable truth. Without explicit capability boundaries, agents can incorrectly assume an API is callable, available through a gateway, or exposed through MCP.
PubFi Discovery does not treat every listed source as directly callable through PubFi. Pages separate public source profiles, request-integration status, degraded availability, and actual gateway availability.
That boundary matters for agents. If a source page says a route needs re-verification, an agent should not turn it into a live callable tool. If an MCP or x402 topic page discusses demand, it should not imply that PubFi publishes a public MCP manifest or x402 payment endpoint today.
How an agent should read PubFi Discovery
- Start with llms.txt to find the public Discovery entry points.
- Use llms-full.txt for the full text corpus when retrieval needs source facts, comparisons, and boundaries.
- Open the canonical HTML page, such as /discovery/api/subscan, when the workflow needs the page owner, status labels, links, and user-facing context.
- Read agents.md before assuming anything about gateway calls, MCP manifests, or x402 payment execution.
Accurate context before execution
Discovery is ultimately a knowledge layer. Developers use it to evaluate crypto data sources. Agents use it to retrieve source facts and capability boundaries.
Both need the same thing: accurate context before execution. That is why PubFi Discovery is built as more than a directory.