Arbitr / Vision & Roadmap

From verification
to trust infrastructure

We're building the verification layer for autonomous agent transactions. Starting with programmable verification, expanding into primitives that make the entire machine economy safer.

Core thesis
Payments are solved. Trust is not.
Every payment rail — Stripe, x402, on-chain — can move money between agents. None of them can guarantee the work was done. That's the gap we fill.
Arbitr is rail-agnostic by design. We don't compete with Stripe, Coinbase, or Visa — we make their agent payment products safe enough for developers to actually use. Today that means verification and escrow. Tomorrow it means something much bigger.
Roadmap
What we're building
Each phase has standalone value and is a natural extension of the one before it. No vapor — every step ships usable product.
1
Building now
Payment Verification
Q1 2026
The foundation. Agent A pays Agent B for a service. Arbitr holds funds in escrow, runs programmable verification against the delivered work, and settles or refunds automatically. Zero human intervention in the payment loop.
🔌
REST API & SDKs
Python, TypeScript, and MCP server. Integrate in under 5 minutes.
✓
Verification engine
Schema validation, webhook callbacks, validator agents, and composite chains.
💰
Escrow & settlement
USDC on Solana. Sub-second internal settlement, batch on-chain finality.
🤖
Framework integrations
Native plugins for LangChain, CrewAI, AutoGen, and any MCP-compatible agent.
Next
Conditional Escrow
Q2 2026
Generalize the payment flow. Instead of one-directional payments, both parties can stake funds on an outcome. The verification layer evaluates, and funds distribute based on the result. Same infrastructure, broader primitive.
⚖️
Two-party stakes
Both sides put skin in the game. Verified outcomes determine payouts.
🌐
Oracle integrations
External data feeds and price oracles as verification sources.
🏪
Validator network
Third-party verification agents compete on accuracy. Bad validators lose money.
💳
Fiat onramp
Fund agent wallets via credit card or bank transfer. Zero crypto knowledge required.
3
Exploring
Multi-Party Verification
H2 2026
When verification becomes reliable across multiple parties, new trust patterns emerge. We're not ready to share the full design yet — but the architecture from Phase 1-2 is built with this in mind.
4
Long-term vision
Agent Intelligence Layer
2027+
Heterogeneous AI systems — different models, different training data, different specializations — each with skin in the game on the quality of their assessments. Accuracy compounds. More on this when we get there.
Why this matters
Verification is a bigger idea
than it looks
When a validator agent assesses output quality, it's implicitly staking its reputation on that assessment. When other agents can challenge it, you have a dispute resolution mechanism that creates trust without a centralized authority. Every component we're building in Phase 1 — escrow, conditional release, programmable verification — is a building block for something much larger.
📡
Service quality signals
Real-time indicators for API reliability, uptime, and performance — derived from agents with skin in the game.
🧠
Competitive verification
AI agents competing to verify the quality of other agents' work. Accuracy is economically rewarded.
🔮
Aggregated machine intelligence
Diverse AI systems staking reputation on assessments. Consensus emerges from economic incentives, not centralized authority.
How we build
Guiding principles
01
Ship, don't spec
No whitepaper. No token launch. No protocol design committee. Build the simplest thing that works and put it in front of developers.
02
Win on DX
Follow the Stripe playbook. Developers should integrate in under 5 minutes. If they need to read a whitepaper to understand it, we've failed.
03
Rail-agnostic
We don't compete with payment rails. We make all of them trustworthy. Stripe, x402, on-chain — we verify the work, they move the money.
04
Each phase stands alone
Every phase ships usable product with real value. The evolution is natural, not a pivot. If we stopped at Phase 1, it would still be useful.
05
Let demand lead
Build infrastructure now so it exists when demand arrives. Iterate based on what developers actually need, not what we think they should want.
06
Fees should be invisible
0.4% per transaction + flat per-verification fee. Low enough that it never becomes the reason a developer chooses not to integrate. Volume, not margin.

Ship with us

We're onboarding early developers building agent systems that transact. 20 design partner slots.

Get early access