Swiss Subnet and Cloud Engines

The operator

Swiss Subnet AG is a Swiss corporation, registered at Gotthardstrasse 3, 6300 Zug. It assembles and coordinates Cloud Engines and holds the contractual relationship with both the client and the node providers whose hardware carries the engine.

Two distinct parties therefore stand behind any engine:

Party	Role	Bound by
Swiss Subnet AG	Assembles the engine, coordinates operations, holds the client relationship	Contract with the client
Node provider	Owns and operates one physical machine in the engine	Node Provider Agreement with Swiss Subnet AG

What a Cloud Engine is

A Cloud Engine is a replicated computer: a group of physical machines that each hold a full copy of the same state and execute the same instructions in the same order. Because every machine computes the same result independently, a caller can rely on the output without trusting any single machine — and no single operator can alter stored state out of band.

An engine is built from a minimum of four nodes, following the Byzantine fault-tolerance requirement of 3f + 1 machines to tolerate f faulty ones. At the minimum size of four, one node may fail, be compromised or behave maliciously without the engine losing correctness or availability.

An engine is a network configuration rather than a fixed set of machines. The hardware underneath can be replaced while the engine keeps running, which is what makes both hardware refresh and capacity changes possible without downtime for the hosted application. See Cloud Engine for how that plays out in practice.

Relationship to the Internet Computer

A Cloud Engine runs the Internet Computer Protocol. It is the same protocol that powers the public Internet Computer, deployed as a private instance rather than as a shard of a public network. The practical consequences:

• Protocol properties are inherited. Consensus, replication, the canister execution model and the resource limits documented in Limitations come from the protocol and are published by the DFINITY Foundation. Some of those limits additionally depend on how large an engine is provisioned: an engine with 500 GiB of replicated storage cannot hold 2 TiB, whatever the protocol itself permits.
• Composition is not. Who runs the nodes, where they stand, how many there are and what hardware they use are decisions of the engine’s operator, not of a public governance process.
• Software written for one runs on the other. An application built for the public Internet Computer runs on a Cloud Engine with little modification, and the reverse holds too.

Dependency on ICP mainnet

Creating an engine depends on the public Internet Computer today. Engines are registered in the NNS registry and creation runs through the public ICP system subnets. An engine that is running continues to serve its application, but the platform is not today self-contained: engine records, and the authority over them, live on ICP mainnet.

Planned: a separate registry for Cloud Engines, holding engine records outside the NNS, which is what would make an engine independent of ICP mainnet. Stated as intention; see Limitations and Governance for what it changes.

Protocol version. An engine runs the version pinned for it in the registry. Today the NNS decides when that pin changes — the same route every other change to a running engine takes.

Planned: protocol version upgrades become opt-in rather than imposed — see Governance.

Node providers

Replication only buys independence if the machines are genuinely independent. Node providers are separate legal entities, individually contracted, each operating hardware they own or lease.

Thirteen node providers are contracted today, all fully independent of one another: no common ownership, no parent company shared between them. An engine draws its nodes from that pool, so the four machines of a minimum-size engine are run by four unrelated companies.

Every node provider is bound by a Node Provider Agreement with Swiss Subnet AG. The obligations relevant to a client evaluating the platform:

Obligation	Requirement
Node availability	99% per calendar month, measured as operational, online, responsive and able to process transactions
Response time	24 hours to respond to and begin acting on a Swiss Subnet request, including redeployment and hotfixes
Physical access	Provider must be able to reach the machine physically at its data centre within the response time
Remote access	Provider must be able to reach the machine remotely within the response time
Node provider requirements	Compliance with the requirements defined by ICP on-chain governance (NNS), as published on the ICP wiki
Data protection	Compliance with the Swiss Federal Act on Data Protection (FADP) and, where applicable, the EU GDPR
Governing law	Swiss law, exclusive jurisdiction of the courts of Zug

Failure to meet the availability or response requirements is grounds for immediate termination without a cure period.

All node machines are located in Switzerland. Node providers are legal entities contracted under Swiss law; the current agreement template admits entities established in Switzerland or Liechtenstein. Going forward, providers will be Swiss entities only — no Liechtenstein and no EU entities are being contracted, so that the operator’s seat as well as the machine sits in Switzerland.

Under the agreement, where a node provider processes personal data on behalf of Swiss Subnet, the provider is the processor and Swiss Subnet AG the controller. Client organisations should map this against their own controller role; see Data Storage and Locations.

Jurisdiction and vetting

Node provider identities are known and vetted rather than pseudonymous, and the relationship is contractual and enforceable under Swiss law. This is the substantive difference from a public permissionless network, where an operator is an address rather than a counterparty.

Identities are disclosed rather than confidential. The contracted companies are publicly known, so a client can see which entities carry their engine and assess them directly instead of taking the independence claim on trust.

Vetting consists of three checks before a provider is contracted:

Check	What is established
Company register	The provider is a real, registered legal entity in the jurisdiction stated above
Beneficial ownership	Who ultimately controls the provider, which is what makes the independence claim between providers checkable
Site review	The machine is housed in a genuine data centre facility, not in a residence or an improvised location

The vetting is not currently documented in a form a client’s compliance function can review. The checks are carried out, but there is no vetting report or attestation to hand to an auditor. A client whose process requires evidence of operator due diligence has to raise that with Swiss Subnet AG directly.

Governance

Today, changes are made through ICP on-chain governance proposals. At network level a Cloud Engine is still a subnet, and the NNS holds the same powers over it as over any other subnet: it can replace the nodes and it can delete canisters. Protocol and GuestOS upgrades, node replacement and configuration changes all reach a running engine through that route. Neither Swiss Subnet AG nor the client controls it unilaterally.

Change to a running engine	Initiated today	Planned
Protocol / GuestOS upgrade	NNS proposal	Engine owner, opt-in per upgrade
Node replacement	NNS proposal	Engine owner
Configuration change	NNS proposal	Engine owner
Canister deletion	NNS proposal	Not possible once the registry moves

A client has no veto and no deferral right today. An upgrade that passes as an NNS proposal reaches the engine regardless of the client’s timing preferences. Planned: GuestOS upgrades become opt-in for the Cloud Engine owner, so that the owner decides whether and when their own engine takes an upgrade — a deferral right, and in effect a veto over that upgrade for that engine.

What the separate Cloud Engine registry changes. The planned registry — listed in Limitations — holds engine records outside the NNS. Once an engine’s record no longer lives in the NNS, the powers above fall away with it: no node replacement, no canister deletion by on-chain governance, and change authority sits with the engine owner instead. This is stated as intention; no date is committed.

Node provider requirements are those defined by the NNS today, as the Node Provider Agreement above records. The Agreement also allows Swiss Subnet AG to define them itself instead, which is part of the same reduction in NNS dependency; no date is attached to that step. It implies no change of hardware: for the foreseeable future, engines run on the Gen 2 nodes already in service.