Blueprints decide what an agent may do in a store. Card networks decide how it may pay. Treeship is the record of what happened: every tool call, every refusal, every human approval, the cart that went to checkout, and the hand-off between agents, signed by your own key and checkable on any machine without asking anyone.
For Anthropic's commerce-agents. Other stacks use the CLI, the MCP bridge, or the A2A bridge. Install.
Payment networks sign the moment of payment and keep the proof on their rails. Everything before and around it, and everything on the merchant's side of the counter, is what Treeship signs. Each card says what shipped and in which release.
Signed before and after every call. A refusal is a signed receipt naming the gate, not a missing log line.
One operator, one action, one change, one use. The journal refuses a second spend before anything is signed.
At hand-off, the cart is signed as a digest with its count and total. The order chains onto it. Payment stays with the host.
Who handed what to whom, and whether the receiver verified the sender live, recorded as signed custody.
A closed session is one package: receipts, Merkle proofs, spent approvals, and its own page that verifies in the browser.
The CLI, the browser, and any Ed25519 library recompute it on your machine against your own trust roots. Nothing phones home.
A payment step bound to the approval that authorized it. On Verifiable Intent, that same chain is the agent attestation inside the Layer 3 credential the network and the merchant check.
Arguments, result text, session id, payment URL, order reference, cart lines. Digests only. A receipt never proves the price was right.
A designed interface is never evidence that a capability shipped. Every row below says which is which.
| Integration | What Treeship gives it | Status |
|---|---|---|
| Claude Commerce Agents anthropics/commerce-agents |
Receipts for every tool call on the Messages API, the Agent SDK and Managed Agents; single-use merchant approvals; the checkout hand-off and the host's order; a Claude Code plugin that wires it (/add-treeship-receipts). |
shipped0.30 |
| @treeship/mcp any MCP tool server |
A drop-in MCP client: every tool call receipted with intent and result, approval-gated calls bound to their grant. Covers storefront and merchant MCP servers on any agent platform. | stable |
| @treeship/a2a Agent2Agent servers and clients |
Task intents and results attested, foreign work refused until the sender proves live key control, custody recorded on the hand-off. | beta0.27 |
| Mastercard Verifiable Intent agent attestation scheme |
treeship vi follows the published draft at verifiableintent.dev: eight constraint types, versioned mandate VCTs, the agent key at cnf.jwk. It signs the Layer 3 pair for the network and the merchant. The spec's agent_attestation claim carries the receipt chain, which is the behavioral record the spec says v0.1 does not provide on its own. One mandate pair. Cumulative budget stays with the network. Independent implementation, tested both ways against the reference SDK. The draft's landscape maps this credential onto AP2, UCP, and ACP; Treeship signs the credential. |
shipped0.31.14 · draft v0.1 |
| Zerker Reason authorization certificates |
A Reason action-authorization certificate signed and chained as a Treeship receipt under a registered predicate, so the policy decision behind a purchase or a price change verifies independently. | beta |
| Robinhood Agentic Trading trading MCP |
Local receipts, approval binding for order placement, and audit trails for agents on Robinhood's trading MCP; a receipt template ships. Robinhood's own rollout is gradual and theirs. | template |
| Lobster Cash agent payments |
Attestation for every Lobster Cash payment through treeship wrap and a published skill. |
skill |
| Visa Trusted Agent Protocol · UCP · ACP checkout transports beside the credential |
Verifiable Intent's own landscape, bounded to AP2 as of 16 September 2025, UCP as of 23 January 2026, and ACP as of 30 January 2026, presents the VI credential as one format for AP2's open verifiable-digital-credential slot, and says it can ride in UCP's AP2 mandate extension and ACP's extension. Treeship signs that credential. It does not implement those transports, or Visa's Trusted Agent Protocol. A deployment can carry both. | adjacent |
Full list, including coding agents and memory providers: docs.treeship.dev/integrations. Statuses are the ones in the feature inventory the docs are generated from.
A real run of Anthropic's retail mock under a Verifiable Intent mandate, sealed 2026-10-13 as ssn_7c891c5a4a091c2e. The wallet allowed the ACME Basecamp 2-Person Backpacking Tent, AR-1201, up to two, ceiling $298. The agent bought one at $149.00. It also tried to add a product the session had never seen. That add is a signed refusal on the chain, and it is not in either credential. The issuer key and the srcDigitalCard token are the reference SDK's demo values. No card was charged. treeship vi verify --local passed.
Same transaction id on L3a and L3b. Run it: python -m treeship_commerce.demo_vi. The command is in the repository on main. The PyPI package picks it up at the next release.
A real run of python -m treeship_commerce.demo_402 on treeship 0.31.14, session ssn_6b8d199eb7fd5741, signed 2026-10-20T19:28:49Z. The agent was given a task and $5.00. A seller on localhost answered HTTP 402. Three amounts fit, and each voucher is a receipt the seller checked with treeship verify. The fourth would have taken the spend to $5.50, so no voucher was signed. The scheme is local.402.v1. Validation, redemption, escrow, and payout were not performed.
Run it: python -m treeship_commerce.demo_402. Each run is a new ship, so the ids change. The command is on main. The PyPI package picks it up at the next release. This process does not call Mastercard Agent Pay for Machines.
Treeship does not gate. Your rules, the blueprint's gates, the network's authorization keep deciding what runs. Treeship signs what they decided, at the moment they decided it, and chains each receipt to the one before.
The one method every tool call passes through, the click that sets an approval, the moment the cart meets checkout. A receipt before, a receipt after, digests only.
Every receipt names its parent. Closing the session folds them into a signed Merkle root and a portable package with its own verification page.
treeship verify on any machine, the browser verifier on the receipt page, or your own code against the reference verifier. No account, no network, no trust in us.
One minute, ten receipts: an order placed, a poisoned listing the gate refused, an operator's yes spent once, a cart digest carried into the checkout hand-off, and a sealed package verifying anywhere. Sound on.
ssn_fe3138b5…, twelve artifacts. Shopping and merchant demos run on Anthropic's mock backends, no model, no API key: python -m treeship_commerce.demo, then treeship package verify. The refusal, the approval and the verdict are inside signed receipts, not log lines.Every receipt is a DSSE envelope signed with Ed25519, content-addressed, chained to its parent, and folded into a signed Merkle checkpoint when the session seals. treeship verify walks the chain offline against your own pinned roots. A published session renders at a permanent receipt URL with the same verifier running in the browser. The hub stores bytes and serves proofs; it never issues a verdict.
What a receipt proves: this key signed, at that time, that this tool was about to run with arguments of that digest, and then what the gate decided. What it does not prove: that the answer was correct. A wrong answer with a perfect receipt is still wrong. Treeship authenticates statements; it does not adjudicate commerce.
The trust boundaryOn Anthropic's reference, pass the receipted executor_class and nothing else changes. On anything else, the CLI, the MCP bridge or the A2A bridge sign the same seams.