Whitepaper, Boson escrow for agentic commerce

An Autonomous Agent Walked the Facet Terminal and Purchased Flowers with Secured Payment Through Boson Escrow

Facet's Terminal already lets an agent pay with a card or with USDC directly. Both settle in one shot: once the charge clears, the money is with the merchant, and getting it back if something goes wrong is a matter of the merchant's or processor's policy, not a property of the payment itself. This paper documents a third option: a payment that is provably held, not just paid, until the order is actually fulfilled, and proves it end to end against a real merchant, with real USDC, on Base mainnet.

Proven on Base mainnet Non-custodial Identity-gated Multi-item cart, landed pricing Composes with Boson Protocol

Jump to the validation report ↓ Download PDF

Abstract

Facet's Terminal identifies an autonomous agent before it can read a merchant's catalog, let alone buy anything from it. For purchases settled through Boson Protocol's on-chain escrow, that identity check is only the first guarantee. The second is that the purchase itself is secured: the buyer's funds move into an escrow contract neither Facet nor the merchant controls, release to the merchant only once the order is fulfilled, and return to the buyer on-chain, by the buyer's own signature alone, if the purchase is cancelled first. This paper describes why that guarantee matters for an unsupervised buyer, what Boson Protocol's escrow contributes to it, and what Facet built on top. The appended validation report proves the full loop end to end: a real multi-item cart, priced with live shipping and tax, a real merchant, a purchase that settles to completion, and a cancellation recovered entirely on-chain.

“An agent that spends its own money needs to be able to get it back on its own, provably, not by asking nicely. That’s what drew us to Boson’s escrow: a contract that holds the funds until the order is fulfilled, and hands them straight back to the buyer if it isn’t. We didn’t rebuild that guarantee. We integrated it, wired it to a real merchant’s real checkout, and proved the whole loop on mainnet before writing this paper.”

Weston · Founder & CEO, Facet

The problem: a one-shot settlement has no provable way back

Facet's Terminal already settles purchases by card, through Stripe, Visa, and Mastercard, and by direct USDC transfer. Both are one-shot: the charge clears, the money is with the merchant, and whatever happens next, a refund, a cancellation, a dispute, is a matter of the merchant's or processor's policy, not a property of the payment itself. That policy layer normally has a human behind it: a cardholder who can call their bank, a shopper who can open a support ticket. An agent transacting fully on its own has none of that built in.

That gap does not matter for a $3 API call, settled and consumed in the same request. It matters for a purchase where fulfillment happens after the money moves, a physical order that can be cancelled, delayed, or never shipped. For that case, an unsupervised buyer needs a payment primitive where the funds are held against an outcome, provably, on-chain, not simply transferred on a promise and hoping the policy holds.

What Boson Protocol's escrow provides

Boson Protocol's x402B escrow rail gives a buyer's commitment a real, on-chain state machine instead of a single irreversible transfer. A buyer commits funds into an escrow contract against a seller-signed offer; the exchange is Committed from that point on. Fulfillment triggers a redemption, moving the exchange to Redeemed, and completion credits the amount, net of the protocol fee, to the seller's own balance. Before redemption, the buyer alone can cancel the commitment and recover its funds, less any buyer cancellation penalty the seller has set on the offer (zero on Facet's WooCommerce offers), directly from the contract, a transaction only the buyer's own key can sign. No party, Facet included, holds a key that can move the escrowed funds anywhere the contract's own state machine does not already allow.

What Facet adds on top

Boson Protocol's escrow secures the money. It has no opinion on who is allowed to spend it, what is actually in the cart, or how a real merchant's fulfillment process is supposed to trigger the on-chain redemption. Facet adds three things in front of and around that escrow: an identity gate, so no catalog and no checkout is reachable without a verified Facet KYA, before a single dollar is ever at stake; a checkout session that binds a real, multi-item cart, priced with live shipping and tax, to the seller's Boson offer, rather than a single bare commit; and a fulfillment binding, so a real merchant's own order-management action, marking an order fulfilled in the store they already use, is what triggers the redemption on-chain, with no blockchain tooling required on the merchant's side.

Composability: Facet integrates the rail, it does not reimplement it

Facet does not fork or reimplement Boson Protocol's escrow contracts. The custody guarantee in this paper, that funds are held by a contract no single party controls, is Boson Protocol's. What Facet contributes sits above it: identity, checkout, and the binding to a real merchant's fulfillment process. When Boson Protocol's own contracts evolve, Facet's integration adapts; the escrow guarantee itself is not something Facet's code needs to reprove.

References

Boson Protocol. Protocol documentation and smart contracts. github.com/bosonprotocol.
Base. Network documentation, chain 8453. base.org.
Circle. USDC EIP-3009 transferWithAuthorization / receiveWithAuthorization, the signed authorization primitive underlying a Boson commit.
IETF. RFC 9421, HTTP Message Signatures.
Facet, LLC. Boson escrow mainnet validation: a purchase settled, and a cancellation recovered, non-custodially. Appended after this paper.

Validation report, Boson escrow on Base mainnet

Facet Boson escrow: a mainnet purchase settled, and a cancellation recovered, non-custodially

An unidentified automated client cannot reach a merchant's catalog on the Facet Terminal; a Facet KYA opens it, and the Terminal verifies that credential rather than merely checking it is present. Two independent, real transactions on Base mainnet, against a live WooCommerce merchant, show what happens next: a cancelled purchase recovered entirely on-chain, at the buyer's own initiative, with no permission needed from the merchant or from Facet, and a full purchase settling through Boson Protocol's on-chain escrow from commit to completion. Every claim below resolves to a live HTTP response, a signature that recovers to the buyer's own address, or a state you can read directly off the deployed contract.

Mainnet cancellation, recovered on-chain Mainnet purchase, commit to completion KYA verified, not just checked Multi-item cart, landed pricing Base mainnet, chain 8453 Non-custodial

00Setup: all public, all on-chain

Merchant: Pecan and Petal, a live WooCommerce store on the Facet Terminal at pecanandpetal.facet.llc. Rail: coin/boson-escrow (Boson Protocol's x402B escrow). Network: Base mainnet, chain 8453, real USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. Escrow contract (the Diamond): 0x59A4C19b55193D5a2EAD0065c54af4d516E18Cb5. Buyer wallet: 0xC0D344C8D10F5f9C64Cb96148FcF176BA170D21E.

Non-custodial by construction. Funds move buyer to escrow to merchant on a completed purchase, or buyer to escrow back to buyer on a cancellation. A Facet-controlled wallet is never in that path; Facet verifies identity and orchestrates the checkout, and never holds the money.

01Discovery: detected and blocked without identity, opened with a KYA

An agent that has never interacted with Facet arrives at the merchant's Terminal cold, with no credential. The edge classifies it as an unidentified automated client and blocks it before it ever sees a product. The agent self-issues a Facet KYA at the trusted issuer and presents it; the identical route now opens.

Cold, no authGET /v1/catalog, no Authorization header → HTTP 402 PAYMENT_REQUIRED: "Facet classified this request as an unidentified automated client and blocked it at the edge. Present a Facet KYA (an ES256 JWT) as Authorization: Bearer <token> to reach the catalog."
Self-issued identitythe agent mints a single-use Facet KYA (ES256 JWT) at issuer.facet.llc, the issuer this merchant's own agents.txt advertises.
Same route, with the KYAGET /v1/catalog, Authorization: Bearer <kya> → HTTP 200. The full merchant catalog is now readable: eleven products, including a $3.00 card and a $15.00 flower arrangement, plus the tools the agent uses to price and buy them.

02The KYA is verified, not merely checked for presence

A checkout session bound to a Facet KYA is created only once the Terminal has verified the credential's signature against the issuer's published key. Presenting a real KYA, a malformed one, and no credential at all each produce a distinct, correct outcome, not a single pass-through gate.

Valid KYAPOST /ucp/v1/checkout-sessions, a real, freshly minted KYA → HTTP 201, a checkout session bound to a live, seller-signed Boson offer.
Invalid KYAidentical request, a malformed bearer token → HTTP 401 UNAUTHORIZED: "Invalid or expired KYA token."
No credentialidentical request, no Authorization header → HTTP 401 UNAUTHORIZED: "signature_missing."

03A cancelled purchase, recovered entirely on-chain

A mainnet exchange against a two-item cart is cancelled before fulfillment. The buyer recovers its own escrowed funds with a single on-chain call, needing no action, approval, or key from the merchant or from Facet.

Committed, then cancelledthe $28.49 cart commits into escrow, then is cancelled before the merchant fulfills it.
Self-recovery, on-chainthe buyer's own wallet calls the escrow contract's withdraw function against its own released balance, a transaction only the buyer can sign; no Facet or merchant key is involved. The buyer's on-chain USDC balance rises by the full $28.49, the exact amount committed. The buyer cancellation penalty is a per-offer parameter, set to zero on Facet's WooCommerce offers, so nothing is withheld here; a merchant that sets a non-zero penalty would see the buyer recover the commitment less that amount.
Facet's own ledger agreesthe order behind this exchange is recorded in Facet's ledger at $28.49, matching the on-chain committed and recovered amount exactly.

WooCommerce order 153, Refunded, reflecting the on-chain recovery

The merchant's own order record, marked Refunded to match

What this proves. A cancelled commit is not a support ticket. It is the buyer's own funds, recoverable by the buyer's own signature, on a public contract Facet does not control.

04A mainnet purchase, commit to completion

A real two-item cart, a birthday card and a flower arrangement, commits real USDC into the merchant's Boson escrow through Facet's signed checkout protocol. The merchant fulfills the order in WooCommerce, the held voucher redeems, the exchange completes on-chain, and the merchant's own signing authority withdraws the released balance to its own treasury, the full lifecycle from commit to a spendable merchant balance.

CartHCF-CARD × 1 ($3.00) + HCF-BDAY × 1 ($15.00) = $18.00 goods + $10.49 delivery and tax = $28.49 landed, committed into escrow.
FulfillmentWooCommerce order 154, the identical cart and total, is marked Completed by the merchant, firing the redeem.
On-chain lifecycle, verified by direct contract readCommitted → Redeemed → Completed. On completion, $28.34755 USDC is credited to the merchant's available Boson-protocol balance; the difference from the $28.49 committed is the Boson protocol's own settlement fee, retained on-chain at completion.
Withdrawn to the merchant's own treasurythe merchant's registered signing authority calls withdrawFunds, moving the full 28.34755 USDC out of escrow to 0xE01233Ec7ebe278f30a263bbddbE62a1b3b2d11f, the merchant's own treasury contract, on transaction 0x4324a0b42c5c010fecf74b6218178af91c12f454080636f4b08a30fcf3ac3c78. Confirmed both sides, directly from the chain: the merchant's available Boson-protocol balance reads exactly 0 afterward, and the treasury's own USDC balance reads exactly 28.34755.
Facet's own ledger agreesthe order behind this exchange is recorded in Facet's ledger at the full $28.49 committed, matching the on-chain committed amount exactly.

WooCommerce order 154, On hold, the cart and Boson escrow note for this exchange

The merchant's own order, On hold, awaiting fulfillment

WooCommerce order 154, status changed to Completed

The merchant marks it Completed, firing the redeem

Fully settled: committed, completed, and withdrawn to the merchant's own treasury. Every step of this exchange is a real, independently-verifiable on-chain state: escrow held the full commit, completion released it net of protocol fee, and withdrawal moved the released balance to the merchant's own registered wallet. At no point did a Facet-controlled address hold, route, or approve the movement of these funds.

05The signature inventory: nothing here is unsigned

Every order in this report carries a real entry in Facet's own append-only signed ledger, quoted verbatim below. Each entry hashes the request and the response, chains to the entry before it, and is signed by this merchant's own Ed25519 key, not a shared platform key. The public key verifies against a JWKS this merchant's own Terminal publishes, reproduced at the end of this section.

Leg	Order	Facet-signed ledger envelope, Ed25519 (EdDSA)
Cancellation, recovered on-chain	153	request_hash `0x4932347158a44970adbaaa75517958da64df88ffca78ed4385cdc07eb5ba6832` response_hash `0xb171f54048e163900db85cb0353ca65b275aa954f5696528c6a684029b78dee6` this_hash `0x9aef1cc160413d25624e266ab11ebae64f07bb0b496aa3110d124014f582c6d2`, chain start for this merchant signature `0xdc3d1cdb0c580f6ced5c0af8716567060deb907bbc43bad3b9c78dc24951ffdcfbee5fd81a68d1d4fd00ddb69500855a6735ded1e688d082aface1adac587e0f` signed 2026-08-08T00:57:46Z, key `kid 85bd0430-34b8-47f3-bf54-e85988a54e04`
Purchase, commit to completion	154	request_hash `0x0446df9ba5f1e94221b394dd1e9b7a5dc8505a29e569ea81d24d8d6dbfe90024` response_hash `0xfeafa3fb9a11527ffd0307cb70a8734dd78dd033c6237c0fc7d1b7828e322d05` prev_hash `0x9aef1cc160413d25624e266ab11ebae64f07bb0b496aa3110d124014f582c6d2`, exactly order 153's this_hash above this_hash `0x3f696cbd03c429018785e5ccf60106224dfef6caeb71ee14954beda06d3f505f` signature `0x4835933e19e2113d270d0a7b1dca1f2c808859dcee27317968a09b3c80584677f7c29ca0f3b78065e7c7651c1121ad7c84c21500a4fbc393b90068e815a4420b` signed 2026-08-09T02:39:17Z, key `kid 85bd0430-34b8-47f3-bf54-e85988a54e04`, same key as above

Independently verifiable. This merchant's Ed25519 public key is published live at pecanandpetal.facet.llc/.well-known/jwks.json, keyed by the exact kid in both rows above; recompute either signature against it under standard EdDSA verification. Order 154's prev_hash equals order 153's this_hash exactly, chaining the two entries directly to each other in Facet's own append-only log, proof neither was inserted or reordered after the fact.

A UCP checkout is two signed legs, not one: CREATE opens the session, COMPLETE carries the buyer's funding authorization and is what the Terminal actually verifies before it will move money. Both are the same RFC 9421 request-signature mechanism, checked before any business logic runs. The literal bytes from the two historical checkouts above were not retained, so both rows below are a live, zero-spend reproduction, run against the same live Terminal, the same merchant, and the same $28.49 cart, moments before this report was generated, using the same platform key already published for Facet's x402-direct validation.

Leg	Cart	Platform signature, RFC 9421, ES256
Checkout CREATE, live, sent	$28.49	`created=1786294614; keyid="facet-ucp-platform-validation-2026"` `sig1=:dOTOnpkxbwESjvGontExzIgDv4UMYKeaMiE6Wzmewq2MryFI4SoOuJfX8KHK/UC+XZt6oLs8Flwf/6a1Qy94uQ==:` content-digest `sha-256=:agNmGaZbk8rjX8kVaVf2Jh8btFKyVyMRRA/ACsGh8w4=:` response `HTTP 201`, checkout `49a8efb3-a8cd-4c92-94a0-d4d23e79a2e6`, totals matched $28.49 exactly
Checkout COMPLETE, signed, not sent	$28.49	`created=1786294619; keyid="facet-ucp-platform-validation-2026"` `sig1=:Ns7FtDr6TCcl5mIFR2IZmtocXys9cBMxOgkPnEQ1Z8v+m5FsT6U58wwM5EPgBC8fWFe3TkXkzb56QqF9/UdSgg==:` content-digest `sha-256=:YhIuLkPqBYN83e83hKChwAxGMuJrUAT1TTTDgx0+5H0=:` carries the buyer's own ERC-3009 commit authorization against the CREATE checkout above; withheld from the network because this reproduction's buyer wallet does not hold the full $28.49, the same funding guardrail Facet's own operator tooling enforces before ever posting a COMPLETE call

Independently verifiable. Platform public key, EC P-256, the same key already published for Facet's x402-direct validation:

kid facet-ucp-platform-validation-2026, x=iiNBe3_n_wSECRyxyawkmO4ufk9Oscc58Ka4cK3vlLM, y=i68drm5xsC21PZ7_7zplfJKRPta6OsBGw8lu_XHbDKU

. Recompute either signature above against it under standard ES256 verification; the Terminal did exactly that for CREATE, live, before returning 201. COMPLETE's signature is the same deterministic computation over real bytes and verifies identically, whether or not the request was ever sent.

06Guarantees

The payout target is always the merchant's own configured account. Never a field an agent's request can set.
The buyer's own on-chain authorization is the only thing that can move the buyer's funds. For the exact amount and offer it was signed against, and nothing else.
A cancelled exchange's escrow balance is withdrawable by the buyer alone. No merchant approval, no Facet key, no support process.
Non-custodial throughout. At no point does a Facet-operated wallet hold buyer or merchant funds.
An unidentified automated client cannot reach the catalog at all. Identity is checked before a single product is visible.

07Summary and how to verify

Two independent mainnet exchanges, the same cart, two different outcomes: a cancellation that recovers on-chain without any party's permission but the buyer's own, and a purchase that settles all the way to a withdrawn merchant balance. Both ran against a live merchant, with real USDC, on Base mainnet, and both are recorded consistently in Facet's own signed ledger and on-chain. To verify independently: confirm 0x59A4C19b55193D5a2EAD0065c54af4d516E18Cb5 is the deployed Boson escrow Diamond on Base; read the exchange and balance state directly from the contract; look up the withdrawal transaction 0x4324a0b42c5c010fecf74b6218178af91c12f454080636f4b08a30fcf3ac3c78 on basescan.org and confirm it moved 28.34755 USDC to 0xE01233Ec7ebe278f30a263bbddbE62a1b3b2d11f; verify both signed ledger envelopes in section 05 against this merchant's own published JWKS; reproduce section 01 and 02 by calling pecanandpetal.facet.llc with and without a Facet KYA.

What this proves

Identity-gated by construction. No catalog, no checkout, and no purchase without a verified Facet KYA. Non-custodial, both directions. A completed purchase pays the merchant; a cancelled one returns the buyer's own funds to the buyer, by the buyer's own signature, on a contract neither Facet nor the merchant controls.