Cycles: the stable accounting unit

Cycles are obtained by converting ICP tokens. The conversion happens through the Cycles Minting Canister, a system canister that accepts ICP and mints the equivalent value in cycles at the current XDR exchange rate. The rate is set by the network rather than by a market, which is what keeps the peg meaningful.

Once minted, cycles are held by principals through the cycles ledger, a system canister that provides a shared balance and complies with the ICRC-1, ICRC-2 and ICRC-3 standards. That means cycles can be transferred, approved and spent using the same interfaces as any other token on the network, which is what makes programmatic funding practical: a canister can hold a cycles balance and top up another canister without a human in the loop.

The ledger exposes operations for depositing attached cycles, withdrawing to a canister, and creating a canister funded from a ledger balance. The documentation notes a minimum deposit and a fee on deposit, which is worth knowing before designing an automated top-up that moves small amounts frequently.

A canister burns cycles continuously. Storage is charged per byte per second, so a canister with state burns cycles even when it receives no messages. Compute is charged as instructions execute. Messaging is charged per request and response. The result is an idle burn rate that a canister's status reports directly, which is the figure an operator watches when deciding how much to top up.

The documentation distinguishes the main balance from a reserved balance. When a canister allocates storage on a subnet above a certain usage level, cycles are moved from the main balance into a reserved balance, and a setting caps how large that reserve may grow. This is a mechanism for keeping a large canister solvent against its own storage commitments rather than a fee in the ordinary sense.

The reverse-gas model page covers who bears these charges and how compute allocation changes the profile. The short version is that the canister pays, and the burn is what makes that a real budget rather than a formality.

A canister does not fail the moment its balance reaches zero. The freezing threshold is a setting that defines how long a canister can survive on its current balance while idle. When the balance would fall below the estimated cost of running for that many seconds, the canister is frozen: it stops processing update calls but still serves query calls.

The default threshold is thirty days, and the documentation recommends a longer one for production canisters or those with large stable memory. The reason is that a frozen canister is recoverable — it can be topped up and resumed — while a canister whose balance is fully exhausted and whose threshold has expired is uninstalled. Its code and data are deleted, and only metadata such as the canister ID, controllers and settings remain.

That asymmetry is the practical lesson of the cycles model. The freezing threshold is not a warning light; it is the mechanism that converts a funding lapse from a permanent loss into a temporary outage. An operator who sets it generously is buying time to notice and react.