Simple Compute Market Architecture

Simple Compute Market Series

Historical release context — May 29, 2026 component release

This post discusses the May 29 market-cli-v0.5.3 component release and its publication-time framing. Current main is later and is covered by the repository's root MIT license; the component tag predates that root license. Neither the release nor current source proves an Arkhai-hosted market or live supply. See Arkhai Compute and current SCM source for current boundaries.

Key Takeaways

• SCM's architecture is a set of separable services and roles, not a single centralized marketplace
• Three roles carry the market and each can run on its own: buyers (market), sellers (market-storefront), and indexers (the listings registry)
• A shared service layer handles chain, Alkahest, and registry access; wallet identity is signing provenance, not legal identity or KYB
• Core design choices: bilateral scalar-price negotiation over signed HTTP, a pluggable policy engine, Alkahest reuse for settlement, and configured registry discovery
• The shipped delivery path provisions KVM VMs with SSH handoff and optional GPU passthrough; other resource adapters require separate implementation and confirmation

Most marketplaces keep their machinery inside one platform: discovery, pricing, payment, delivery, and disputes all run through one operator, behind one account.

SCM is built the other way. Its public open-beta component release supplied software for agent-driven compute markets, and its architecture is a set of separable services and roles, not a centralized marketplace. The later current main source is covered by the root MIT license. The launch post introduced the release; this post opens it up.

Discovery runs through one or more configured operator registries rather than one mandatory platform-owned broker. Registry access can still be gated by operator policy. The public open-beta code release provisions KVM virtual machines with SSH credential handoff and optional GPU passthrough. Other resource adapters require separate implementation and confirmation.

Separable Roles, Not One Platform

Three roles carry the market, and each can run on its own:

• Buyers run the market CLI: discover listings, negotiate, lock escrow, receive credentials, and track lease and recovery state. The buyer is a pure HTTP client with no server.
• Sellers run market-storefront: publish offers, answer negotiations under their own policy, integrate provisioning, and report delivery and settlement state.
• Indexers run the listings registry: a discovery and coordination surface.

Underneath sits a shared service layer the buyer and storefront both use: a chain client, an Alkahest client, and a registry client. Signing provenance is Ethereum-native, carried as generic (scheme, identifier) references so the surface stays open to other schemes; it does not establish legal identity, KYB, quality, or capacity. Settlement runs through Alkahest escrow, with arbiters and claim, refund, reclaim, and recovery paths. Reachability can use ordinary endpoints or an optional ZeroTier overlay for private reachability. And the negotiation layer takes pluggable policies, including a Puffer-trained reinforcement learning pricing example as one option.

The Design Choices Behind It

A few decisions shape the whole system:

• Bilateral negotiation, not a central order book. Buyers and sellers exchange signed offers and counteroffers peer-to-peer over HTTP, rather than through a mandatory matching engine. The current VM flow varies scalar price while resource, duration, provisioning, and non-amount escrow terms remain fixed or validated.
• A policy engine as the extension point. Pricing strategy is pluggable: deterministic, custom, or learned. The selected schema and policies validate payment requirements and accepted settlement assets.
• Alkahest reuse, not custom escrow. Settlement inherits crypto-native assets, arbiter criteria, and release paths instead of hard-coding one platform payment model. Current examples center ERC-20; Alkahest itself can settle ERC-20, ERC-721, ERC-1155, native-token, and bundled obligations.
• Configured discovery, not one mandatory platform-owned broker. Buyers can query one or more configured operator registries; access may be open or gated. Wallet signing supplies publisher provenance, and ERC-8004-compatible identities are available only as an external extension.
• A concrete delivery path first. KVM VM provisioning with SSH handoff and optional GPU passthrough is the shipped path; other resource adapters require separate implementation and confirmation.
• A pattern language, not a monolith. Inspired by Compositional Game Theory: markets composed from smaller pieces agents and operators can reason over.

What The Architecture Enables

Because the roles are separable, different participants can do different things with the same system:

• Buyers can query storefronts and exchange policy-governed offers and counteroffers programmatically.
• Sellers can expose KVM VM capacity, with optional GPU passthrough, through their own listings, policy, and settlement requirements.
• Indexers can run the listings registry for discovery and coordination.
• Registry and market operators can evaluate separable services in self-hosted or operator-owned deployments without being locked into one provider.
• Evaluation teams can identify where a delivery adapter, policy, or deployment would need scoped work; this is not evidence of current partners or deployments.
• Researchers and agent developers can read a concrete, end-to-end agent-commerce system.

Inspect The Architecture

• Explore the repository
• Read the architecture reference
• Explore Arkhai Compute
• Scope a deployment or adapter

Separable roles. Direct scalar-price negotiation. Explicit commitments. No single service has to own the market.

Next, the buyer's path: from a workload to a provisioned machine.