web2 — a compute-bridge operator competing on rate

audience: ai

This half of Part II walks the provider side of the coordination-market pattern. An entity runs a TDX-attested compute-bridge that wraps AWS, GCP, Azure, and bare-metal hosts behind one provider identity, and competes with other providers for grants issued by a coalition’s Compute module.

The bridge lives in its own coalition, bridge-β, which ships Compute and registers the bridge as one of many providers. The chapter walks mirror web3 — MEV-searcher rung for rung.

The backing crate is at examples/compute-bridge/; it compiles today (cargo check and cargo test are green) as a minimum-compile skeleton. The backend trait, the fleet router, and the encrypted-receipt crypto are real; the coalition, Compute-module, and shuffle integrations are stubbed locally and land when the upstream crates ship.

What is assumed

The bridge operator already has a coalition’s CoalitionConfig and its Compute module’s OrganismConfig in hand — either because the operator runs the coalition, or because the coalition publishes a handshake page carrying both. The Compute module admits multiple providers, so the bridge is designed around competing on rate, region coverage, TDX posture, and capacity.

Readers are assumed to know Part I: the Compute basic service (ai/compute.md, contributors — Compute), the four emergent-coordination patterns, and the TDX/non-TDX split. Cloud SDKs and bare-metal SSH access are the operator’s problem, not the book’s.

Shape

bridge-β is the bridge’s own CoalitionConfig. It ships the Compute module so the bridge has a place to register; from chapter 7 onward it may additionally ship Chronicle for heartbeat commits. It references no lattice in the minimal version; a compute-bridge operator need not bond against a block-building lattice to run. (An operator whose revenue settles via an on-chain payment contract may later reference such a lattice for settlement reads; chapter 6 covers that.)

The primary member is one shape-2 standalone organism: the bridge itself, registered as a provider in the Compute module’s Collection<ProviderId, ProviderCard>. Its Config folds the declared capability union (regions, CPU/RAM maxes, TDX posture per backend), the rate-table fingerprint, and the TDX image post-hash.

Chapter 7 adds an optional provider-reputation organism when the coalition scores providers — either run by bridge-β alone, or shared across several bridges.

The bridge’s TicketValidator admits the Compute module’s composition (module ACL, scheduler TDX Measurements when pinned) and admits requester tickets issued by the coalition. Incoming grants are gated by the Compute module’s clearing. The bridge’s own ACL controls operator-side access only.

Economic framing

The Compute module is a two-sided platform in the Rochet–Tirole sense (Platform Competition in Two-Sided Markets, 2003): demand on the requester side grows when more providers register, and provider margins grow when more requesters queue. Cross-side externalities set the operator’s pricing problem — the module may subsidise one side (waive scheduling fees for providers) to bootstrap the other. On the matching side, the clearing rule the module publishes is an instance of a two-sided matching market in Roth and Sotomayor’s taxonomy; the bridge’s ProviderCard is the provider’s declared preferences over grant attributes (duration, region, TDX posture), and each cleared grant is one pairwise match between a requester’s intent and a provider’s capacity. Stability of the match replaces revenue-maximisation as the design target where requesters and providers both care about non-price attributes.

The bridge’s rate-table-as-signal maps onto information-design literature: a provider that publishes narrower capacity bands commits to serving the segment it declared and credibly forgoes out-of-segment demand. See Kamenica and Gentzkow, Bayesian Persuasion (AER 2011), for the canonical treatment.

What runs where

TDX on the bridge itself is not optional. A non-TDX build cannot produce the self-quote the provider card folds, so the Compute module’s admission rejects it.

Chapters

1. Setup and shape — Cargo.toml, CoalitionConfig for bridge-β, one boot TOML.
2. Binding to the Compute market — the TicketValidator, the boot flow in src/main.rs, provider-card publication.
3. Reading the market — other providers’ cards, subscriber cardinality, rate signals, clearing records.
4. Wrapping backends — the Backend trait, the Fleet router, and the four backend modules.
5. Provisioning on demand — the grant-handling loop in src/provider.rs.
6. Sealed receipts and settlement — encrypted SSH receipts and market-side settlement.
7. Reputation, retirement, successor chain — provider-reputation bonding, retirement, operator exit.

Unlike web3, the provider side has no market-maker variant. The bridge serves whatever distribution of grants the market clears to it.

Register and non-goals

audience: ai. Code excerpts are drawn from the backing crate. Where the excerpt references a coalition or shuffle type, the crate carries a local stand-in that will be replaced by the real upstream type when the crate ships.

Out of scope: pricing strategy, cloud sub-account negotiations, running the business, comparison with existing cloud marketplaces, the Compute module’s own specification (which lives in contributors — Compute).

Cross-references

• Part I — AI overview
• Part I — emergent coordination — coordination markets
• Part I — compute
• Part II — web3 overview
• Part III — contributors — Compute
• examples/compute-bridge/ source