Learn · Marketplace fundamentals
How the VirtEngine marketplace works
VirtEngine combines a Waldur-connected, multi-service catalogue with a five-stage protocol lifecycle: order, match, lease, usage, settlement. Waldur makes private clouds, storage, VMs and fully custom provider offerings available in one self-service surface; the protocol supplies identity, exchange and settlement guarantees. Match runs three acquisition paths: buy a named offering outright at its listed price (direct), open the order to competitive bids, or describe requirements and get matched to the best eligible listing (selector).
Figures
What the tenant does
Describes the service, region, requirements and price expectations — or names a listing outright — and funds escrow so the demand is provably budgeted.
What the provider does
Watches the chain for open demand that matches registered capacity and attributes.
Becomes protocol state
An Order object is created and an escrow account is funded against it.
Stays off-chain
The workload manifest and any tenant-side configuration are prepared for delivery later.
Next — Match — direct purchase, bids, or an attribute match. How the marketplace works
What the tenant does
Takes a published price, accepts a competing bid, or lets the engine resolve eligible listings inside a price cap.
What the provider does
Pricing strategy and bid rules run in the provider daemon; valid bids must satisfy the order's resource and attribute requirements.
Becomes protocol state
The order resolves to a listing, an accepted Bid, or a deterministic selector result.
Stays off-chain
Provider pricing configuration and capacity planning; no off-chain deal can replace the on-chain match.
Next — Lease — the match becomes an enforceable agreement. Three ways to buy
What the tenant does
Holds a lease that binds the provider, the price and the funded escrow account.
What the provider does
Routes the matched request into its control plane and backend to provision the service.
Becomes protocol state
A Lease binds one tenant, one provider and one escrow account; lifecycle state is correlated back to it.
Stays off-chain
The provider daemon calls Waldur or a provider integration; the backend creates the resource. The chain does not provision infrastructure.
Next — Usage — the service runs and is metered. How the marketplace works
What the tenant does
Consumes the service and can observe resource state through the provider's console.
What the provider does
Meters per-workload consumption on a scheduled cadence, screens anomalies, and submits signed batches to the chain.
Becomes protocol state
Signed UsageRecord entries are submitted against the lease and reconciled against platform metrics.
Stays off-chain
Metering, anomaly detection, retry and reconciliation run inside the provider daemon.
Next — Settlement — validated usage becomes payment. Escrow & settlement
What the tenant does
Can raise corrections during the dispute window; unspent escrow returns when the deployment closes.
What the provider does
Receives the agreed amount from escrow at the full agreed amount.
Becomes protocol state
Settlement converts validated records into priced line items and releases escrow.
Stays off-chain
Provider and project reporting views remain operational; they do not override the lease price or authorise payout.
Next — Renewal, scale, or close — any remaining escrow returns to the tenant. Escrow & settlement
Default · listed price
Name the listing. Buy at the published price.
Pick a provider's offering and plan from the catalogue and order it directly. The order names that exact listing, matches without a bidding window, and becomes a lease backed by escrow. This is the default path — and the right one for most purchases.
- published plans
- known provider
- predictable price
- SaaS seats
- managed services
- fixed catalogue products
Opt-in · price discovery
Post what you need. Providers compete on price.
Open your order to a bidding window and let eligible providers offer prices. Accept a bid yourself, or let the matching engine take the best-ranked offer when the window closes. Use it for fungible capacity where competition should set the price.
- price discovery
- flexible provider choice
- custom compute requirements
- larger workloads
- Provider A$1.42 / GPU-hr
- Provider B$1.29 / GPU-hr · selected
- Provider C$1.51 / GPU-hr
Attribute matching
State the requirements. Get matched to eligible listings.
Instead of naming a provider, describe the category, region, minimum specifications and maximum price. The engine filters to eligible listings and matches deterministically within your cap — request-for-quote semantics without the negotiation round-trip.
- policy-driven sourcing
- region constraints
- hardware requirements
- compliance and attestation filters
- Region = AU
- GPU ≥ A100
- Confidential = required
- Price ≤ cap
| Path | Direct | Open bid | Selector |
|---|---|---|---|
| Provider chosen by | Tenant | Market / tenant | Requirements |
| Price | Listed | Competitive | Eligible listing |
| Wait for bids | No | Yes | No |
| Best use | Known product | Price discovery | Fit / attributes |
Table scrolls horizontally on narrow screens.
- GPU VM
- Managed Kubernetes
- Managed database
- HPC job
- Software plan
- Support service
- Custom listing
Metered consumption where the service is metered; the agreed component where it is fixed.
After the dispute window, at the full agreed amount. Unspent escrow returns to the tenant.
Stage 1 — Order: describing what you need
A tenant can begin from a catalogue offering: a private cloud, storage service, VM, accelerator-backed service, or a provider's fully custom listing. Where a workload deployment is needed, x/deployment carries its declarative description in groups with CPU, memory, storage, accelerator and placement requirements.
The order is the demand signal: a structured, on-chain request that either names one offering at its listed price or opens demand providers can bid on. Escrow is funded at this point, so the market can see the demand is backed by real budget.
Stage 2 — Match: three acquisition paths
Direct orders resolve immediately against the named offering — no waiting, no auction. Open orders collect bids from provider daemons, which price the work against their configured strategy; valid bids must satisfy the order's resource and attribute requirements.
The tenant can accept a bid, or let the matching engine auto-resolve to the best-ranked offer when the bidding window closes. Selector orders name no provider at all: category, region, minimum specifications and a maximum price are resolved deterministically within that cap.
- Direct — published price, immediate match, no bidding window.
- Open bid — competing on-chain bids, accepted or auto-resolved.
- Selector — request-for-quote semantics without the negotiation round-trip.
Stage 3 — Lease: the match becomes a contract
The match becomes a lease: the on-chain contract binding one tenant, one provider, and one escrow account. The Waldur integration passes the agreed service into the appropriate fulfilment path — Kubernetes for containerized services, a scheduler adapter (SLURM, MOAB, Open OnDemand) for HPC jobs, or a provider-defined integration for a custom offering.
Off-chain communication between tenant and provider — delivering the workload manifest, fetching status — is mutually authenticated with TLS certificates anchored on-chain by x/cert.
Stage 4 — Usage: metering with signatures
The provider daemon meters per-workload consumption on an hourly cadence. Metrics become usage records, screened by anomaly detection and submitted in signed batches (MsgRecordUsage) with retry and backoff.
Reconciliation runs alongside — cross-checking reported usage against platform metrics on a six-hour default interval and flagging discrepancies above threshold. A record that never gets signed never becomes billable.
Stage 5 — Settlement: usage becomes payment
The settlement module (x/settlement) validates each record against its lease and converts it into priced line items. Records sit in a 24-hour dispute window where either party can raise corrections; after it closes, line items settle against the lease's escrow.
Funds transfer to the provider at the agreed lease price at the full agreed amount — with no protocol deduction. When the deployment closes, unspent escrow returns to the tenant.
Fulfilment
The chain does not provision infrastructure. After the lease binds tenant, provider and escrow, the provider daemon routes the matched request into the provider control plane, which invokes the configured backend.
Provision, resize, suspend, resume and terminate are asynchronous. Each outcome returns as an authenticated callback before it becomes correlated lease state. Operational dashboards remain views; protocol payout follows the lease.
Why this design holds up
Each stage hands off with a verifiable artifact: orders backed by escrow, matches validated against requirements, leases binding funds, usage signed and disputable, settlement rule-bound. VEID is optional for general participation; any provider-set proof requirement should be disclosed on the individual offer before an order.
Asked about how the marketplace works
Where do I start — Waldur or the chain?
Either. Tenants can begin from a Waldur offering and buy it outright at its listed price; the protocol client creates the verifiable market order and the lease is correlated with a Waldur order for fulfilment. Open bidding is available when you want price discovery instead, and selector orders match eligible listings by attribute and price cap. Match selection and escrow never leave the chain.
Who sets the price?
The offering's published price for direct orders; competing providers for open bid orders; the best eligible listing within your cap for selector orders. Bids must satisfy the order's resource and attribute requirements, and multiple bids against one order is the price-setting mechanism for that mode — competition per order, not per contract cycle.
What happens when usage numbers are disputed?
Records sit in a 24-hour window where either party can raise corrections. Disputes escalate through support intake, and to fraud handling where misconduct is alleged — while anomaly detection screens records before they ever reach the chain.