Learn · Reference
Marketplace glossary
Definitions for the terms used across the marketplace pages, written from the protocol repository and Waldur's published marketplace model. Every term has a stable anchor so it can be linked directly.
Marketplace & catalogue
The commercial surface: what is listed, who lists it, and how it is described.
- Provider
- An independent operator that lists capacity or services in the catalogue and fulfils leases on its own infrastructure. Providers register on-chain with attributes, region and identity, and run the provider daemon.
- Tenant
- The buyer: an organisation or individual that orders services through the marketplace and operates the leased resources. Tenants are identity-gated before matching, exactly as providers are.
- Offering
- A listed product or service a provider publishes. On-chain it is the offering object orders can name; in Waldur it is the catalogue item users see. The provider daemon keeps the two correlated.
- Plan
- A purchasable variant of an offering — the pricing and configuration a tenant chooses, such as hourly, monthly, reserved or per-seat. Waldur models plans under offerings; VirtEngine records the agreed commercial terms in the lease.
- Component
- A measurable billing dimension of a plan — GPU-hours, vCPU-hours, RAM GB-hours, storage GB-months, seats, or a provider-defined unit. Providers meter components; settlement prices them against the lease.
- Limit
- A cap on a component, such as a maximum number of vCPU-hours or a storage ceiling. Limits keep a plan's exposure bounded and are visible to the tenant before ordering.
- Custom offering
- A provider-defined listing beyond the standard service models: scripted provisioning, consultancy hours, remote catalogue items or bespoke bundles. Custom offerings use order forms, approvals and provider-defined components while keeping the same lease and settlement guarantees.
- Resource
- The thing that actually exists after fulfilment — a virtual machine, cluster, database, entitlement, storage bucket or service engagement. The provider's backend owns the resource; VirtEngine records the lease it belongs to.
- Allocation
- The provider-side assignment of capacity to a tenant — for example an HPC allocation on a scheduler or a quota grant in a private cloud. Allocation state is reconciled back to the chain as lease and lifecycle state.
- Backend
- The provider system that creates and operates the sold service: OpenStack, VMware, Kubernetes/Rancher, a scheduler, a storage system, an entitlement service or a custom integration. VirtEngine does not provision backends; the provider's integration does.
- Processor
- Waldur's term for the plugin or integration that fulfils an order against a backend — for example a cloud processor, a site agent or a custom scripted processor. The processor performs the work; Waldur tracks the order and resource state around it.
Orders, leases & settlement
The protocol objects an order passes through, and the money rules attached to them.
- Order
- A structured, on-chain request for a service: it names an offering at its listed price, or opens demand that qualifying providers can bid on. An order is backed by escrow so the market can see real budget behind the demand.
- Direct order
- An order that names one specific offering and matches at its published price without a bidding window. The default acquisition path and the right one for most catalogue purchases.
- Bid
- A priced offer a provider daemon places against an open order. Bids are on-chain objects that must satisfy the order's resource and attribute requirements to be valid. The tenant can accept one, or the matching engine resolves the best-ranked bid when the window closes.
- Selector
- An acquisition mode where the tenant names no provider: category, region, minimum specifications and a maximum price are described, and the engine resolves the best eligible listing deterministically within that cap.
- Match
- The protocol step that resolves an order to a provider: a direct purchase at a listed price, an accepted bid, or an attribute match against eligible listings. Match selection happens on-chain.
- Lease
- The on-chain agreement binding one tenant, one provider and one escrow account after a match. Fulfilment, metering and settlement all reference the lease, which is what makes the relationship enforceable rather than merely displayed.
- Escrow
- Funds committed by the tenant against a lease. Escrow is provably funded but provably not yet transferred: it moves only under settlement rules, and unspent balance returns to the tenant when the deployment closes.
- Usage record
- A signed measurement of consumption for a lease, submitted by the provider daemon on a scheduled cadence. Records are screened by anomaly detection, pass through a dispute window, and are validated against the lease before pricing.
- Settlement
- The conversion of validated usage records into priced line items and the release of the agreed amount from escrow to the provider under the governed settlement fee policy.
- Dispute window
- A period (24 hours by default) during which either party can dispute or correct a usage record before it settles. Disputed records escalate through support intake, and to fraud handling where misconduct is alleged.
Identity & trust
How the market knows who is on the other side of a lease.
- VEID
- Verifiable Electronic Identity: the protocol's privacy-preserving identity layer. Encrypted identity evidence is scored by validators by consensus, and users prove facts about the result with zero-knowledge proofs rather than revealing documents.
- Audit
- Auditor-signed provider attributes recorded on-chain — certifications, compliance evidence and verified operational claims that tenants can filter on when choosing a listing.
- Benchmark
- Measured hardware performance data published by a provider. Benchmarks let tenants compare capacity on observed results rather than specification claims.
- Attestation
- Cryptographic evidence that hardware or software is what it claims to be — used for confidential-compute enclaves and device integrity. Attestation results can be required as listing attributes before a match.
- mTLS
- Mutually authenticated TLS: both sides of an off-chain connection present certificates. VirtEngine anchors certificates on-chain (x/cert), so manifest delivery and status calls between tenant and provider are mutually authenticated.
- CID
- Content identifier: a hash-derived address for off-chain content such as workload manifests or evidence bundles. Where a manifest is referenced, the CID lets either side verify the bytes they received match what was agreed.
Waldur & delivery
The control plane, the bridge and the systems that actually run services.
- Waldur
- An independently developed open-source service-management platform: catalogue, organisations, projects, orders, resources, quotas, accounting and provider plugins. VirtEngine integrates with Waldur through the provider daemon; it does not own or replace it.
- HomePort
- Waldur's browser application: the self-service surface where users browse the catalogue, order, and manage resources, quotas and reporting inside their organisation and project boundaries.
- MasterMind
- Waldur's backend API and service layer. HomePort and integrations talk to MasterMind to manage offerings, orders, resources, accounting and provider plugins.
- Provider daemon
- The off-chain agent an operator runs. It watches protocol events, maintains offering and resource mappings, routes fulfilment into the provider's control plane, verifies signed callbacks, reconciles state and submits signed usage records.
How to use this glossary
Terms are grouped by area — marketplace and catalogue, orders and settlement, identity and trust, and the control plane. Each definition links to the page that explains it in full where one exists.
Where a term belongs to Waldur rather than VirtEngine, the definition says so and links to Waldur's official documentation.
Technical detail
Protocol objects such as orders, bids, leases and usage records are defined at message level in the module reference and the external technical documentation.
Asked about marketplace glossary
Where are protocol objects defined precisely?
In the module reference and the external technical documentation, which document messages and state at implementation level.
Which terms are Waldur's rather than VirtEngine's?
Offering, plan, component, limit, resource, processor, HomePort and MasterMind come from Waldur's marketplace model; the glossary notes the distinction where it matters.