From listing to delivery
The common core of every SCM market is exactly Discovery, Negotiation, Settlement, and Arbitration. Settlement includes payment; delivery is seller-owned and follows Settlement; what a domain adds is vocabulary — what is listed, what is negotiable, what delivery and evaluation mean.
The lifecycle
One deal moves through seven observable states:
| Stage | Owner | What happens |
|---|---|---|
| Listing | Seller | The storefront sends an authenticated publish request; chosen Registries attribute the listing to the recovered signing address. |
| Discovery | Buyer | The buyer queries chosen Registries and compares candidates under buyer policy. |
| Accept or negotiate | Buyer ↔ seller | Listed-price acceptance is the direct path; signed scalar rounds run only where configured. |
| Agreement | Participants | One explicit total is accepted; the shared round history reduces to Terms. |
| Payment settlement | Configured mechanism | The buyer creates escrow and submits settlement; obligations are serviced by the configured mechanism. |
| Seller delivery | Seller | Fulfillment produces the domain result — machine access, credentials, quota. |
| Evaluation or configured resolution | Participants | Domain- and mechanism-defined evaluation, claims, refunds, or expiry complete the deal. |
The pinned end-to-end statement of this flow is the domain-authoring lifecycle (Custom-domain authoring). The Registry participates in listing publication and Discovery only; acceptance, optional negotiation, and the stages that follow use buyer tooling, the seller storefront, and the configured settlement mechanisms directly.
Negotiation is optional; the listed price is the path
Listed-price acceptance is the default. The buyer's default policy opens at the listing's advertised price and never counters; scalar negotiation (bisection, or a trained RL policy) is opt-in and configured per side. When it runs, only the payment amount moves — quantity, duration, and other pinned terms stay fixed, and each side's shape guard rejects counters that mutate a pinned field.
Accept, Reject, Propose, and Timeout are outcomes of one pluggable, participant-controlled agent policy — an ordered middleware chain each side configures — not four separate mechanisms. The chain contract, bundled policies, and defaults are synchronized in Configuration; the task view is Optional negotiation.
Buyer aggregation never takes commitment
Across candidate listings, the buyer runs one aggregation policy that may order, score, race, or select — sequential cheapest-first, parallel best-price, fastest-agreed, and similar shapes ship at the pinned revision. Aggregation cannot change seller terms and cannot take over the buyer's explicit commitment: Agent policy and buyer aggregation.
Settlement includes payment; Arbitration is the escrow-arbiter surface
Agreement and settlement stay distinct. Accepted Terms materialize into a payment amount, selected escrow kind, and one concrete arbiter demand. The configured settlement mechanism — Alkahest-backed on-chain escrow at the pinned revision — then services the obligations: escrow verification, claims, refunds, expiry and reclaim.
Arbitration in this core means the escrow-arbiter surface: a listing
declares which arbiter demands it accepts (demands[]), the buyer's
proposal concretizes exactly one, and settlement claims are arbitrated
against that demand on chain. Composite conditions are expressed as one
logical demand (for example an AllArbiter). The pinned revision does not
implement a general dispute-resolution workflow, and this documentation does
not describe one. Evidence:
domain authoring — accepted settlement choices
and
the settlement-servicing specification.
Delivery is seller-owned
After settlement, the storefront performs or coordinates fulfillment through seller infrastructure: VM provisioning against reserved capacity, an issued bearer credential with quota, whole-machine SSH access. The Registry plays no part in delivery, and no platform actor sits between buyer and seller. The delivery task views are Fulfillment and seller delivery and the domain guides.
Watching a deal as data
Every stage above is machine-readable: listings as Registry JSON, rounds as signed HTTP messages, agreements as canonical history, settlement as chain state, delivery as typed fulfillment results. The Machine-readable records shows the Registry wire shape and two richer website review projections; the Market page renders those review projections as a human-readable inspection surface.