How the VirtEngine marketplace works

A tenant can begin from a Waldur marketplace 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.

Creating the deployment emits orders into the market module (x/market). An order is the marketplace's demand signal: a structured, on-chain request that any qualifying provider can compete for. The tenant also funds an escrow account at this point, so the market can see the demand is backed by real budget.

Provider daemons — the off-chain agents operators run inside their datacenters, clouds, and HPC facilities — watch the chain for open orders that match their registered capacity and attributes. When one appears, the daemon prices it against the operator's configured strategy and places a bid.

Bids are on-chain objects too: priced offers that must satisfy the order's resource and attribute requirements to be valid. Multiple providers bidding against the same order is the mechanism that sets prices — competition per order, not per contract cycle.

The tenant accepts a winning bid and the match becomes a lease — the on-chain contract binding one tenant, one provider, and one escrow account. The VE–Waldur API passes the agreed service into the appropriate fulfilment path. That can be 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.

While the workload runs, the provider daemon meters per-workload resource consumption on an hourly cadence. Metrics are processed into usage records, screened by anomaly detection, and submitted to the chain 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.

The settlement module (x/settlement) validates each usage record against its lease and converts it into priced line items. Records sit in a 24-hour dispute window during which either party can raise corrections; after it closes, line items settle against the lease's escrow.

Funds transfer from escrow to the provider at the agreed lease price. There is no protocol commission or platform fee on marketplace settlement; low validator transaction fees apply only to the on-chain messages that create, operate and settle the lease. When the deployment closes, any unspent escrow returns to the tenant. No invoices were created, and no one had to trust the other side's accounting.

Each stage hands off to the next with a verifiable artifact: orders backed by escrow, bids validated against requirements, leases binding funds, usage signed and disputable, settlement rule-bound. Both counterparties are VEID-verified before any of it starts — the marketplace's guarantees are protocol properties, not platform policies.