Reference
What it does
The market module implements the exchange itself. Tenants post orders describing the resources they need; orders naming a specific offering match it outright at the listed price, while open orders collect competing bids from provider daemons watching the chain. A match becomes a lease — the on-chain contract under which a provider serves a workload and gets paid. All these objects are chain state, created and transitioned by transactions and validated by consensus.
The module enforces the lifecycle rules: an order can only be matched while open, a bid must satisfy the order's resource and attribute requirements, and a lease binds exactly one tenant, one provider, and one escrow account. Lease closure — voluntary, for non-payment, or through enforcement — flows back through the same state machine so every marketplace event leaves an auditable record.
Why it exists: In a conventional cloud, the exchange between buyer and seller happens inside a company's private billing system. VirtEngine's premise is that the exchange should be the protocol: matching, pricing, and contract state executed by consensus rather than by a trusted intermediary. The market module is where that premise is implemented.
State
Primary objects
| Concept | Definition |
|---|---|
Order | A tenant's on-chain request — compute, memory, storage, region, and required attributes — naming a specific offering or open for bids. |
Bid | A provider's priced offer against an open order, placed automatically by the provider daemon. Direct orders never need one. |
Lease | The matched contract between tenant and provider that authorizes a workload and its payment stream. |
Messages
Messages & queries
Message and query surfaces are documented at implementation level in the module docs ↗ and the source ↗. The objects above are the state those messages create and transition.
Connections
Module interactions
-
x/deploymentOrders are derived from tenant deployment specifications and groups. -
x/escrowEvery lease is backed by an escrow account funded before the workload starts. -
x/providerBids reference registered providers and their on-chain attributes. -
x/veidVEID is an optional, offer-specific trust signal; marketplace participation is not universally gated. -
x/settlementUsage recorded against a lease settles into payments from lease escrow.
Flows
Core flow
- Post — Tenant posts an order. A structured, on-chain request for resources: compute, memory, storage, region, and required attributes.
- Match — Direct purchase or winning bid. A named offering matches immediately at its listed price; open orders resolve to the accepted or best-ranked bid.
- Match — A match becomes a lease. The matched contract authorizes the workload and its payment stream, backed by escrow funded before serving starts.
- Close — Usage settles, lease closes. Recorded usage settles into payments from escrow; closure of any kind returns through the state machine as an auditable record.
Questions
Asked about x/market
Who can match an order?
A named offering matches its own direct orders outright. For open orders, any provider whose bid satisfies the resource and attribute requirements, while the order is open. Matching is consensus-validated, never discretionary.
What exactly does a lease bind together?
Exactly one tenant, one provider, and one escrow account — the payment stream is authorized against collateral that provably exists before serving starts.
How does a lease end?
Voluntarily, for non-payment when escrow runs dry, or through enforcement — each path transitions through the same state machine so the marketplace record stays complete.
Related