Signed interfaces

The same machine-readable records support a CLI, applications, and external agents acting under participant authority. Every interface is an entry mode into a role protocol — none of them is a lifecycle stage, and none of them creates a central market actor.

Interface	Intended user	What it controls	Authority
CLI	Human participant	Discovery, proposal, commitment, and inspection	The invoking buyer, seller, or operator
Signed HTTP	Application or service	Signed role protocol calls	The participant whose interface is called
Python	Workflow or policy integration	Candidate aggregation and workflow logic	The participant that configures it
External agent	Long-running participant agent	Signed role calls under one participant policy	The controlling participant, including final commitment

CLI surfaces

Two console scripts ship at the pinned revision: the buyer's market (package arkhai-core-buyer, with domain plugins such as arkhai-vms-buyer) and the seller's market-storefront admin CLI. The CLI reference enumerates the proven command surface; Start here covers install and local verification.

Signed HTTP role protocols

Participation over HTTP is signed and role-scoped:

• Publication — publishing is an EIP-191-authenticated POST /listings; the body carries the claimed signing address and a signature over create_listing:<identifier>:<timestamp>, and the Registry creates the publisher record from the first valid signature. The full listing payload is not what that signature covers. Mutations are owner-scoped to the recovered signing address; this attribution is not real-world identity verification. Evidence: registry listing routes and the storefront-publication specification.
• Discovery — Registries expose read APIs (GET /listings with filter-spec parameters, GET /filter-spec, GET /health), optionally behind bearer-token read gates. Evidence: the registry-discovery specification.
• Negotiation — buyers drive signed synchronous request/response rounds against the storefront (/negotiate/new, /negotiate/{id}); negotiation is a deterministic reduction of the shared message history to agreed Terms. Evidence: the negotiation-protocol specification.
• Settlement — the buyer creates the on-chain escrow for the accepted proposal and submits settlement to the storefront, which verifies escrow and services claims through the configured mechanism. Evidence: the settlement-servicing specification.
• Seller operations — storefronts expose authenticated admin surfaces (for example POST /api/v1/admin/resume after a global pause, and GET /api/v1/system/status for operational state), plus public listing reads at GET /api/v1/listings. Evidence: the curated Storefront and listing management task and pinned storefront source.

Python policy hooks

Policy is code the participant controls: negotiation middleware chains share one contract on both sides, and buyer aggregation policies own iteration across candidates. Both register through decorators or file discovery — synchronized in Configuration and the middleware module.

External agents

Long-running agents call the same signed role interfaces and execute the same configured policies. SCM supplies role protocols and policy hooks — not a bundled LLM or autonomous-agent runtime — and an agent's decisions bind only the participant that controls it.