How to build a research agent that buys its own data
A walkthrough for developers: wire an agent to discover a real-world data API, pay for a single call in USDC from one balance, and get back a signed receipt.
The problem this solves
A research agent rarely reads one API. It reads many: weather for a logistics model, prediction-market odds, company news, on-chain metrics, whatever the task needs. Going direct to each provider means a signup, a key, and an invoice per source, and no single ledger to answer a simple question: what did this agent spend today, and on what.
The fix is collapsing the many into one: one identity, one prepaid balance, one signed receipt per call, across every provider in a catalog.
1. Use a scoped key, not a wallet
If an agent only spends from a pre-funded balance, it should never hold a Solana private key. A scoped, revocable API key tied to the balance (not to signing authority) is issued from the dashboard, and it can be revoked without moving funds. This is the least-privilege design point worth keeping: humans fund the balance with a connected wallet in the browser, so no private key ever needs to reach the agent.
2. Search, not memorize
Discovery is semantic: an agent describes what it needs in plain language rather than looking up a slug it has to remember. Results carry a listing id, a preview of callable endpoints, and the price per request in micro-USDC, visible before anything is spent.
3. Make the call, keep the receipt
A single call returns the upstream response, the exact amount charged, and a request id anchoring a signed receipt. That receipt is not decoration: the moment an agent is spending money on your behalf, an auditable trail of what it bought is the thing that actually matters, not just the data itself.
4. Same flow, whichever surface fits
The same balance and the same receipts are reachable through a TypeScript SDK, a CLI, plain REST against the gateway, or as MCP tools for an agent that lives in an MCP client. Multi-surface on purpose: use whichever your stack already speaks, without ten different integrations behind it.
Funding, briefly
Top-ups run over the x402 rail. In gasless mode the platform covers Solana fees and rent, so the balance needs only USDC. USDC is the first settlement rail shipped; it is not meant to be the only one, more rails are on the roadmap, but it is what is live today, so it is what this walkthrough uses.
What this is and is not
What works today: one agent reading many real-world data providers through one identity, one prepaid balance, and one signed receipt per call. What is not solved yet: a full entitlement and compliance layer for regulated market data, that work is ahead, not behind, and the catalog is still being filled out provider by provider rather than complete.
Related concepts
More guides
Frequently asked questions
No. A human funds the prepaid balance once with a connected wallet in the browser. The agent authenticates with a scoped API key tied to that balance, never a private key, which keeps the agent’s credential surface to one revocable token.
Every call returns a request id anchoring a signed receipt alongside the exact amount charged. Reviewing usage means reading one ledger, not reconciling invoices across every provider the agent touched.
Whichever the stack already speaks: a TypeScript SDK for application code, a CLI for scripting and exploration, plain REST against the gateway, or MCP tools if the agent lives in an MCP client. All four hit the same balance and the same receipts.