What is a decentralized cloud?

Five conditions separate the category from a directory of vendors with a payment form attached:

• Independent operators - each provider owns or controls its hardware and decides what to offer and at what rate.
• One description of capacity - listings expressed in a shared schema, so machines from different operators can be compared.
• Verifiable counterparties - identity checks on both sides before an order matches, rather than after a complaint.
• Escrowed payment - funds committed when the order is placed and released only under protocol rules.
• Signed usage - the meter's output attributable to the provider who produced it and open to challenge.

Drop any one of them and the system degrades into a broker with better marketing: someone ends up trusting a single party with the price, the meter and the money at the same time.

The gains are structural. Pricing is set by competition among operators rather than by one party's list. Capacity comes from many sources, so an outage, a quota or an account suspension at one provider is an incident rather than a stoppage. Workload placement becomes a choice that can be revisited, and the terms of a lease are legible before any money moves.

The costs are equally structural, and worth stating plainly. Hardware is heterogeneous, so portability between providers is work rather than a button. Capacity in different facilities carries different network paths. Support spans whoever ran the machine that hour. Performance cannot be assumed from a brand name when the brand is not supplying it. Decentralisation earns its place where those costs are smaller than the cost of depending on one operator - not everywhere.

Portability is the practical test of the category. A workload that can only run on one operator's proprietary services is rented rather than decentralised, because it cannot shift when price or availability changes. Workloads written against standard building blocks - containers, virtual machine images, ordinary object storage - keep that option open, and a deployment spec stating resources, region and accelerator class can be evaluated against any listing that satisfies it.

The limit is honest: portability is a property of how the workload was written, not something a marketplace can add afterwards. Providers differ in network path, hardware generation and locality, so a move may change performance as well as price. What protocol-level ordering removes from that decision is the renegotiation - the terms were published before the order, and the settlement works the same way on the next provider as on the last.

A decentralised cloud needs software that performs the roles a central platform would otherwise own. On VirtEngine that is a chain carrying marketplace, identity, economics and quality modules, a provider daemon that watches orders, bids, instantiates workloads and meters what they consume, and an open control plane through which providers publish their offerings. The architecture, module by module, is set out on the protocol page, and the operators who supply capacity are described under providers.

None of that is invisible plumbing. Because the rules live in code rather than in a platform's terms of service, both sides of a transaction can check what will happen to their funds and their data before agreeing to anything.

The commercial question a decentralised cloud must answer is how a buyer pays an operator they have never dealt with. Here the answer is procedural rather than reputational: both parties verify identity before matching, the tenant funds escrow when the order is placed, and the provider starts work against a balance it can see rather than an invoice it hopes will arrive.

From there the run follows the meter. Consumption is recorded in signed batches during the lease, each reading sits in a dispute window either side may use, and settlement converts the surviving readings into line items drawn from escrow - with whatever remains returning to the tenant. The provider does not have to be trusted with the price or the adjudication, because neither of those is its to decide.