Simple Compute Market Series

Key Takeaways

• SCM splits a market into recurring parts: separable roles, open discovery, pluggable policy, an explicit settlement handoff, and a domain-specific delivery adapter
• The roles are the pattern: buyer, storefront, indexer, deployer, policy, registry, and settlement, with none owning the others
• 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 a compute market. 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 treats market participants as agents with explicit, separable roles: buyer, storefront, indexer, deployer, policy, registry service, and settlement. None of them owns the others.

Discovery runs through the listings registry, not a platform-owned search box. The registry indexes offers and coordinates discovery; it does not take a cut or own the buyer-seller relationship. Negotiation runs peer-to-peer over signed request and response, mediated by pluggable policies. Commitments, crypto-native settlement, release criteria, and recovery run through Alkahest. Delivery is tied to a concrete domain adapter, which for the open beta is GPU-backed KVM VMs. 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, is invariant. What a message means, how a participant prices its next move, and what a valid set of terms looks like are all schema-defined and swappable.

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: identity and metadata, discovery and listing state, policy-driven 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. Each is a place to plug in, not a place the platform locks down.

What Carries Over​

The reusable part is the separation itself: roles with clear contracts, open discovery, pluggable 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

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

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

Simple Compute Market Series

Key Takeaways

• SCM gives sellers market machinery as open infrastructure: publish capacity, negotiate under your own policy, and settle through Alkahest, while provisioning stays on your own service
• The seller flow is one path: deploy, publish, set policy, settle, provision, and operate
• You keep control of pricing policy, settlement terms, reachability, and delivery, and the marketplace never becomes your operator
• Settlement is Alkahest-backed and verified on-chain before you provision
• The open beta delivery path is GPU-backed KVM VMs with SSH credential handoff and optional GPU passthrough; other compute delivery types are on the roadmap

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 open infrastructure. You run market-storefront: publish capacity, negotiate under your own policy, settle through Alkahest, and keep provisioning on your own service. The buyer's side has its own post; this is the same market from the seller's seat.

The open beta delivery path is GPU-backed KVM virtual machines with SSH credential handoff and optional GPU passthrough. Inference and other compute delivery types are on the roadmap.

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, terms they can negotiate, 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 is the open starting point in between: the market machinery, run by the seller, on infrastructure the seller controls.

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. Register identity with a wallet signature and publish offers to the listings registry.
• Set policy. Configure the negotiation policy so the storefront returns accept, counter, or exit decisions across price, payment requirements, and the settlement terms your deployment supports.
• 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 is your call too: ordinary public endpoints, or an optional ZeroTier overlay for private, member-authorized access.

Throughout, the split holds. SCM runs the market workflow; your infrastructure delivers the machine. The marketplace never becomes your operator.

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
• Scope a seller deployment or pilot

Your infrastructure. Your policy. Your market.

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

Key Takeaways

• SCM gives buyers an open, software-driven path through compute procurement: discover, negotiate, escrow, receive, and settle
• Agent procurement needs the market itself to be inspectable, with no human in the loop to read a dashboard or click approve
• Beyond machine-readable APIs, SCM adds crypto-native settlement, negotiated payment terms, deployment-set settlement assets, and arbiter and release criteria
• The buyer flow is a sequence software controls end to end: discover, evaluate, negotiate, commit, receive, track, settle and recover
• The first delivery path is GPU-backed KVM VMs with SSH access; inference and other compute delivery types are on the roadmap

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 an open path through compute procurement: discover listings, negotiate terms, lock escrow, receive access, and settle, all through software, instead of through an account on a platform-owned marketplace. The launch post introduced the release; this is the same market from the buyer's seat.

The first delivery path is concrete: GPU-backed KVM virtual machines with SSH access. Inference and other compute delivery types are on the roadmap.

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 itself to be inspectable. Listings, terms, availability, the commitment, delivery state, and the settlement path all have to be things software can read and act on.

Plenty of compute APIs are already machine-readable. What SCM adds is crypto-native settlement, payment terms that are negotiated rather than fixed, settlement assets that can vary by deployment, and arbiter and release criteria a deployment can set for itself.

It also means a compute-market deployer does not rebuild escrow, recovery, and settlement from scratch for every new market. Those paths come with the buyer flow.

The Buyer Flow​

The buyer's path through SCM is a sequence software can drive end to end:

• Discover. Query the registry service 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, across terms like price, duration, accepted settlement assets, and release criteria where the deployment supports them.
• 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.

Each step is the buyer's to control. Nothing here asks you to trust a platform to hold the relationship, set the 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 GPU-backed KVM VMs 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
• Scope a buyer evaluation or pilot

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

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.

Simple Compute Market Series: Part 1 of 6

Key Takeaways

• Simple Compute Market (SCM) open beta is live: open-source infrastructure for agent-driven compute markets
• Buyers, sellers, and indexers get a machine-readable path through discovery, negotiation, escrow-backed commitments, provisioning, lease state, and settlement
• CLI-based with no dashboards, sign-ups, or middlemen, and identity is Ethereum-native and pluggable
• Settlement runs through Alkahest escrow, and delivery today centers on GPU-backed KVM/QEMU VM provisioning with SSH credential handoff
• A public good: open source, with no SCM token and no platform fees

Simple Compute Market (SCM) open beta is live.

SCM is open-source infrastructure for agent-driven compute markets. Agents can find compute, negotiate terms, lock escrow, receive access, and settle without a human driving every step.

If you can express it onchain, you can exchange it for compute.

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 open beta 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 the registry API that sellers publish to and buyers query. No dashboards, sign-ups, or middlemen.

It is also a public good. SCM is open source, with no SCM token and no platform fees. Cypherpunk in the practical sense: infrastructure you can run, fork, and verify instead of a platform you ask permission to use.

What Launched​

The open beta ships 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.

Identity is Ethereum-native. Participants authenticate with wallet signatures, and the identity layer is pluggable, so operators can integrate another identity scheme when they need one. 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. Pricing is dynamic because it is part of the market flow, not a dashboard setting.

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. Alkahest is the Zellic-audited primitive SCM consumes; SCM is not separately audited.

Delivery today centers on KVM/QEMU VM provisioning with SSH credential handoff and a full lease lifecycle. GPU-backed compute is the starting point, and inference and other compute delivery types are on the roadmap. 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 LLM agent can run market to discover, negotiate, commit, and consume compute. Every step is machine-readable and backed by a verifiable onchain commitment.
• 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​

• Compute market deployers and coordinators that want open infrastructure for discovery, negotiation, and settlement without a single imposed platform model.
• Compute sellers and resource operators that want control over listings, negotiation policy, deployment, and settlement terms.
• 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 through the pilot form

The open beta is market infrastructure, not a hosted compute catalog operated by Arkhai. Available listings depend on participating providers.

Join The Pilot​

Providers, buyers, and indexers are onboarding now.

• Join the pilot
• Explore the code
• Learn more
• Alkahest
• Compositional Game Theory docs
• Compositional Game Theory GitHub
• Whitepaper