Skip to main content

2 posts tagged with "market design"

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.