Glossary

Plain-language definitions for the terms used across the console and these articles.

Foundations

Engine. A cluster of replica nodes that runs your canisters. Every node in the cluster runs the same software and the same canister state; together they form a single trusted execution environment. You compose an engine by picking which nodes belong to it.

Replica node. A single node in the engine cluster. Each replica is a physical machine in a data center, owned by an independent node provider. Replicas run consensus to agree on every state change.

Canister. Your application: a bundle of WebAssembly code with its own persistent state. Every replica in the engine runs the same canister and keeps an identical copy of its state. A single engine can host many canisters.

Subnet. The underlying subnet that your engine runs on. The subnet ID is the unique identifier you provide to the ICP CLI when deploying applications.

Principal ID. A cryptographic identifier on the Internet Computer: the public key that represents an identity. A principal can be a user (from their Internet Identity), a CLI identity, or a canister. It is how access and administration is scoped, both in your organization and on the subnet.

Capacity

Node classes. Hardware tiers available in the marketplace: STD, PERF, HPERF, DENSE. Larger classes mean more vCPU, RAM, and NVMe per replica, which raises per-node capacity. The class is consistent across an engine: every replica shares the same hardware specification.

Query throughput. Queries are non-consensus reads: any single replica can serve them. Query throughput scales with the number of nodes multiplied by per-node capacity. More nodes means more parallel reads.

Update throughput. Updates go through consensus: every replica processes them in the same order. Adding more nodes raises fault tolerance, not write throughput. To raise update throughput, choose a larger node class.

Reliability

Byzantine fault tolerance (BFT). The number of compromised or offline nodes your engine can survive. With n replicas, the engine tolerates f failures where 3f + 1 is at most n. A minimum of 4 replicas is required to establish any BFT at all (f = 1).

Provider grouping. Replicas from the same node provider count as one for BFT purposes, because one compromised provider can affect every node they operate simultaneously. Seven replicas from two providers gives f = 0. Spread your selection across distinct providers.

Dispersion. How physically distributed your replicas are: how many data centers, countries, and continents they cover. Concentrated placement shares failure risks: a single facility incident, regional outage, or geopolitical event can affect every node at once.

Privacy

SEV-SNP (TEE). AMD SEV-SNP is a Trusted Execution Environment: replica memory is encrypted and integrity-protected even from the host machine. The platform cannot read or tamper with your canister state. Required for regulated workloads.

Money

Cycles. The digital fuel that powers computation on the Internet Computer. Storage, compute, and network all consume cycles. You pay by card via a processor, which converts your payment to cycles and credits them to your engine. Cycles are the underlying metering unit; you do not need to manage them directly.

Operating budget. How long the engine runs between top-ups. When the balance drops to your emergency balance, the engine freezes (canisters paused, data retained) until you top up. The longer you pre-fund, the less often you need to top up.

Emergency balance. When the operating budget runs out, the engine enters a frozen state: canisters are paused but code and data are preserved. The emergency balance keeps the engine alive in this state for the window you choose. After it runs out, the engine is permanently deleted by the network. The unspent emergency balance is refunded if you cancel the engine while it is still active.