One protocol.
Many classes of node.

Inside a cloud engine, every compute node replicates the same computations and the same memory pages. If one node is slower than its peers, then it might fall behind under load, and the engine will degrade to the performance of the node just above the bottom third. For this reason, cloud engines are required to be formed from nodes from the same class.

The class is a floor, not a ceiling. A provider can over-spec (a perf node may have 20 vCPU and 72 GiB rather than the minimum 16 / 64), but every other node in the engine will still only see perf capacity. Over-specing is a waste of money; under-specing would undermine the purpose of engines.

Today's catalog of classes has been kept deliberately small. To avoid fragmenting the compute node market, five standard node hardware classes have been defined. However, mechanisms exist for associations of node providers to add new classes and innovate.

The five classes above are the initial official set, hand-picked to cover the workloads we expect customers to arrive with. They are not immutable. As the network matures we will open class invention to node providers themselves.

A provider will be able to propose a new class with a distinct spec profile: perhaps a compute-optimized 2 GiB/vCPU tier, a GPU-accelerated tier for confidential AI inference, or a latency-optimized tier with specific network guarantees. Other providers and customers vote with supply and demand; the NNS promotes successful experiments into the official catalog and retires ones with no liquidity.

This is why the catalog is small today. A curated starting set keeps the network liquid while the community builds intuition for what additional classes would genuinely serve. The long-run equilibrium is an open market for classes, priced by providers, selected by customers, and standardized by use.