Fulfillment channels

Boson is a commitment / escrow protocol — it doesn't deliver the goods for you. What it does provide is a state machine that says when delivery is owed (after REDEEMED) and an opinionated set of channels for how to deliver, especially for digital and agent-to-agent commerce.

The five built-in channels

Channel	Use	Delivery mechanism
Inline	Direct HTTP response	The seller's server returns the asset in the same response that confirms commit (atomic)
Email	Digital codes, links, instructions	Server sends an email containing the asset or a one-time link
XMTP	Agent-to-agent, on-chain identity	Server posts to the buyer's XMTP address
Webhook	Server-to-server	Server POSTs to a URL the buyer provided at commit time
IPFS pointer	Large files	Server returns an IPFS CID; buyer fetches separately

The channels are implemented in @bosonprotocol/x402-fulfillment, but the concept applies to any seller — even an SDK-based marketplace.

Picking a channel

Scenario	Channel
Selling an API call response	Inline
Selling a digital license / activation code	Email
Selling agent-readable JSON	XMTP or Inline
Selling a large file (model weights, dataset)	IPFS pointer
Selling a physical good with tracking	Webhook (your fulfillment system posts back)

Channel declaration (x402)

In x402, the seller's 402 Payment Required response advertises which channel(s) it supports. The client picks; the server delivers via that channel after on-chain settlement.

{
  "accepts": [{
    "scheme": "escrow",
    "fulfillment": {
      "channels": [
        { "id": "inline" },
        { "id": "email" }
      ]
    },
    "…": "…"
  }]
}

Custom channels can be registered via the FulfillmentChannel interface in x402-fulfillment.

Non-x402 delivery

If you're not using x402 — e.g. a marketplace selling physical goods — fulfillment is between your backend and your shipping system. The protocol's contract with you is "the exchange is REDEEMED; the buyer has signaled they want the goods." See Build → Sellers → Handle redemption / deliver.

Reorg / re-delivery safety

Two principles:

Tie delivery to the VoucherRedeemed event, not to a subgraph read. Subgraph lag means you might miss redemptions; the event is the source of truth.
Make delivery idempotent. Key on exchangeId. Re-firing the event (due to a reorg or replay) must not double-deliver. Persist a "delivered" flag per exchangeId.

Common footguns

Email delivery is asynchronous. A buyer who commits and immediately checks email may not see the message for 30+ seconds. Show "delivery in progress" in your UI.
Webhook handlers are public endpoints. Authenticate the request — the simplest is HMAC-sign the payload with a per-exchange secret.
XMTP requires the buyer's address to have an XMTP identity. Not every wallet has one. Have a fallback channel.