The AI agent stack is crowded. New protocols launch weekly. If you’re building for agents, you need to know what solves what - and what’s missing.
The missing piece: a data layer that any agent can query and pay automatically.
Here’s the answer: OnchainDB is the data layer with payments built in.
Traditional databases cost you money. OnchainDB earns you money - while giving you access to data across app boundaries without the sourcing overhead.
ERC-8004] COM[Communication
MCP, ACP] PAY[Payments
x402] end subgraph Data["DATA ACCESS"] OCDB[OnchainDB
Query engine
Cross-app JOINs
Pay-per-query
Immutable audit] end subgraph Infra["INFRASTRUCTURE"] ST[Storage
Celestia] SE[Settlement
Tempo, USDC] MEM[Agent Memory
Recall] PD[Personal Data
Vana, ODL] end A & S --> ID & COM & PAY ID & COM & PAY --> OCDB OCDB --> ST & SE & MEM & PD style OCDB fill:#3b82f6,stroke:#1e40af,color:#fff
Not an identity protocol. Not a payment rail. Not a personal data network. We’re the database that lets any application query data across apps and pay automatically - the infrastructure that makes Satya Nadella’s “multi-repo CRUD” vision actually work.
The Stack at a Glance
| Layer | Problem | Solution | OnchainDB? |
|---|---|---|---|
| Identity | “Can I trust this agent?” | ERC-8004, ENS | No |
| Communication | “How do agents talk?” | MCP, ACP | No |
| Payments | “How do agents pay?” | x402, Tempo | We implement x402 |
| Data Access | “Where do agents get data?” | OnchainDB | Yes - this is us |
| Agent Memory | “Where do agents store state?” | Recall | No |
| Personal Data | “Who owns user data?” | Vana, Open Data Labs | No |
We don’t compete with the other layers. We’re the missing piece that connects them.
Traditional Databases
The obvious comparison. We’re all databases (MongoDB, Supabase). Here’s why OnchainDB wins for agent workloads:
| Feature | MongoDB/Supabase | OnchainDB |
|---|---|---|
| CRUD operations | Yes | Yes |
| Built-in payments | No | Yes - HTTP 402 on every query |
| Cross-app queries | No - siloed | Yes - JOIN across any app |
| Data monetization | No | 70% to you, 30% platform |
| Immutable audit trail | No | Yes - Celestia DA |
| Who pays whom | You pay them | They pay you |
Use MongoDB/Supabase if you’re building a traditional app with no agent access, no monetization needs, and you’re fine paying hosting bills forever.
Use OnchainDB if you want your database to generate revenue. Every query from an AI agent pays you. Cross-app JOINs work out of the box. Your data has a permanent, verifiable audit trail.
The math is simple: Supabase costs you $25-500/month. OnchainDB earns you money from day one.
Observability Platforms
Splunk, Datadog, Azure Log Analytics - these are built for internal observability. Your team queries your logs to debug your systems.
OnchainDB is for external observability - when your logs have value to others.
| Splunk / Datadog / Azure | OnchainDB | |
|---|---|---|
| Use case | Internal ops, debugging | External monetization, audit |
| Cost model | You pay them | Others pay you |
| Data monetization | No | Yes - sell access to logs |
| Cross-org queries | No | Yes - query across publishers |
| Data layer | Deletable, mutable | Immutable (Celestia DA) |
| Index retention | Configurable | Configurable (data retrievable from DA) |
Use Splunk/Datadog for internal dashboards, alerting, and debugging.
Use OnchainDB when your logs have external value:
- Threat intel - Security vendors monetize IOC feeds, attack patterns
- Compliance records - Auditors need verifiable, immutable proof
- AI transparency - Chain-of-thought logs for accountability
- Cross-org analytics - Aggregate logs across multiple publishers
Internal observability stays internal. External observability belongs on OnchainDB.
Communication Protocols
MCP is Anthropic’s protocol for connecting agents to tools. 97 million monthly SDK downloads. 10,000+ public servers. Now governed by the Linux Foundation with OpenAI and Block. It’s the “USB-C of AI” - standardizing how agents discover and call tools.
ACP refers to multiple protocols: Agent Commerce Protocol (Stripe/OpenAI), Agent Communication Protocol (Virtuals/Base), and Agent Client Protocol (Zed). All handle communication or commerce flows.
None of them store data. They’re protocols, not infrastructure.
| MCP / ACP | OnchainDB | |
|---|---|---|
| What it is | Communication protocols | Database + query engine |
| Data storage | No | Yes (Celestia + materialized views) |
| Payments | No (MCP) / Some (ACP) | Yes (HTTP 402) |
| Query engine | No | Yes (cross-app JOINs) |
How they work together:
MCP handles discovery and routing. OnchainDB handles the actual data and payment. An agent using ACP for commerce still needs somewhere to query product data - that’s OnchainDB.
Building an MCP server for OnchainDB? Expose your app’s data to any MCP-compatible agent. They discover via MCP, query via OnchainDB, pay via x402. Three protocols, one integration.
Trustless Agents
ERC-8004 is an Ethereum standard from MetaMask, Google, and Coinbase engineers. It defines three registries:
- Identity Registry - Agent handles (ERC-721)
- Reputation Registry - Feedback and scoring
- Validation Registry - zkML verifiers, TEE oracles
ERC-8004 answers: “Should I trust this agent?”
OnchainDB answers: “Where does this agent get its data?”
| ERC-8004 | OnchainDB | |
|---|---|---|
| Purpose | Trust verification | Data access |
| What it stores | Identity, reputation | Application data |
| Payments | Uses x402 | Uses x402 |
How they work together:
ERC-8004 tells you whether to query. OnchainDB is how you query.
Example: Trusted Data Marketplace
High-reputation providers get more queries. Bad actors get filtered out. Trust and data access work together.
Payment Infrastructure
x402
x402 is Coinbase’s payment protocol. It revives HTTP 402 (“Payment Required”) for instant stablecoin micropayments. 500,000+ weekly transactions across Base, Solana, and BNB Chain.
OnchainDB implements x402. We’re not a competitor - we’re a consumer.
30% to platform
x402 moves the money. OnchainDB stores and serves the data.
Tempo
Tempo is Stripe and Paradigm’s payments-first L1. $500M raised at $5B valuation. Partners: Mastercard, UBS, Klarna.
| x402 | Tempo | OnchainDB | |
|---|---|---|---|
| Type | Payment protocol | L1 blockchain | Database |
| Purpose | HTTP micropayments | Payment settlement | Data access + queries |
| Stores data | No | No | Yes |
| Query engine | No | No | Yes |
Tempo is a settlement layer. x402 is a payment protocol. OnchainDB is a data layer.
We’re adding Tempo support for payment settlement alongside Celestia. When an agent queries OnchainDB, Tempo can settle the micropayment. Different layers, same stack.
Personal Data Networks
Vana
Vana is an L1 for user-owned personal data. 1M+ users pool data (Reddit posts, health metrics, DNA) into DataDAOs for AI training.
How DataDAOs work:
- Users contribute personal data to Data Liquidity Pools (smart contracts)
- Proof-of-contribution validates data quality
- Contributors earn governance tokens and royalties
- AI companies pay to train on the pooled data
Open Data Labs
Open Data Labs built Vana and runs a data playground with 16+ queryable datasets: Instagram, Twitter/X, Telegram, sleep patterns, credit transactions, Spotify history. Each dataset comes from user contributions via DataDAOs with governance tokens (MIND, REM, BOPS).
| Vana / Open Data Labs | OnchainDB | |
|---|---|---|
| Data type | Personal (social, health, genetic) | Commercial (products, prices, APIs) |
| Data flow | C2B - users contribute to pools | B2B/A2A - apps serve agents |
| Use case | AI model training (batch) | Real-time queries (live) |
| Revenue model | Pool once, earn royalties | Pay per query |
| Governance | Token-based DAO voting | App owner sets pricing |
Vana = Personal data pooled for training. Users contribute their Reddit history, sleep patterns, genetic data.
OnchainDB = Application data queried in real-time. Retailers expose inventory. APIs expose prices. Every query pays instantly.
When to use together
DataDAOs aggregate personal data. But AI agents need to query that aggregated data in real-time.
Example: Health AI Agent
Vana handles contribution and governance. OnchainDB handles query and payment. The DataDAO earns from every agent query without building query infrastructure.
Example: Sentiment Analysis
Vana is the data collection layer. OnchainDB is the data access layer. They stack.
Agent Memory Networks
Recall is a “decentralized intelligence network” born from the merger of Textile (Tableland) and 3Box Labs (Ceramic) in early 2025. $42M raised from Bessemer, Coinbase Ventures, and Union Square Ventures. Built on Base.
Recall provides a memory layer for AI agents - storing knowledge bases, predictions, chain-of-thought logs, and performance history. Agents build reputation through verifiable track records.
Two components:
- Agent Memory - On-chain storage for agent-internal data (logs, predictions, reasoning)
- Competitive Arenas - AI models compete on tasks (trading, coding, reasoning) with tokenized rankings
| Recall | OnchainDB | |
|---|---|---|
| Primary focus | Agent memory + reputation | Data access + monetization |
| Competitive arenas | Yes (AI rankings, token staking) | No |
| Revenue model | Token staking on agent portfolios | Pay per query (reads and writes) |
| Query engine | No | Yes (cross-app JOINs) |
| Can store agent logs | Yes | Yes (we’re usage-agnostic) |
Recall = Specialized for agent memory with built-in reputation and competitive arenas.
OnchainDB = General-purpose data layer. Can store agent memory and serve external data - with payments on every operation.
How they work together:
Recall specializes in agent memory with competitive rankings. OnchainDB is the general-purpose data layer - store agent logs, serve external data, or both. The difference: Recall has arenas and token staking; OnchainDB has cross-app queries and pay-per-operation.
Beyond Data Access: Append-Only Ledger
OnchainDB is append-only by design. Every write is immutable, stored permanently on Celestia DA. This isn’t just for audit trails - it enables a new architecture: code offchain, data onchain.
Instead of writing smart contracts, you can:
- Store state in OnchainDB tables (immutable, verifiable)
- Run business logic in your application (flexible, upgradeable)
- Get blockchain guarantees without blockchain complexity
Use cases this enables:
| Application | How It Works |
|---|---|
| Stablecoins | Balances in tables, transfers as appends, mint/burn logic offchain |
| Token systems | Ownership records in collections, transfer validation in your app |
| Voting/governance | Votes as immutable records, tallying logic offchain |
| Asset registries | Title records, ownership history, all verifiable |
| Settlement systems | Transaction logs, reconciliation, audit-ready by default |
| Loyalty programs | Points ledger, redemption history, cross-merchant queries |
The pattern:
Smart contracts are powerful but rigid. OnchainDB gives you the immutability and verifiability of a blockchain with the flexibility of a traditional database. Upgrade your logic anytime - your data history remains tamper-proof.
Why Publish to OnchainDB
OnchainDB serves data out - but first, someone has to put data in. Here’s why data providers are publishing:
| Data Provider | What They Publish | Who Queries | Revenue Source |
|---|---|---|---|
| E-commerce retailers | Product catalogs, inventory, prices | Shopping/comparison agents | Per-query from price aggregators |
| API providers | Pricing, rate limits, capabilities | Developer agents | Per-query for API discovery |
| Financial data vendors | Market data, prices, indicators | Trading/analytics agents | Per-query micropayments |
| IoT networks | Sensor readings, telemetry | Monitoring agents | Per-query for real-time data |
| Content platforms | Metadata, summaries, embeddings | Discovery agents | Per-query for content search |
| Logistics providers | Shipping rates, ETAs, capacity | Procurement agents | Per-query for supply chain |
| DataDAOs | Aggregated personal data insights | Research/analytics agents | Per-query with contributor splits |
| Security vendors | Threat intel, IOCs, attack logs | SOC agents, SIEM tools | Per-query for threat feeds |
| AI agents | Chain-of-thought logs, decisions | Auditors, compliance, researchers | Per-query for transparency |
| Any application | Audit trails, event logs | Compliance, forensics, analytics | Immutable retention + monetization |
The pitch is simple: You already have a database. Sync a copy to OnchainDB and turn reads into revenue. Or let others write to your collections and charge for that too.
What changes:
| Before OnchainDB | After OnchainDB |
|---|---|
| Build custom APIs | Publish once, query anywhere |
| Negotiate data deals | Automatic per-query payments |
| Pay for bandwidth | Get paid for bandwidth |
| Data sits unused | Data generates revenue |
| No audit trail | Immutable provenance on Celestia |
Every query is a transaction - reads and writes. Every transaction pays the data provider. No sales team required.
When to Use OnchainDB
Our primary focus is AI agents - they generate high query volumes and need frictionless cross-app data access. But OnchainDB is usage-agnostic:
| If you’re… | Use OnchainDB to… |
|---|---|
| Building an AI agent | Query data from multiple apps, pay automatically |
| Fine-tuning models (Unsloth, Axolotl) | Pull training datasets with automatic payment |
| Running a DataDAO (Vana) | Expose aggregated data to any consumer, earn per query |
| Building MCP tools | Add a monetizable data source to your MCP server |
| Publishing data | Monetize every read without building payment infrastructure |
| Need audit trails | Get immutable, verifiable data history on Celestia |
| Running analytics pipelines | Aggregate cross-app metrics, pay providers automatically |
OnchainDB is the data layer you add when:
- Your data should generate revenue
- Any consumer (agent, script, app) needs to query across app boundaries
- You need verifiable, immutable records
- You don’t want to build payment infrastructure
OnchainDB is NOT for:
- Personal data pooling for AI training (use Vana)
- Agent identity/reputation (use ERC-8004)
- Payment settlement rails (use Tempo, x402)
- Agent-to-agent communication (use MCP, ACP)
We do one thing: queryable data with payments built in.
npm install @onchaindb/sdk
Start building or follow us on Twitter.