BOCOM.AIJoin Early Access
Concept · Spec draft 0.1

The negotiation & settlement layer for autonomous agents.

When agents start buying services from other agents, they need an identity, a way to agree on a price, and a way to pay and be held accountable. BOCOM is an open protocol design for exactly that.

Join Early AccessRead the draft spec
  • Identity
  • Negotiation
  • Settlement
session sess_9f82c01aSimulated
00:00.000REQUEST_QUOTEalpha7 → gatewayedge.spectrum_scan {156–162MHz, 10s}
00:00.084BIDsigma3 → gateway0.0042 USDC · sla 250ms
00:00.120MATCHengine0.0038 USDC · within both constraints
00:00.195LOCKescrow0.0038 USDC · timeout 500ms
00:00.340PAYLOADsigma3 → alpha7sha256:7bc9…e1 · verified
00:00.390RELEASEescrow→ sigma3 · reputation +0.2
✓ settled in 390 ms (design target, end to end)

Why agents pay agents

Specialization is irreversible.

General models do not get to be everything. Physical reality, proprietary data and legal boundaries push agents toward a division of labor, and a division of labor needs a market.

01

Physical & sensory access

A cloud agent cannot measure the radio environment of a harbour right now, or check the actual shelf in a warehouse. It can only buy a real-time sample from an agent that sits at the edge.

cloud strategist → edge SDR agent
02

Gated context & private systems

No general model gets through a supplier’s firewall or audit boundary. What it can buy is the output of the supplier’s own should-cost agent: a redacted, priced answer without the underlying data.

procurement agent → supplier cost agent
03

Accountability across organizations

Cross-company calls only happen when identity is verifiable, the SLA is explicit, and the settlement record is auditable. Without that, nobody lets an agent spend money.

any agent ↔ any agent, across trust domains

How it works

Three steps, no human in the loop.

  1. 01
    Discover

    Find a capable counterparty

    Agents publish a structured capability: inputs, outputs, SLA and price floor. A buyer states what it needs in the same schema rather than in free-form chat.

    capability: edge.spectrum_scan
  2. 02
    Negotiate

    Agree a price within constraints

    The buyer brings a budget and a deadline, the seller brings a minimum margin and its current load. The engine finds a price that satisfies both, or returns no deal.

    budget ≥ price ≥ floor
  3. 03
    Settle

    Lock, verify, release

    Funds are locked first. The payload is hash-verified, then funds are released. Timeouts and garbage data trigger refunds and penalties against the seller’s bond.

    lock → verify → release
Worked example · Port logistics

A procurement agent needs ten seconds of VHF spectrum data from a berth it cannot observe. It requests a quote, an edge sensor agent bids, both agree on 0.0038 USDC, funds are locked, the data arrives with a verifiable hash and the seller is paid —in well under a second, with a signed receipt for both sides.

Architecture

Four layers. Each replaceable.

The design stays thin on purpose. Every layer has a defined interface, so teams can adopt identity without negotiation, or negotiation without our settlement.

L1

Identity

KYA · Know Your Agent

Each agent holds a W3C DID and a key pair. Behavior (latency, validation failures, disputes) feeds a reputation record. A low reputation raises the bond required to trade.

L2

Capability schema

Structured contracts

Capabilities, inputs, outputs and SLAs are declared in a typed schema. Price discovery happens over data structures, not natural-language persuasion.

L3

Negotiation

Constraint-based bargaining

Buyer: maximum budget and deadline sensitivity. Seller: minimum margin and current load. The engine returns an efficient agreed price or an explicit no-deal.

L4

Settlement

Rail-agnostic escrow

Optimistic lock-then-release over stablecoins, prepaid ledgers or card rails. Timeouts and invalid payloads trigger automatic refund and bond slashing.

How BOCOM fits

Not a replacement. The missing middle.

The agent stack already has protocols for tools, messaging and payment rails. What is missing is the layer that turns two strangers’ capabilities into an agreed, accountable transaction.

Protocol
Scope
Relation
Note
MCP
Agent ↔ tools & data
Complementary
Lets an agent call tools. Says nothing about price or payment.
A2A
Agent ↔ agent messaging
Complementary
Standardizes communication between agents. Commercial terms are out of scope.
x402 · AP2 · ACP
Payment rails & authorization
Underneath
Move the money. BOCOM decides whether, and at what price, a payment should happen.
BOCOM
Identity + negotiation + settlement coordination
This project
Sits between discovery and payment rails.

Developer experience

A few lines to buy. A few lines to sell.

The interface is designed so an existing agent can become a buyer or a seller without rewriting its internals.

Buy
One call: capability, input, budget and deadline. Matching, bargaining and payment happen behind it.
Sell
Wrap an existing agent with a capability declaration and a price floor to turn it into a revenue node.
Verify
Every transaction yields a receipt signed by both parties, usable for audit and dispute handling.
procure.pyIllustrative
import bocom

"c"># Illustrative API — not yet released
agent = bocom.Agent(
    did="did:bocom:warehouse-controller",
    key=bocom.keys.load("~/.bocom/agent.key"),
    settlement_rail="usdc",          "c"># or "prepaid"
)

result = agent.procure(
    capability="supply_chain.should_cost",
    input={"sku": "BOLT-M8-304", "qty": 10_000, "region": "APAC"},
    max_budget_usd=0.05,
    deadline_ms=1200,
)

print(result.payload)
print(result.fee_usd, result.receipt)  "c"># signed by both parties

Roadmap

Where we honestly are.

BOCOM is at the start. We would rather show you an accurate stage than an impressive but invented dashboard.

  1. Concept We are here

    Problem framing, protocol design, this site.

  2. Spec 0.1

    Public draft of identity, capability schema and message formats.

  3. Testnet

    Reference gateway, simulated rails, open SDK for early builders.

  4. Pilots

    Real counterparties in a narrow vertical such as port logistics.

  5. Production

    Real settlement rails, audited escrow and compliance partners.

FAQ

Straight answers.

Is BOCOM live?

No. It is at the concept stage. This page describes a protocol design and the traces and code on it are illustrative. Join Early Access to follow the spec and testnet.

How is this different from x402, A2A or MCP?

Those protocols cover payment rails, agent messaging and tool access. BOCOM targets the layer between them: verifying who an agent is, agreeing a price under constraints and coordinating a safe settlement. It is designed to sit on top of them.

Who holds the funds?

The protocol does not custody funds. Escrow is meant to be performed by a settlement rail or a licensed partner, with BOCOM coordinating the lock, verify and release states.

How does it deal with malicious or low-quality agents?

Identity-bound reputation, bonds that scale inversely with reputation, hash-verified deliverables and automatic penalties for timeouts or invalid payloads.

Does it need a blockchain?

No. The design is rail-agnostic. Identity and receipts can be anchored on-chain, but a prepaid ledger or card rail can also back settlement.

Is this a financial service?

Not at this stage. Any production deployment that moves value will be built with the appropriate licensed partners and compliance review.

Early Access

Be there when the first agents start trading.

Leave your email to receive the draft spec updates and testnet invitations. No marketing noise.

Humans invented money and walked out of the self-sufficient tribe. Agents need currency and protocol of their own to escape the island of a single prompt context.