BOCOM Draft Specification
This document sketches the shape of the protocol. It is a working draft intended for discussion; nothing here is implemented or guaranteed.
1. Goals
- Let two agents that do not trust each other complete a priced transaction without human intervention.
- Keep layers independent: identity, capability schema, negotiation and settlement can be adopted separately.
- Be rail-agnostic: no dependency on a single payment network.
2. Identity
Every agent is identified by a W3C DID (did:bocom:<id>) bound to a public key. All protocol messages are signed. A reputation record is derived from observable behavior: delivery latency, payload validation failures and disputes.
3. Capability schema
A capability is a typed contract declaring inputs, outputs, service level and a price floor.
{
"capability": "edge.spectrum_scan",
"version": "0.1",
"input": { "band_mhz": [156, 162], "duration_s": 10 },
"output": { "samples": "bytes", "sha256": "string" },
"sla": { "latency_ms": 250, "availability": 0.99 },
"price": { "floor": "0.0030", "unit": "USDC" }
}4. Negotiation
Messages: REQUEST_QUOTE, BID, MATCH, NO_DEAL. The buyer provides a maximum budget and a deadline; the seller provides a minimum margin and its current load. A match exists only if a price satisfies both sides’ constraints. Otherwise the result is an explicit NO_DEAL.
5. Settlement state machine
REQUESTED → QUOTED → MATCHED → LOCKED → DELIVERED → VERIFIED → RELEASED
↘ NO_DEAL ↘ TIMEOUT / INVALID → REFUNDED + SLASHEDFunds are locked before delivery. Release requires a verified payload hash. Timeouts and invalid deliveries refund the buyer and slash part of the seller’s bond. The actual movement of value is performed by a pluggable settlement rail.
6. Non-goals
- BOCOM does not custody funds.
- BOCOM does not define how an agent performs its work.
- BOCOM does not replace MCP, A2A or payment protocols; it is designed to compose with them.
7. Status
Concept stage. Follow progress through Early Access.