Interop — the portable credential
Status: design intent, not a shipped API. This page describes how fleet is meant to compose with the wider agent ecosystem. The bond + delegation primitives it builds on are live (see Bond verification); the credential-attachment helpers below are a roadmap item, not something you can
importtoday. Where that matters, it's called out.
The position
fleet does not compete with the rails that move money or mint agent identities. It sits above settlement and beside the IdP: the one thing those rails deliberately skip is does this agent have something to lose, and can a counterparty verify that without trusting anyone? (see the overview).
The corollary is that an OC delegation + bond should be portable — a small, offline-verifiable credential that travels inside whatever rail an agent is already using, rather than asking anyone to adopt a new one. An OC artifact is content-addressed and BIP-322-signed, so it verifies the same way no matter what carries it.
Where the credential is designed to ride
| Rail | What it does | Where OC attaches (designed) |
|---|---|---|
| x402 (Coinbase / Circle) | HTTP 402 stablecoin settlement; no reputation/bonding layer | An OC delegation+bond id as a request header field — the payer's agent presents verifiable standing alongside payment. |
| Google AP2 | Signed Mandates proving a human authorized this purchase | An OC bond reference annotating a mandate — adds standing skin-in-the-game the mandate itself does not assert. |
| A2A (agent-to-agent) | AgentCards describing an agent's capabilities | An OC delegation+bond claim in the AgentCard — a counterparty agent weighs the bond before transacting. |
| ERC-8004 (EVM, on-chain) | Identity + Reputation + Stake registries | An OC artifact as an off-chain attestation referenced from the registry — bitcoin-rooted, no-custody, no-token, alongside the on-chain record. |
In every case the carrier is opaque to the trust claim: the relying party fetches the referenced OC delegation + bond, re-derives its id, re-checks the BIP-322 signature, and re-resolves the bond against live bitcoin UTXO state — exactly as described in Bond verification. The rail moves the value or the identity; OC supplies the verifiable accountability, and it does so without OC, or the rail, being trusted.
Why "ride into" rather than "replace"
The only credible bitcoin-neutral competitor is ERC-8004 (mainnet 2026: Identity + Reputation + Stake). It is custodial (locked-token staking), has a token, and is EVM-only. fleet's primitives win where those are liabilities — no custody, no token, offline-verifiable, bitcoin-rooted — and the way to express that advantage is not to ask the ecosystem to switch rails. It is to make the OC credential cheap to attach to the rails already winning. A bond is worth more as a field in a header everyone already sends than as a standard nobody adopts.
What exists today vs. what's designed
- Live now: the delegation and bond primitives, content-addressed and
offline-verifiable;
GET /api/bondto re-resolve a bond from anywhere; the client-side verifier. - Designed (roadmap): the thin attachment helpers — encoders/decoders that pack an OC delegation+bond reference into an x402 header field, an AP2 mandate annotation, an A2A AgentCard claim, or an ERC-8004 off-chain attestation, plus the relying-party verifiers for each. These ship as a small package when the rails' formats stabilize; this page will move from "designed" to "live" then.
If you're building on one of these rails today and want the OC credential in it,
the primitive you need already exists — the bond is verifiable from any context
via /api/bond. Talk to us about the carrier format; that's the part still
settling.