# PubFi Discovery: A Searchable Knowledge Layer for Crypto Data APIs

> PubFi Discovery is a searchable knowledge layer for crypto data APIs, helping developers and agents compare sources, formats, and capability boundaries.

Published: Published June 3, 2026
Updated: 2026-06-03T00:00:00.000+08:00
Canonical HTML: https://pubfi.ai/blog/pubfi-discovery-searchable-knowledge-layer-for-crypto-data-apis
Markdown companion: https://pubfi.ai/blog/pubfi-discovery-searchable-knowledge-layer-for-crypto-data-apis.md

## 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](https://pubfi.ai/discovery) for developers comparing crypto data APIs.
- [llms.txt](https://pubfi.ai/llms.txt) for lightweight discovery.
- [llms-full.txt](https://pubfi.ai/llms-full.txt) for retrieval systems that need the full Discovery corpus.
- [agents.md](https://pubfi.ai/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.

<table>
    <thead>
      <tr>
        <th>Page type</th>
        <th>What it helps answer</th>
        <th>Example</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>Source</td>
        <td>What is this API source and what is its status?</td>
        <td>
          <a href="https://pubfi.ai/discovery/api/subscan">Subscan API</a>
        </td>
      </tr>
      <tr>
        <td>Chain</td>
        <td>Which sources fit one ecosystem?</td>
        <td>
          <a href="https://pubfi.ai/discovery/chain/polkadot">Polkadot data APIs</a>
        </td>
      </tr>
      <tr>
        <td>Category</td>
        <td>Which source type fits the workflow?</td>
        <td>
          <a href="https://pubfi.ai/discovery/category/market-data">Market data APIs</a>
        </td>
      </tr>
      <tr>
        <td>Comparison</td>
        <td>How do two choices differ?</td>
        <td>
          <a href="https://pubfi.ai/discovery/compare/subscan-vs-subsquid">Subscan vs SubSquid</a>
        </td>
      </tr>
      <tr>
        <td>Topic</td>
        <td>Which capability-first question should be explored?</td>
        <td>
          <a href="https://pubfi.ai/discovery/topic/mcp-crypto-data-api">MCP crypto data APIs</a>
        </td>
      </tr>
    </tbody>
  </table>
## 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. PubFi's hosted MCP manifest describes the generic authenticated route-tool surface; MCP or x402 topic pages must still not imply provider-specific endpoint tools, unauthenticated supplier execution, or a live x402 payment endpoint.

## How an agent should read PubFi Discovery

1. Start with [llms.txt](https://pubfi.ai/llms.txt) to find the public Discovery entry points.
2. Use [llms-full.txt](https://pubfi.ai/llms-full.txt) for the full text corpus when retrieval needs source facts, comparisons, and boundaries.
3. Open the canonical HTML page, such as [/discovery/api/subscan](https://pubfi.ai/discovery/api/subscan), when the workflow needs the page owner, status labels, links, and user-facing context.
4. Read [agents.md](https://pubfi.ai/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.