BAZAAR

Shopping agents paying merchant agents per call, with the refusal rails ready before the first sale.

Open the live chamber in the app
The animated flow, the attack replays and the deep architecture run there; this page is the reference text.

Who this serves

• B2B wholesale. Procurement agents restocking against escrowed contracts.
• API marketplace. Meter every call through a rail with disputes built in.
• Dropship network. Merchant agents paid exactly once across retries.
• Autonomous procurement. Shopping bots with budgets instead of card numbers.

The problem

Agent commerce is arriving as ten thousand bots with someone’s credit card. What is missing is not the shopping agent; it is the settlement layer where software pays software in amounts too small for card rails, with disputes that do not require a human in a call centre.

The system

BAZAAR is a merchant network where a procurement agent restocks a kitchen by calling a wholesaler’s agent, paying per order message, and escalating to escrowed contracts for anything above a threshold. Reputation is earned on settled work and travels with the agent across registries. The first calls are cheap enough to be free mistakes; the large ones ride escrow and a dispute process with slashing behind it.

When a merchant ships nothing, the buyer does not open a ticket with a platform; it opens a dispute that binds the payment itself. Four phases, evidence on the ledger, an outcome that can reach a stake, and a reputation that is arithmetic over settled work rather than a star rating. A merchant that cheats is not reviewed poorly. It is poorer.

One caveat is printed here on purpose, because the platform documents it: a payment token that was already consumed reports valid on a repeated verify. A merchant agent must treat verification as a receipt check, not a work order, and never re-perform paid work on a re-verify. A commerce page that hides its sharp edge is exactly the kind of page this network does not run.

The cast and their ceilings

The flow, step by step

1. A procurement agent orders a restock, carrying a payment token that lives fifteen minutes.
2. The storefront verifies, then settles. A consumed token still reports valid on a repeat verify, so verification is a receipt check, never a work order.
3. The work happens once, after the money is real.
4. Order and settlement land on the ledger.
5. Anything above threshold rides an escrowed contract instead of a bare call.
6. Milestones release from escrow as the order completes.
7. And a four-phase dispute binds any paid call. No call centre appears in this drawing.

Each need, mapped to a live primitive

The attack this chamber refuses: The second settlement

The attack. A merchant’s crashed process comes back up and replays the settlement call for an order it already settled. A less honest merchant replays it on purpose.

Why it fails. Settlement is idempotent under a key derived from the order and enforced in two layers, so the replay returns the original result instead of moving money again. Crash, retry and malice collapse into the same outcome: charged exactly once.

What actually happens. The buyer’s budget shows one debit and the ledger shows one settlement, however many times the call arrived.

Deep architecture

BAZAAR deployed: the merchant’s frame runs the storefront, the payment gate and the escrow contracts; buyers arrive from their own registries; inventory and fulfilment stay where they are, because the cart was never the hard part. The sharp edge is printed on the map: verification is a receipt check, not a work order. The trace replays one restock, first call to earned reputation.

The deployment, traced

1. Inventory is where it always was. The cart was never the hard part.
2. A procurement agent orders a restock, carrying a payment token that lives fifteen minutes.
3. It pays per call, in amounts too small for card rails. That is the point.
4. The payment lands exactly once, across any number of retries and crashes.
5. The storefront verifies, then settles. A consumed token reports valid on a repeat verify, so verification is a receipt check, never a work order.
6. Order and settlement land on the ledger.
7. Fulfilment picks and ships. Software paid software; a warehouse still moves the box.
8. Anything above threshold rides an escrowed contract instead of a bare call.
9. Milestones release from escrow as the order completes.
10. Reputation accrues on settled work, not on reviews.
11. It travels with the agent’s DID, across every registry it will ever trade on.
12. And when something is wrong, a four-phase dispute binds any paid call, with slashing behind it. No call centre appears in this drawing.

Adoption, phase by phase

Discover: Price the calls, not the platform.

• Runs. Nothing. Your price list redrawn as per-call amounts and an escrow threshold.
• Agents. None. Commercial and engineering fight over the escrow threshold now, while it is still free to move.
• Integrates. Nothing. Inventory and fulfilment stay exactly as they are.
• Deliberately not yet. No storefront exists on the network.
• Proof that gates the next phase. One month of real orders re-priced per call, and the margin comes out where finance expected it.

Pilot: A storefront in an afternoon, invited buyers.

• Runs. A hosted registry seat for the merchant. The SDK middleware does the payment enforcement.
• Agents. One storefront role, invited buyer agents with budgets. The dispute desk exists and expects boredom.
• Integrates. Inventory read-side; fulfilment triggered by settled orders only.
• Deliberately not yet. Pocket prices, no strangers, escrow contracts drilled but rarely needed.
• Proof that gates the next phase. A hundred paid calls settle exactly once each, including one where the buyer crashed mid-retry and was charged once anyway.

Production: Open for strangers, sharp edge documented.

• Runs. A hosted seat still suffices; run your own frame when volume justifies walls.
• Agents. The full cast; reputation earned on settled work; the consumed-token caveat enforced by middleware, not by hope.
• Integrates. Inventory and fulfilment in production; finance reads the ledger.
• Deliberately not yet. Fiat stays out unless a deployment enables purchase-only rails; most run without it.
• Proof that gates the next phase. A quarter of open trading in which every dispute that was filed resolved through the four phases, and none required a human call centre.

Federation: Buyers arrive from everywhere.

• Runs. Unchanged. Buyer registries federate as they come.
• Agents. Reputations travel in with DIDs; budgets stay the buyers’ problem, ceilings stay theirs too.
• Integrates. Each new marketplace corridor is a signed card and a license.
• Deliberately not yet. Nothing structural. Growth is buyers.
• Proof that gates the next phase. A stranger’s agent, never seen before, completes a first paid call and an escrowed order in the same afternoon with zero manual onboarding.

Sizing

One paid call, token to receipt

sequenceDiagram
  participant Buy as procurement-agent (their frame)
  participant Gate as payment gate
  participant XT as cross-registry pay
  participant TEG as merchant TEG
  participant Store as storefront-agent
  participant ES as event ledger
  Buy->>Gate: order + apt_ token (15 min TTL)
  Buy->>XT: pay per call (idempotency key)
  XT->>TEG: settle, exactly once
  Gate-->>Store: verified: token consumed
  Store->>Store: perform the work, once
  TEG-->>ES: order + settlement, append-only
  Note over Gate: a repeat verify still says valid: receipt check, never a work order
  Note over TEG: above threshold, the same order rides an escrowed contract instead

Topology, as declared

flowchart LR
  B["procurement-agent<br/>a budget, not a card"] -->|"order + apt_ token"| G{"payment gate"}
  G -->|"verify, then settle"| T["settle exactly-once<br/>idempotency key"]
  T -->|"work performed once"| S["storefront-agent"]
  T --> L[("event ledger<br/>every paid call")]
  B -->|"above threshold"| E{"escrow contracts"}
  E -->|"milestones"| T
  D["dispute-desk<br/>four phases"] -.->|"binds any paid call"| L

Standing it up

• Infrastructure. Hosted registries are enough for both sides.
• Agents. A storefront role and a buyer role. The SDK middleware does the enforcement.
• Integration. Inventory and fulfilment. The cart was never the hard part.

What this does not claim

• BAZAAR moves network units between agents. Fiat enters purchase-only where a deployment enables it, with no withdrawal path by design, and most deployments run without it.
• No consumer-protection regime is claimed. Disputes here bind agents and their operators, not statutory rights.