Simple Compute Market Architecture

Simple Compute Market Series

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, and identity is Ethereum-native and open to other schemes
• Core design choices: bilateral negotiation over signed HTTP, a pluggable policy engine, Alkahest reuse for settlement, and open discovery
• The shipped delivery path is GPU-backed KVM VMs with SSH handoff; broader resource adapters are roadmap

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. It is open-source infrastructure for agent-driven compute markets, and its architecture is a set of separable services and roles, not a centralized marketplace. The launch post introduced the release; this post opens it up.

Discovery runs as open userland infrastructure, not a platform-owned search layer. The open beta is compute-first and repository-backed: GPU-backed KVM virtual machines with SSH credential handoff. Inference and other compute delivery types are on the roadmap.

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. Identity is Ethereum-native, carried as generic (scheme, identifier) references so the surface stays open to other schemes. 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, member-authorized networks. 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 settle terms peer-to-peer over signed HTTP, rather than through a matching engine someone has to operate.
• A policy engine as the extension point. Negotiation strategy is pluggable: deterministic, custom, or learned, covering price, payment requirements, and accepted settlement assets where a deployment supports them.
• 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.
• Open discovery, not platform-owned search. Ethereum-native identity plus a registry and listing service replaces ad hoc provider discovery. ERC-8004-compatible identities are available as an external extension.
• A concrete delivery path first. KVM VM provisioning with SSH handoff is the shipped path; broader resource adapters are roadmap.
• 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 negotiate compute terms programmatically.
• Sellers can expose GPU-backed KVM VM capacity through their own listings, policy, and settlement requirements.
• Indexers can run the listings registry for discovery and coordination.
• Market deployers can evaluate separable services and operating models, self-hosted or operator-owned, without being locked into one.
• Pilot partners can find exactly where a delivery adapter, policy, or deployment would need scoped work.
• Researchers and agent developers can read a concrete, end-to-end agent-commerce system.

Inspect The Architecture

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

Open roles. Direct negotiation. Verifiable commitments. No single service has to own the market.

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