Skip to main content

6 posts tagged with "simple-compute-market"

View All Tags

Compute Sovereignty and Programmable Markets

Compute Sovereignty and Programmable Markets

How buyers, sellers and market operators can shape the agreements and markets they depend on, with compute as the worked example.

September 29, 2026 · Arkhai Team

How participants can shape the agreements and markets they depend on

AI is redrawing the boundary of the firm. A small team can now do work once spread across entire departments. Large companies can coordinate more complex work across business units, suppliers and regions. The scale differs; the dependence does not.

Every company owns only part of what it needs. The chips, the power, the capital and the routes to customers often belong to someone else. Much of what sits outside a company arrives by agreement.

When a supplier reprices, a contract ends or a venue changes its rules, the speed of software stops mattering. A company can move only as fast as it can form its next workable agreement.

That agreement has a cost: finding a counterparty, judging whether they are credible and settling terms both sides can carry out. The cost sets how much power the current relationship holds. If replacing a supplier takes private introductions, weeks of assessment and a bespoke negotiation, the supplier is more than a vendor. It is a dependency. If customers can be reached through only one venue, that venue decides which businesses are seen and on what terms.

Compute sovereignty means that participants retain meaningful authority over the decisions that belong to them. Buyers shape how they source capacity and make commitments. Sellers shape what they offer, how they price it and how they fulfill it. Market operators shape the rules of their venues. Exercising that authority across many relationships requires infrastructure that can carry those choices into action.

A programmable market is a market whose offers, negotiation policies and venue rules can be expressed in software while participants retain authority over the commitments they make. This makes compute sovereignty practical by giving participants shared infrastructure for discovering counterparties, forming agreements and developing markets without placing every relationship under one operator.

The business behind the model​

Consider a company that provides AI inference. Its customers see an API. Behind that API is a chain of commitments.

The company needs machines with enough memory, in a useful region, for long enough to run its models. A compute provider needs prices and commitments that justify making those machines available. The inference company combines that capacity with its models, software and operations, then sells a new service to its customers.

On Monday, a customer asks the company to process a large archive by Friday. The job needs roughly 36 hours on hardware the company does not hold. Its usual supplier has nothing free that week.

The company searches for continuous access through Thursday. Another supplier has the right machines, but they are committed during the day and open for ten hours each night.

In a catalog, that is the end. The request matches nothing and disappears. The company's answer to its customer now rests on a supplier it could not replace.

A programmable market carries the conversation further. The company knows whether its job can stop and resume. The supplier knows which nights are open. Four nights may provide enough machine time once restarts are counted, or they may not. The two sides can find out. If the numbers work, they agree on a schedule neither offered at the start. Friday remains the company's deadline to meet. The agreement gives it the capacity to try.

They may also discover that no workable agreement exists.

A mismatch is information. An unmet request reveals demand for an offer nobody has built. A successful negotiation reveals something more: a combination of timing, price, risk and commitment that real participants will accept.

One agreement does not create a market. When similar agreements recur, however, a pattern begins to appear. Participants can encode that pattern as a new offer, a purchasing policy or an independently governed market. What began as an exception becomes infrastructure.

From a conversation to a market​

A programmable market treats the agreement as something participants can develop, rather than merely select. Offers, negotiation policies and venue rules can be expressed in software. Software searches, compares and carries out the rules the participants accepted. Buyers and sellers still make the commitments.

Simple Compute Market (SCM) provides open-source infrastructure for programmable compute markets. Sellers run their own storefronts and publish listings to federated registries, which store, validate and expose those listings for discovery. Buyers search those registries, then negotiate prices directly with seller storefronts through SCM's peer-to-peer infrastructure. The policies SCM ships with negotiate price. Participants can replace them with policies they write themselves.

Sellers can publish through several registries without surrendering their storefronts or rebuilding every offer. Buyers can apply their purchasing policies through their own tooling across different registries. Changing an intermediary does not have to mean giving up the commercial capability built around it.

That portability does not remove the work of discovery. Buyers still judge reliability, hardware fit and operating conditions. Participants could organize curators or buyer groups to share assessments and maintain venues around common requirements. Each buyer still decides which assessments to trust and which agreements to accept. Another supplier still has to exist and want the deal. Open infrastructure keeps the path short when one does.

SCM also separates roles that a conventional platform bundles together. Different operators can run registries, storefronts, settlement services and fulfillment systems while sharing the interfaces that let them work together. Market builders can reuse those components, then concentrate on the rules and services that make their markets different.

Shared interfaces do not require shared rules.

What a lender can read​

One overnight agreement is an anecdote. When the same agreement recurs, it becomes something a supplier can plan around and a lender can read.

Infrastructure is built on that kind of evidence. Operators commit to equipment, power and facilities years before the last unit of demand appears. Their customers plan in months, weeks or hours. Financing works best when the gap between them holds credible offtakers, clear credit signals and agreements that can be underwritten.

The inference company sits inside that gap. It can make a longer commitment when it knows what the agreement lets it do with capacity its customers do not use. It can serve more inference customers or run another workload the agreement allows. Handing the capacity itself to another party is a separate transaction. Resale or transfer depends on the supplier's terms, and the original buyer may retain obligations afterward.

Clear records distinguish interest from commitment, commitment from delivery and delivery from payment. They give operators, buyers and financiers better evidence for deciding what to build, fund or purchase. Each longer commitment from a credible buyer gives a supplier more to show lenders and investors.

Those records help a lender decide whether to finance capacity. A buyer faces a different question: whether that capacity can actually serve its workload. Protecting a price and securing usable capacity solve different problems. Location, timing, topology, reliability and contractual fit still determine whether capacity can serve the work.

Programmable markets make offers easier to discover, terms easier to compare and agreements easier to form, or to transfer where contracts allow. As buyers and sellers find one another and commit on clear terms, compute markets can grow deeper and more liquid. In a deeper market, capacity is easier to finance, buy and sell.

Markets people can shape​

Compute is where this example begins because the need is immediate and the constraints are physical. The pattern is larger.

A solar farm has power at midday that the grid will not take. A lab needs access to a dataset for three months, but the only license offered lasts a year. A dozen clinics need the same privacy terms from an inference provider, and none is large enough to ask alone. Each is an agreement waiting to be formed. None appears in a catalog, because a catalog contains only what someone has already thought to offer.

In a programmable market, each can begin as a negotiation. Participants can develop arrangements that recur into standing offers, then organize those offers into venues with their own rules: a registry maintained by a trade association, a buyers' group with a shared purchasing policy or a regional market connecting power and compute.

Businesses can help shape what is offered, which terms can change, how participants find one another and what authority they delegate. Shared registries, storefronts, negotiation tools and settlement components give new markets a foundation, with no single platform in control of every relationship.

That authority will matter more as AI expands what organizations of every size can attempt. It will let more people start companies, help established businesses coordinate more ambitious work and give infrastructure operators new ways to serve demand. The same question reaches buyers, sellers, lenders and market organizers: can they replace, renegotiate or reshape the agreements on which they depend?

If every important resource and customer relationship runs through an intermediary that cannot be replaced, software has made the organization faster without making it freer.

Compute sovereignty depends on more than access to a machine. It depends on whether participants can make their own decisions, form the next agreement and help shape the market around it. Programmable markets let the people who depend on a market help build it.


Arkhai is developing an optional managed service intended to make participation easier by handling hosted access, accounts, billing and support. Participants would still retain meaningful authority within the service: buyers would shape how they source capacity and make commitments, sellers would shape their offers, prices and fulfillment, and each side would decide which agreements to accept. SCM remains open source, and buyers and sellers can use it without Arkhai. The managed service is intended to reduce the work around participating in a market without becoming the only path to it.

Request app access.

Simple Compute Market Design Patterns

Simple Compute Market Design Patterns

Historical May 29, 2026 component-release design context: separable roles, configured-registry discovery, scalar-price policy with non-price VM terms fixed or validated, explicit settlement, and domain-specific delivery.

June 17, 2026 · Arkhai Team

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​

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 For Compute Sellers

Simple Compute Market For Compute Sellers

Historical May 29, 2026 component-release seller context: seller publication, signed, bilateral, policy-governed scalar-price negotiation with non-price VM terms fixed or validated, escrow verification, and seller-operated KVM delivery; optional GPU passthrough proves no inventory or availability.

June 15, 2026 · Arkhai Team

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​

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 For Compute Buyers

Simple Compute Market For Compute Buyers

Historical May 29, 2026 component-release buyer context: configured-registry discovery, signed, bilateral, policy-governed scalar-price negotiation with non-price VM terms fixed or validated, escrow, and seller-operated KVM access.

June 11, 2026 · Arkhai Team

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​

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 Architecture

Simple Compute Market Architecture

Historical May 29, 2026 component-release architecture context: separable buyer, storefront, indexer, policy, provisioning, registry, and Alkahest settlement roles.

June 9, 2026 · Arkhai Team

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​

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 Public Release

Simple Compute Market Public Release

Historical May 29, 2026 component-release context: configured-registry discovery, signed, bilateral, policy-governed scalar-price negotiation with non-price VM terms fixed or validated, Alkahest settlement, and seller-operated VM delivery.

May 29, 2026 · Arkhai Team

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​

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.