What is a compute marketplace?

Procurement of infrastructure by telephone works, and every large buyer has done it: describe the requirement, collect quotes, negotiate a contract, sign, wait, reconcile the invoice against a spreadsheet. A marketplace compresses that into structured fields and a published price, because the requirement and the offer are expressed in the same schema on both sides.

It also replaces the discovery problem. Capacity that nobody can find is capacity that does not exist from a buyer's point of view, and the long tail of capable operators - a research facility, a colocation provider, a GPU farm - has never had a fair way to reach demand it does not already know. A public catalogue inverts that: reach follows the listing rather than the vendor's sales history.

Every marketplace in this shape runs the same five stages, in order:

• Order - a deployment states what is needed and funds escrow, so the demand carries provable budget.
• Match - a named offering is taken at its listed price, or an open order collects bids and resolves to the best-ranked one.
• Lease - the match becomes a contract binding one tenant, one provider and one escrow account.
• Usage - consumption is metered, screened for anomalies and submitted in signed batches.
• Settlement - validated records price into line items, wait out a dispute window, then draw down escrow.

The full walkthrough, including what happens when the numbers are contested, is in how the marketplace works. The point of the sequence is that each step produces a record instead of an assertion.

A marketplace supports three buying motions rather than one, and which applies depends on how precisely the buyer knows what they want. A named offering can be taken at its published price when the listing already answers the requirement. An open order can be posted when the requirement is clear and the supplier is not, letting providers compete against it. Or a set of constraints can be submitted and matched against the eligible listings already on the market.

The three price discovery differently. A published rate is a fact to compare before committing; a bid is a negotiation that happens once, in public, under stated rules; a match is a filter doing the work a salesperson would otherwise do. All three end in the same object - a lease, an escrow account and a meter - so a buyer can change path without changing how the resulting consumption is billed.

Matching strangers is the easy part; the hard part is money and accountability. A compute marketplace without escrow asks the provider to serve on a promise, and asks the tenant to prepay a party with no track record. A marketplace without verified counterparties has no way to act when a dispute turns on who actually placed an order. Both problems are structural rather than cosmetic, which is why decentralised cloud designs put identity checks before matching and committed funds before the first hour of service.

On VirtEngine the venue is itself protocol software. Listings are published through one schema no matter which operator posts them, matching rules live in the marketplace module rather than in a private order desk, and the provider daemon reports the usage that settlement consumes. Nothing about how a price was reached or how a reading was accepted has to be taken on trust: the same state is visible to both parties.

The commercial consequence is that terms stop being negotiable secrets. A rate is an attribute of a listing, a dispute window applies equally to both sides, and the settlement fee is a governed parameter rather than a platform's private take. For the mechanics behind those three sentences see escrow and settlement.