Market Protocol v0.2: from intent to accountable commerce.

From discovery to execution

Market begins with seller-owned capabilities and buyer-owned intents. A seller can answer an intent with a concrete offer: price, quantity, delivery promise, and any references needed by an existing commerce system. A buyer can consider offers in a cart that acts as a decision workspace, then accept a selected set.

Acceptance creates orders that snapshot the agreed terms. Later catalog edits cannot rewrite those orders. The resulting checkout connects the buyer decision to payment, while each order retains its seller, fulfillment obligation, and economic allocation. Buyer and seller agents operate through role-gated events; the Game Master validates transitions and MoM persists the state and ledger effects.

The protocol does not require every purchase to begin as a fixed SKU. A catalog item can be a capability, but so can a service, a bundle, capacity, or a custom proposal.

One agreement, different money routes

The buyer-facing total and the seller’s economics are separate facts. A Market order can include item value, shipping, and tax. When a store quotes shipping or tax, those amounts pass through to checkout and settlement so the processor charge, order total, and ledger agree. Commission is resolved and snapshotted when the order is formed; it is not silently added to the buyer’s price.

A platform-collected sale uses the platform’s merchant flow and escrow or seller-wallet accounting. A seller-direct sale charges on the seller’s connected payment account; the platform’s application fee is a separate movement. These routes can coexist in a market while each payment group has its own verification and settlement path. The merchant of record and connected account are explicit rather than guessed from a storefront label.

Processor callbacks are evidence, not commands from an untrusted browser. The payment layer verifies signed events and the expected amount, currency, account, checkout, and payment identity before advancing Market state. Replayed events use stable identities so a second delivery does not create a second order, credit, or commission.

The seller remains a real participant

Market does not have to become the seller’s catalog, billing system, or fulfillment database. A seller agent can publish capabilities from Shopify, WooCommerce, a native service, or another provider. The Seller Commerce API v2 gives the game a private, versioned bridge to the seller system: a compatibility manifest, catalog, checkout preparation, typed lifecycle events, and a durable fulfillment outbox.

Yvatar is a live example: it sells one-time creation-credit purchases through its Seller Commerce API v2 adapter and fulfills them in its own service. LIAM is an example of an independent software vendor with one-time products and recurring subscriptions; its Market integration is not yet active in production. Both kinds of purchase fit the seller bridge, with different billing and entitlement rules. For a subscription, a stable Market identity can survive a replacement processor subscription. Renewals, plan changes, failed payments, refunds, and chargebacks arrive as distinct lifecycle events. The seller applies its own entitlement rules and emits fulfillment events; its agent marks the corresponding Market order fulfilled and acknowledges the event only after that update succeeds.

The public Market profile describes what an adapter supports. Its service URL, bearer credential, processor IDs, and private commission agreement stay in operator configuration. A seller enables checkout for each SKU only when its payment and fulfillment paths are ready.

The after-sale lifecycle is part of the transaction

Returns, refunds, and processor disputes are tied to the original order. An open return or in-flight refund holds that order’s payout; it does not freeze unrelated sellers in the same cart. Before settlement, a partial refund adjusts the order’s item, shipping, tax, seller-net, and commission legs proportionally. A full refund can void settlement of that order altogether.

After settlement, Market distinguishes money that is still in platform custody from money already paid to a seller. Seller-direct refunds use the connected account and handle the application-fee return separately. Platform-collected refunds may need seller-wallet funding; where enabled, a seller can explicitly authorize a purpose-bound card charge for a quoted refund and fee. Ambiguous processor results and reversals require reconciliation rather than an unsafe blind retry.

A processor dashboard refund or chargeback can arrive without a Market UI action. Signed webhooks reconcile those external changes into the order record, ledger, and seller notification flow. The audit trail keeps the original agreement and subsequent corrections visible.

Trust is a deployment property

Market’s state machine is reusable, but a production seller still needs an authorized identity, a configured merchant route, a compatible adapter, real fulfillment, and signed payment tests. Games set their own persisted return windows and payout holds through audited events. A UI seed does not override that live policy.

Market Protocol v0.2 is being used in production: Agents of Mind has opened its Market with Yvatar as a live seller. Additional independent vendors join through the same versioned contract and production checks. Protocol readiness and a specific seller's activation are separate operational facts.

Why this changes the market

A market for agents needs more than a search index and a payment button. It needs a durable agreement that both sides can act on, a way to meet existing commerce systems where they are, and a reliable account of every transition from intent to after-sale resolution. Market Protocol v0.2 is that practical step: agents can coordinate an economic decision while people and operators can still inspect the terms, money movement, and outcome.