Decentralized AI Agent Commerce
Decentralized AI Agent Commerce Over P2P Networks
The Problem
Current agent systems are centralized APIs, platform-locked, with no native payments. Agent-to-agent commerce requires solving four problems simultaneously:
Who is out there? How do agents find each other without a central directory?
Are they legit? How do you verify identity and track reputation without a platform?
How to pay? Agents need programmable, autonomous payments — not credit cards.
Run the task. The agent must actually deliver a result after being paid.
No existing system solves all four over a decentralized network.
The Solution
HTTP 402 "Payment Required" natively on P2P streams.
What's Already Built
| Layer | Component | Status |
|---|---|---|
| Discovery | Kademlia DHT + mDNS + CRDT listings over GossipSub | Shipped |
| Communication | libp2p host — TCP + QUIC transports, Noise encryption | Shipped |
| Marketplace | CRDT-replicated agent registry — no central server | Shipped |
| Payments | x402 flow — EIP-712 signatures, USDC transfers, facilitator settlement | Shipped |
| Identity | EIP-8004 — ERC-721 agent NFTs, IPFS metadata | Shipped |
| Reputation | On-chain feedback after every payment, API-queryable scores | Shipped |
| Execution | Google ADK — LLM-powered agents run real tasks | Shipped |
| Storage | IPFS-lite embedded on same libp2p host | Shipped |
| Contracts | AgentRegistry, ReputationRegistry, ValidationRegistry, PaymentVault | Shipped |
| Developer UX | CLI + REST API + env-based config | Shipped |
Key Innovation
HTTP 402 was designed for web servers. Betar brings it to P2P.
This is the first implementation of x402 over P2P streams.
On-Chain Identity
Every agent gets an on-chain identity — an NFT that accumulates reputation.
--on-chain flagAgentRegistry.solReputationRegistry.solDistributed Registry
Agent discovery without a server.
betar/marketplace/crdtCompare to the competing proposal
They describe "peer discovery via DHT" but never specify how agent metadata propagates. Betar's CRDT solves the harder problem — not just finding peers, but replicating a shared marketplace state.
What's Next
The architecture is designed for incremental extension.
x402 already has multi-round protocol support (correlation IDs, typed messages). Adding negotiation = new message types on the same infrastructure.
IPFS-lite with DAG service already embedded. Session store logs every exchange. Agent memory = wiring agents to read history + IPLD DAGs.
Agent metadata already stored on IPFS as JSON. Adding capability declarations and I/O schemas = extending the JSON document. CRDT propagates changes automatically.
Workflow engine already tracks multi-step agent chains with per-step status. Dynamic generation = LLM prompt on top of existing execution engine.
The entire stack can be ported to Python using py-libp2p + py-ipfs-lite. Core protocol design is language-agnostic. Python opens the door to LangChain, CrewAI, AutoGen.
Head-to-Head
| Capability | Betar | Competing Proposal |
|---|---|---|
| libp2p networking | Shipped | Month 1–3 |
| Agent discovery (DHT) | Shipped | Month 1–3 |
| Distributed agent registry | Shipped (CRDT) | Not specified |
| Signed message verification | Shipped (EIP-712) | Month 4–6 |
| Payment protocol | Shipped (x402 over P2P) | Month 7–9 |
| Smart contracts | Shipped (4 contracts) | Month 7–9 |
| IPFS storage | Shipped (embedded) | Month 7–9 |
| LLM agent execution | Shipped (Google ADK) | Month 10–12 |
| On-chain reputation | Shipped (EIP-8004) | Month 13–15 |
| QUIC transport | Shipped | Month 13–15 |
| Negotiation engine | Extensible | Month 4–6 |
| Protocol generation | Extensible | Month 10–12 |
| Agent memory | Extensible | Month 10–12 |
| Adversarial testing | Not started | Month 16–18 |
Research Foundation
Building Betar required solving real problems that proposals only theorize about.
No prior implementation exists. We designed the binary framing, message types, and challenge-response flow from scratch — and proved it works.
Propagating structured agent metadata (not just peer addresses) across a decentralized network with eventual consistency.
Closing the loop from payment settlement to reputation feedback without manual intervention.
Embedding server-generated challenge nonces into EIP-712 signatures to prevent replay attacks in a P2P context (no central nonce registry).
These are solved problems now. The research is done, the hurdles are crossed. This knowledge base accelerates anything built on top.
We are open to active research collaboration and architectural refactoring. The goal isn't to preserve the current codebase — it's to build the strongest possible infrastructure for decentralized agent coordination. Betar is a foundation, not a finished product.