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 splits a market into recurring parts: separable roles, configured registry discovery, pluggable scalar-price policy, an explicit settlement handoff, and a domain-specific delivery adapter
• Buyer, seller storefront, and indexer are the runtime roles; policy, provisioning, registry, and settlement remain separable services or boundaries
• A line runs through the system: behavior that holds for every listing belongs to the market core, and anything that varies by what is sold is injected from below
• The reusable part is the separation of concerns, which is what makes the structure portable across domains
• Compute is the first domain; another market keeps the structure but brings its own delivery, metering, evidence, recovery, and release criteria

Start with a concrete question: what can you reuse from SCM when you build a different agent-driven market?

SCM is software for compute markets. The way it is built splits a market into parts that recur, and those parts are worth naming.

The launch and workflow posts showed the system running. This one pulls out the patterns.

The Roles Are The Pattern​

SCM has three explicit runtime participant roles: buyer, seller storefront, and indexer. Registry and market operators configure deployments, while policy, provisioning, registry, and settlement remain separable services or boundaries. None has to own the others.

Discovery runs through one or more configured operator registries, not one mandatory platform-owned search broker; registry access can still be gated. Registries index offers and coordinate discovery. Arkhai currently charges no SCM platform fee, but operators may choose deployment economics and sellers, infrastructure, networks, settlement rails, and services can still impose costs. Zero protocol fees remain intended direction rather than guaranteed economics. Negotiation runs peer-to-peer over signed request and response, mediated by pluggable policies. Current VM rounds vary scalar price while resource, duration, provisioning, and non-amount escrow fields stay fixed or validated. Commitments, crypto-native settlement, release criteria, and recovery run through Alkahest. The public open-beta code release uses KVM VMs with optional GPU passthrough as its concrete domain adapter; other adapters require separate implementation and confirmation. A Puffer-trained reinforcement learning pricing policy is one implementation path inside that frame.

The useful idea is the separation itself. Each role has a clear contract, so you can change one without rewriting the others.

What Stays Fixed, And What Varies​

The deeper pattern is a line drawn through the system. A behavior belongs to the market core only if it holds for every possible listing. Anything that varies by what is being sold is supplied from below, through an injected hook.

That gives a clean test. The shared structure, discovery, negotiation rounds, and the settlement handoff are invariant. Message meaning, how a participant prices its next move, and valid terms are schema- and policy-defined. In the current VM flow, this extensibility does not mean arbitrary-term negotiation: signed rounds vary scalar price, while non-price VM terms remain fixed or validated.

The settlement boundary makes it concrete: negotiation reduces a conversation to terms, and settlement turns terms into a commitment. Pricing decisions stay separate from custody. Changing a policy should not touch settlement, and changing the delivery adapter should not erase the commitment.

The market surfaces fall out of that line: signing provenance and metadata, discovery and listing state, policy-driven scalar-price negotiation, escrow and settlement assets, the delivery adapter and its evidence, claim, refund, reclaim, recovery, and arbiter criteria, post-trade state, and the deployment's own operating-model choices. Signing provenance is not verified legal identity or KYB. Each boundary is explicit rather than hidden behind one mandatory platform.

What Carries Over​

The reusable part is the separation itself: roles with clear contracts, configured registry discovery, pluggable scalar-price policy, an explicit settlement handoff, and delivery scoped to one domain. Each piece has a defined edge, so each can change without rewriting the others. That is what makes the structure portable.

Compute is the first domain. Another market keeps that structure but brings its own delivery, metering, evidence, recovery, and release criteria. The patterns give you a market's shape; each domain still does its own work.

Inspect The Patterns​

• Read the architecture
• Explore the repository
• Read the CGT pattern language
• Tell us which market you would build next
• Explore Arkhai Compute

Make the structure explicit. Keep decisions local. Keep delivery concrete.

Next, the roadmap: what the public open-beta code release is meant to test, and where it goes from here.

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 lets sellers publish capacity to one or more configured operator registries, negotiate scalar price under seller policy, and settle through Alkahest, while provisioning stays on the seller service
• The seller flow is one path: deploy, publish, set policy, settle, provision, and operate
• Sellers keep control of seller-originated rates, infrastructure, reachability, provisioning, and delivery within the settlement assets, networks, and deployment boundaries configured by registry and market operators
• Wallet signatures establish signing-publisher provenance, not verified legal identity, KYB, quality, or capacity
• Settlement is Alkahest-backed and verified on-chain before you provision
• The public open-beta code release provisions KVM VMs with SSH credential handoff and optional GPU passthrough; other delivery adapters require separate implementation and confirmation

Useful compute capacity does not become a market just because it has a listings page.

To sell it, you need market machinery: machine-readable offers, negotiation policy, commitments, provisioning, delivery evidence, accepted settlement assets, and release criteria. Compute networks and operators usually end up building that plumbing themselves, or renting it from a platform that then owns the customer relationship.

SCM gives sellers that machinery as inspectable software. You run market-storefront: publish capacity to one or more configured operator registries, negotiate scalar price under your own policy, settle through Alkahest, and keep provisioning on your own service. Registry access may be open or gated. The buyer's side has its own post; this is the same workflow from the seller's seat.

The public open-beta code release provisions KVM virtual machines with SSH credential handoff and optional GPU passthrough. Other delivery adapters require separate implementation and confirmation.

The Seller's Problem​

A seller has capacity. What it lacks is everything around the sale.

Buyers driven by software need offers they can read, prices they can negotiate under policy, a commitment they can trust, delivery they can verify, and settlement that resolves on its own. Build all of that per market and the plumbing becomes the product. Hand it to a platform and the platform owns the relationship, the pricing model, and the payment rails.

SCM separates the layers: the seller runs its storefront and delivery infrastructure, while a registry or market operator configures and runs its own registry, access, settlement, topology, and operating boundaries. One party may take more than one role, but the software does not conflate them.

The Seller Flow​

Standing up a storefront follows one path:

• Deploy. Run market-storefront through Docker Compose, Helm and Kubernetes, or the raw runtime.
• Publish. Establish signing-publisher provenance with a wallet signature and publish offers to one or more configured operator registries. A signature is not verified legal identity or KYB.
• Set policy. Configure the negotiation policy so the storefront returns accept, counter, or exit decisions. The current VM flow negotiates price; the selected schema and policies validate payment and settlement fields.
• Settle. Use Alkahest-backed escrow for accepted commitments, and verify the on-chain obligation before you provision.
• Provision. Connect KVM VM provisioning with SSH credential handoff for the shipped delivery path.
• Operate. Surface lease status, delivery evidence, recovery paths, and settlement state.

Reachability can use ordinary public endpoints or an optional ZeroTier overlay for private reachability, depending on deployment configuration.

Throughout, the split holds. SCM software coordinates the workflow; seller infrastructure delivers the machine; registry and market operators configure their deployments. No single mandatory broker is required.

What To Try​

A seller or operator can evaluate SCM in steps:

• Inspect the storefront runtime in the repository.
• Follow the seller quickstart.
• Connect a test backend for the KVM VM path.
• Run a buyer negotiation against a test storefront and watch your policy decide.
• Decide whether deterministic, custom, or a Puffer-trained reinforcement learning policy fits your pricing.

Try The Seller Flow​

• Explore the repository
• Follow the seller quickstart
• Add VM reachability with FRP
• Explore the seller pathway
• Scope a seller deployment

Your infrastructure. Your policy. Your seller-operated delivery path.

Define the offer. Set the policy. Confirm the commitment. Deliver the machine.

Next, the design patterns underneath all of this: what belongs to the market, what belongs to participants, and what stays specific to the resource.

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 gives buyers a software-driven path through configured registries: discover, negotiate scalar price, escrow, receive, and settle
• Agent procurement needs machine-readable evidence and actions rather than browser-only dashboards and manual clicks
• Beyond machine-readable APIs, SCM adds crypto-native settlement, policy-governed price negotiation, deployment-set settlement assets, and arbiter and release criteria
• Buyer software drives buyer-side decisions through discover, evaluate, negotiate, commit, receive, track, settle, and recover; the seller still provisions and delivers
• Listings retain publisher provenance, seller-asserted availability, and separate displayed and final terms; provenance is not verified legal identity or KYB
• The public open-beta code release provisions KVM VMs with SSH access and optional GPU passthrough; other delivery adapters require separate implementation and confirmation

Your software can already schedule a workload. Buying the compute to run it still means dashboards, sales forms, fixed catalogs, quotes, and a person clicking approve.

That model does not fit an agent.

SCM gives buyers a path through one or more configured operator registries: discover publisher-attributed listings, negotiate scalar price under policy, lock escrow, receive access, and settle through software. Registry access can be open or gated, and operators and optional services can still coordinate a deployment; SCM does not require one mandatory platform-owned broker. The launch post introduced the release; this is the same software from the buyer's seat.

The public open-beta code release has a concrete delivery path: KVM virtual machines with SSH access and optional GPU passthrough. Other delivery adapters require separate implementation and confirmation.

What Agent Procurement Needs​

Human buying assumes a human in the loop: a dashboard to read, a form to fill, a quote to wait on, an approval to click. None of that survives contact with an agent that has a workload, a budget, and a deadline.

An agent needs the market evidence to be inspectable. Listings retain signing-publisher and source provenance, but that is not verified legal identity or KYB. Availability is seller-asserted rather than independently verified real-time capacity. Displayed terms and final negotiated terms remain distinct; commitments, delivery state, and the settlement path must be readable without implying that every assertion is verified.

Plenty of compute APIs are already machine-readable. What SCM adds is crypto-native settlement, policy-governed price negotiation, settlement assets that can vary by deployment, and arbiter and release criteria a deployment can set for itself.

It also means a registry or market operator does not rebuild escrow, recovery, and settlement from scratch for every new deployment. Those paths come with the buyer flow.

The Buyer Flow​

The buyer's path through SCM is a sequence software can drive on the buyer side; sellers remain responsible for infrastructure, provisioning, credentials handoff, and delivery:

• Discover. Query one or more configured operator registries for listings.
• Evaluate. Weigh the offers against what the workload needs.
• Negotiate. Talk to a seller's storefront over signed HTTP and a negotiation policy. The current VM flow negotiates price; duration, resource, and escrow fields are fixed or validated by the selected schema and policies.
• Commit. Lock escrow through Alkahest once terms are accepted.
• Receive. Take VM access through SSH credential handoff.
• Track. Follow lease status and delivery evidence.
• Settle and recover. Work the settlement, reclaim, refund, and recovery paths when a deal completes, expires, or fails.

Buyer-side choices remain under buyer policy. Sellers still provision and deliver, while operators configure registries, access, and settlement. No single mandatory broker must hold the relationship, set a universal price, or custody the funds.

What To Try​

A buyer evaluating SCM can start small:

• Inspect the market buyer runtime in the repository.
• Follow the buyer quickstart.
• Run or read a negotiation against a market-storefront.
• Decide whether KVM VMs, with optional GPU passthrough, fit the first workload, or whether another compute adapter should be scoped separately.
• Decide which pricing policy fits: deterministic, custom, or a Puffer-based reinforcement learning example.

Try The Buyer Flow​

• Explore the repository
• Follow the buyer quickstart
• Request a Market
• Scope a buyer evaluation

Find compute. Agree on terms. Make a credible commitment. Receive the machine.

Give software a workload. Let it procure compute.

Next, the seller's side: publishing capacity, setting policy, verifying commitments, and running delivery.

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.

Simple Compute Market Series: Part 1 of 6

Historical release context — May 29, 2026 component release

This post describes the 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

• The Simple Compute Market (SCM) public open-beta code release is available for evaluation
• Buyers, sellers, and indexers get a machine-readable path through discovery, negotiation, escrow-backed commitments, provisioning, lease state, and settlement
• CLI-based with configured operator registries and no single mandatory matching broker; access can still be operator-gated
• Settlement runs through Alkahest escrow, and the release provisions KVM VMs with SSH credential handoff and optional GPU passthrough
• The release had no SCM-native token; current main is covered by the root MIT license, and current Arkhai SCM fee boundaries are documented separately below

The Simple Compute Market (SCM) public open-beta code release is available for evaluation.

SCM software implements infrastructure for agent-driven compute markets. Buyer software can discover across configured registries, negotiate scalar price under policy, lock escrow, receive seller-operated access, and settle without a human driving every step.

The release connected a bounded, machine-readable compute agreement to an onchain settlement commitment; it did not implement arbitrary-term exchange.

Most marketplace software assumes a human buyer, a human seller, and a platform in the middle of every decision. SCM starts from the opposite assumption. The next compute buyer is software with a workload, a budget, a deadline, and a policy.

We started with compute because it is the resource agents reach for first. The public open-beta code release gives buyers, sellers, and indexers a machine-readable path through the compute-market loop: discovery, negotiation, escrow-backed commitments, provisioning, lease state, and settlement.

SCM is CLI-based for buyers and sellers. Indexers run operator-configured registry APIs that sellers publish to and buyers query. SCM does not require a single mandatory matching broker, but deployments can still have registry operators, access policies, governance, and optional services.

The release had no SCM-native token. SCM's current main source is covered by the repository's later root MIT license; the May 29 component tag predates that license. Arkhai currently charges no SCM platform fee, while sellers, infrastructure providers, networks, settlement rails, operators, and services can still impose costs. Zero protocol fees are intended direction, not guaranteed economics. Registry access may be open or gated under an operator's policy.

What Launched​

The public open-beta code release includes the basic roles and runtime surface for an agent-driven compute market:

• Buyers run market to discover listings, negotiate with seller storefronts, lock escrow, receive access, and track lease state.
• Sellers run market-storefront to publish listings, negotiate under their own policies, set accepted settlement assets, and manage delivery.
• Indexers run the listings registry / indexer API that supports discovery and coordination.
• Policies run through market-policy, which supports rule-based and custom policies, including reinforcement learning pricing strategies.

Signing provenance is Ethereum-native in this release. Participants authenticate with wallet signatures, which identifies the signing publisher but does not verify legal identity, KYB, service quality, or capacity. The identity layer is pluggable, so operators can separately integrate another scheme. ERC-8004-compatible identities are possible as an external extension, but they are not core SCM support.

Negotiation is buyer-driven and policy-mediated. Buyers send signed HTTP requests to seller storefronts. Seller policies can quote, counter, accept, or walk away. In the current VM flow, rounds vary scalar price while resource, duration, provisioning, and non-amount escrow terms remain fixed or validated.

Settlement runs through Alkahest escrow. SCM examples center ERC-20 flows today, while Alkahest can settle ERC-20, ERC-721, ERC-1155, native-token, and bundled-token obligations. That leaves room for futures and other derivatives to settle onchain through the same broader settlement path.

The public open-beta code release provisions KVM virtual machines with SSH credential handoff and a full lease lifecycle, with optional GPU passthrough. Other resource adapters require separate implementation and confirmation. vm, container, and bare_metal appear as metadata / filter vocabulary, not claimed delivery adapters.

Deployments can also choose optional private reachability through a ZeroTier overlay or an FRP (Fast Reverse Proxy) tunnel for remote SSH access.

Why Compositional Game Theory​

SCM is inspired by Compositional Game Theory (CGT), without following CGT formalisms strictly.

The reason is composability. Signed endpoints, CLI commands, registry records, and negotiation middleware can be wired into larger market behavior. That decomposition gives learning agents a clean action surface: buyers aggregate listings, sellers respond through policies, indexers support discovery, and each side can change policy chains without changing the rest of the market.

SCM does not claim formal strategy-proofness, equilibrium guarantees, or strict CGT implementation. It uses CGT as a pattern language for building markets out of smaller pieces that agents and operators can reason over.

What You Can Build​

A few of the things teams can build on SCM today:

• A marketplace layer for a compute network. A network with aggregated compute supply but no market machinery can use SCM as its open market layer: providers run market-storefront, buyer agents run market, indexers support discovery, and Alkahest provides enforceable commitments.
• Idle or surplus compute monetization. A datacenter, cloud provider, or GPU operator can list capacity through a storefront under a pricing policy it controls. Surplus held under a reservation or over-provisioned cluster becomes a normal market activity rather than a workaround.
• Agent-driven procurement. An autonomous system or other buyer agent can run market to discover, negotiate, commit, and consume compute. The flow is machine-readable, and its settlement commitment is onchain; this does not make every offchain listing, availability assertion, or delivery fact independently verified.
• Custom pricing and negotiation strategies. Both sides can drive negotiation through pluggable policies: rule-based, fully custom, or reinforcement learning strategies.

Who It Is For​

• Registry and market operators that want open infrastructure for discovery, negotiation, and settlement without a single imposed platform model.
• Compute sellers and resource operators that want control over seller-originated listings and rates, negotiation policy, infrastructure, provisioning, and delivery within an operator-configured settlement environment.
• Compute buyers and agent developers wiring agents to procure compute programmatically.
• Indexer operators that want to run the listings registry / indexer API for the market.
• L1/L2 ecosystems and agent tooling ecosystems looking for concrete agent-commerce infrastructure.

What To Try​

• Browse the code
• Run the buyer quickstart
• Stand up a storefront and list capacity
• Write a negotiation policy through market-policy
• Scope adapter, deployment, or integration needs

The public open-beta code release is market infrastructure, not a hosted compute catalog operated by Arkhai. Source and release evidence do not establish any live listing, available capacity, or participating provider; the current website fails closed without an approved source and labels any availability as seller-asserted.

Evaluate the Release​

Providers, buyers, and indexer operators can evaluate the release through the role quickstarts.

• Explore Arkhai Compute
• Explore the code
• Request a Market
• Alkahest
• Compositional Game Theory docs
• Compositional Game Theory GitHub
• Whitepaper