Technology
How Internet Computer Canisters Work
A canister is the application unit of the Internet Computer — part smart contract, part backend server, part database. It holds both code and state, runs as WebAssembly, and is executed by a replicated group of nodes. This is the mental model you need to understand anything else on ICP.
August 16, 2026 · 7 min read
A canister is more than a smart contract
On Ethereum, a smart contract is logic without a home: the logic lives in bytecode, but the data usually lives in some other storage system. A canister bundles both. It contains WebAssembly code, its own state, and memory — all in one deployable unit.
Think of it as backend + persistent state + execution environment. A single canister can hold user records, file metadata, and application logic without ever reaching out to PostgreSQL, Redis, or S3.
What is inside a canister
Imagine an ICPay Cloud canister. It exposes methods like upload(), download(), delete(), and createBucket(). Beside the code, it keeps state: bucket metadata, file metadata, the file bytes, expiration dates, and the owner's principal.
- Code — compiled WebAssembly.
- State — the current values of every variable the code manages.
- Stable memory — persistent storage that survives canister upgrades.
- A balance of cycles — the fuel that pays for its own execution.
How your code runs
Canisters execute WebAssembly. You do not write Wasm by hand — you compile Motoko, Rust, or TypeScript (via Azle) down to Wasm, then deploy it. The path is:
- Source code in Motoko, Rust, or TypeScript.
- Compiled to WebAssembly.
- Deployed as a canister onto a subnet.
- Executed by every replica node of that subnet.
Because execution is deterministic, every replica computes the same result — that is what lets the network reach consensus on state without trusting any single node.
Canisters live on subnets
A canister is not deployed to one machine. It is deployed to a subnet — a group of independent nodes that collectively execute the canister. Each node runs the same computation; the subnet uses consensus to agree on the resulting state.
This is the hierarchy that matters:
- The Internet Computer is made of subnets.
- Each subnet is a group of nodes.
- Each node runs replicas of the same canisters.
The path of a single call
When your browser calls upload(), the request travels from the frontend to the canister on a subnet. Each replica executes the deterministic state transition. The subnet reaches consensus, and the agreed state becomes the new canister state. From the outside it looks like an ordinary API call that takes one to two seconds.
Read-only queries skip consensus entirely and return in about 100 milliseconds — and they cost no cycles. Updates go through the full replicated path. This split is why an app can look up a balance or search usernames instantly while writes settle in about two seconds.
Canisters pay their own bills
A canister holds a balance of cycles— the network's unit of computation. Every update call, byte of storage, and message burns a small amount. The developer tops the balance up, so users never pay gas. This is the reverse gas model, and it is why apps on ICP feel like ordinary websites.
Why this matters for wallets
For a custodial wallet like ICPay, the entire backend — users, balances, transfers, and cloud storage — runs inside canisters on a subnet. Sending ICP means the canister calls the ICP ledger directly in the same consensus round as your request. There is no separate server, database, or bridge to trust.
The same canister model powers ckBTC and ckETH through chain-key signatures, and it is the foundation of every other concept on this blog.