Simple Compute Market Design Patterns

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.