Learn · Catalogue

Anatomy of a marketplace listing

A listing is a contract-shaped description: who provides, what is delivered, how it is measured, what it costs, and what evidence supports it. This guide reads a listing card field by field — and shows how the card stays connected to the protocol object behind it.

Shelves in a library, looking up through the stacks.
A card is a structured agreement, not a brochure.

Figures

IaaS

Illustrative example

General Purpose VM

Example Provider

Sydney · AU

  • 4 vCPU
  • 16 GB RAM
  • 200 GB NVMe

Billing components

  • vCPU-hour
  • storage GB-month
  • audited
  • benchmarked

$0.06 / vCPU-hour

Order

Identifier mapping

  • VirtEngine offering_id ve:offering:…
  • Provider daemon mapping persisted cross-reference
  • Waldur offering_uuid catalogue item users see

Each numbered note maps to a part of the card. The listing is illustrative; the structure is what the protocol and the catalogue agree on.

  1. Provider

    The independent operator that publishes and fulfils the listing. Identity, region and attributes are protocol state.

  2. Category

    Where the listing sits in the catalogue — IaaS, PaaS, SaaS, HPC, storage, managed or custom.

  3. Offering

    The product itself. On-chain it is the offering an order can name; in Waldur it is the catalogue item.

  4. Plan

    The purchasable variant: hourly, monthly, reserved or per-seat, with its own pricing and limits.

  5. Component

    A measurable billing dimension — GPU-hours, vCPU-hours, storage GB-months, seats, or a provider-defined unit.

  6. Limit

    The cap on a component. Limits keep exposure bounded and are visible before ordering.

  7. Attribute

    Machine-readable claims such as audited, benchmarked, attested or confidential — usable as match filters.

  8. Region

    Where the service is delivered. Region is a first-class selector input and a display property on the card.

  9. Backend

    The provider system that actually fulfils the listing — OpenStack, VMware, a scheduler, an entitlement service or a custom integration.

  10. Price

    The published price for direct orders; bids and selector results are priced by their own rules.

  11. Order field

    Extra information the provider needs at order time, such as a project code, public key or region preference.

  12. Audit / benchmark

    Independent evidence attached to the provider or the offering — auditor-signed attributes and measured hardware performance.

  13. Lifecycle

    Provision, resize, suspend, resume and terminate. The provider's control plane performs them; the lease stays correlated.

Every part of the card has a job.

Reading the card

The top of the card identifies the product and the provider: service type, title, provider name and region. These are not decoration — category and region are match inputs, and provider identity is verified state.

Components and limits

Components are the measurable dimensions the plan is billed on: GPU-hours, vCPU-hours, RAM GB-hours, storage GB-months, seats or provider-defined units. Limits cap them so exposure stays bounded.

A plan with components but no limits is still a plan; limits are what make consumption predictable before the order is placed.

Attributes, audits and benchmarks

Attributes are machine-readable claims: audited, benchmarked, attested, confidential. Auditor-signed attributes and published hardware benchmarks are evidence, not marketing — and both can be used as match filters.

Identifiers: from card to protocol object

An offering has an on-chain identifier. The provider daemon persists a mapping between that identifier and the corresponding Waldur offering, so a polished catalogue card never becomes detached from the protocol object it represents.

  • VirtEngine offering_id — the chain object an order can name.
  • Provider daemon mapping — the persisted cross-reference.
  • Waldur offering_uuid — the catalogue item users see and order.

Fulfilment is not on the card

The card describes what is sold, not how it is made. Fulfilment details live in the provider's plan and backend configuration: OpenStack, VMware, a scheduler, an entitlement service or a custom integration.

That is why two listings can look similar on the card and be delivered by completely different systems — and why the provider's implementation path is worth checking before ordering.

Asked about anatomy of a listing

What is the difference between an offering and a plan?

The offering is the product; the plan is the purchasable variant with its own pricing, components and limits.

Are benchmarks verified?

They are published performance records attached to the provider; audits are auditor-signed attributes. Both are on-chain evidence you can filter on.

x/benchmark module

Where do order fields fit?

They are the extra inputs a provider needs at order time — a project code, a public key, a region preference — defined by the plan and collected before fulfilment.

More questions → FAQ