The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MCP Server listing page.
Non-custodial USDC escrow + AI arbitration for agent-to-agent payments on Base.
Two agents lock USDC into a contract, one delivers, the other confirms or disputes, and a neutral AI arbiter resolves. Arbitova never holds the money — the contract does.
No API keys. No registration. No custody. Your Ethereum address is your identity.
EscrowV1 at 0xA8a031bcaD2f840b451c19db8e43CEAF86a088fC on Base Sepolia — verified on Basescan, mainnet launching after auditA2A-ESCROW-RFC-v0.1/.well-known/arbitova.jsondocs/tutorials/15-min-paid-agent.mdEvery A2A / agent-commerce spec in the wild — MCP, Google's A2A, ERC-7683, Coinbase's Agent Commerce — defines how agents talk. None of them define how money moves when the agents don't trust each other.
Arbitova is the missing settlement primitive:
createEscrow → markDelivered → {confirmDelivery | dispute → resolve | cancel}. No hidden branches, no admin override.DISPUTED, not into seller payout. Silence is safer than a wrong confirmation.keccak256 is stored on-chain. The full verdict history is queryable at /verdicts — no aggregation, no delay.This is not a marketplace. There is no Arbitova account, no listing fee, no Pro tier. The protocol is the whole product.
Seller-side, arbiter-side, browser wallet integration: see packages/sdk-js/README.md.
Six tools: arbitova_create_escrow, arbitova_mark_delivered, arbitova_confirm_delivery, arbitova_dispute, arbitova_cancel_if_not_delivered, arbitova_get_escrow. All sign locally via ethers v6. Your private key never leaves the process.
Omit ARBITOVA_AGENT_PRIVATE_KEY for read-only introspection mode (useful for observability).
Two terminal states not drawn: CANCELLED (buyer calls cancelIfNotDelivered after delivery window) and auto-escalation into DISPUTED if the review window expires without confirmation.
Three end-to-end A2A demos on Base Sepolia with a live AI arbiter:
Each demo runs the full CREATED → DELIVERED → CONFIRMED (or DISPUTED → RESOLVED) flow with real on-chain transactions.
| Package | Purpose |
|---|---|
@arbitova/sdk | Node.js / browser SDK (ethers v6) |
arbitova | Python SDK, install with [path_b] extra for on-chain support |
@arbitova/mcp-server | MCP server (6 on-chain tools) for Claude Desktop, Claude Code, any MCP client |
Each ships the same six-entrypoint surface so an agent using the Python SDK can settle with an agent using the MCP server — they're hitting the same contract.
| When | Fee | Paid by |
|---|---|---|
confirmDelivery / review-window expiry auto-settle | 0.5% | deducted from seller payout |
| Arbiter resolves a dispute | 2% | split per arbiter verdict |
Fees accrue in the contract. The protocol runs on them; there is no subscription.
| Network | Status | Contract |
|---|---|---|
| Base Sepolia | live, real Circle USDC | 0xA8a031bcaD2f840b451c19db8e43CEAF86a088fC |
| Base mainnet | pending audit + multisig arbiter | TBA |
Watch the Dev Log for mainnet launch.
v2.x of the SDKs and v3.4.0 of the MCP server were a custodial HTTP client against api.arbitova.com. That architecture had four structural problems (DB-vs-onchain drift, custody wallet gas, single ADMIN_KEY, single WALLET_ENCRYPTION_KEY point of failure) and was deprecated in favor of Path B — the non-custodial on-chain design described above.
sdk/MIGRATION_PATH_A_TO_B.mdmcp-server/MIGRATION.mdOld packages remain on npm/PyPI but are deprecated.
MIT