Waldur Integration

The marketplace layer

Waldur is an open-source platform for managing hybrid cloud resources, service marketplaces and organizational hierarchies. In the VirtEngine architecture, it is the main marketplace and service-management integration: the self-service catalogue where providers can publish and users can discover more than a single kind of compute service.

The catalogue can include private clouds, storage, VMs, accelerator-backed compute and fully custom offerings defined by a provider. This matters because not every service is a Kubernetes deployment or an HPC batch job.

For Waldur installation, configuration and administration, use the maintained upstream Waldur documentation.

How Waldur and the protocol divide responsibilities

The VE–Waldur API connects Waldur’s catalogue and service-management model to the VirtEngine protocol. Waldur handles the user-facing catalogue, organization/project context, provisioning hand-off and service accounting. VirtEngine supplies the decentralized parts: VEID-gated participation, orders and bids, leases, escrow, signed usage and settlement.

After a listing is selected or matched, fulfilment can be handed to a Kubernetes deployment, an HPC scheduler such as SLURM, or a custom provider integration. Kubernetes and schedulers are execution targets — not the limit of the marketplace catalogue.

Who owns what

A non-deterministic service cannot run inside consensus, so the split is deliberate:

Concern	Owner	Why
Catalogue listings, orders, bids, leases, reservations, escrow	The chain	Must be deterministic and identical on every validator
Offering discovery, provider onboarding, service accounting, admin UI	Waldur	Rich, stateful, operator-driven
Provisioning execution (VM, cloud, HPC)	Provider daemon	Talks to real infrastructure
Metering reconciliation	Provider daemon vs. Waldur	Cross-checks two independent sources

Waldur offerings are mirrored on-chain as signed snapshots verified against a registered Waldur key, so every validator agrees on the same catalogue without performing network calls. Buying a Waldur-backed listing emits a durable command that an off-chain adapter executes in Waldur; the results flow back as signed, reconciliation-checked inputs.

This is what “Waldur integrated with the chain” means in practice: the marketplace semantics are protocol code that runs on validators, while the Waldur service runs at the edge. The chain is the source of truth for commercial state; Waldur is the operational and administrative plane. See Acquisition Pathways for the end-to-end view.

Reconciliation and metering

The provider daemon can cross-validate its metering against Waldur platform metrics:

waldur_reconciler:
  enabled: true
  discrepancy_threshold: 10.0  # percentage
  auto_correct: false
  auto_correct_threshold: 5.0

The reconciler compares provider-side sources against Waldur-side sources per metric — container metrics vs. component usage for CPU/memory, volume stats vs. resource limits for storage, NVIDIA metrics vs. component usage for GPU — and feeds the discrepancy-handling policy described in Escrow & Settlement.

This keeps a useful reconciliation path between the marketplace surface and the protocol’s signed usage and settlement records.

Migration guidance

There is no automated migration from every existing cloud platform into this architecture. A practical path:

Inventory legacy workloads (VMs, containers, apps) and their storage.
Re-express workloads as protocol deployments (Deploying Workloads) or HPC jobs.
If you operated the platform as a provider, evaluate becoming a marketplace provider — your capacity, and the operational skills the platform demanded, transfer directly.