For AI agents: Documentation index at /llms.txt

Skip to content
docs.internetcomputer.org

Cycles

Every canister runs on real hardware: nodes operated by independent node providers distributed across the world. Unlike a traditional cloud, there is no single company to bill: no AWS account, no credit card, no monthly invoice. Instead, the network handles payment at the protocol level. Canisters pay for their own compute, storage, and bandwidth using cycles. The network deducts cycles automatically as the canister runs. Anyone can top up a canister: the developer, another canister, a user, or an automated service. Users interact with apps for free, the same way they use any web service.

Cycles cover four resource categories:

  • Compute: executing instructions (update calls, timers, heartbeats)
  • Storage: Wasm heap memory and stable memory, charged per byte per second
  • Messaging: ingress messages from users, inter-canister calls, responses
  • Special features: HTTPS outcalls, threshold signatures, Bitcoin integration, EVM RPC

Query calls are free: they run on a single node, do not go through consensus, and are not charged.

Acquiring cycles

Section titled “Acquiring cycles”

Cycles are obtained by converting ICP tokens. The conversion happens through the Cycles Minting Canister (CMC) (rkp4c-7iaaa-aaaaa-aaaca-cai), a system canister that accepts ICP and mints the equivalent value in cycles at the current XDR exchange rate.

Once minted, cycles are held by principals via the cycles ledger (um5iw-rqaaa-aaaaq-qaaba-cai) and transferred to canisters to fund their operation. Cycles flow in one direction: they can only be burned (consumed by canisters), never converted back to ICP tokens.

For step-by-step instructions, see Acquiring cycles.

Cycles are pegged to XDR

Section titled “Cycles are pegged to XDR”

Unlike ICP tokens, whose price fluctuates with markets, cycles are pegged to the Special Drawing Right (XDR): a basket of currencies maintained by the IMF. 1 trillion (T) cycles = 1 XDR (approximately $1.30–$1.40 USD). This peg makes infrastructure costs predictable for developers regardless of ICP token price movements.

Pricing

Section titled “Pricing”

Compute

Section titled “Compute”

By default, canisters are scheduled for execution on a best-effort basis. The subnet schedules them when capacity is available. Canisters that need guaranteed execution can set a compute_allocation in their settings, expressed as a percentage of one execution core:

AllocationGuarantee
1%Scheduled at least every 100 rounds
2%Scheduled at least every 50 rounds
100%Scheduled every round

Compute allocation costs 10M cycles per 1% per second. Best-effort scheduling (0% allocation) incurs no idle allocation cost, but execution is not guaranteed under high subnet load.

Storage

Section titled “Storage”

Storage is charged per byte per second for both Wasm heap memory and stable memory. Storing 1 GiB for one year costs approximately 4T cycles (≈$5.40 USD, May 2025). The cost is the same whether the data is in heap or stable memory.

When a canister allocates new storage bytes on a subnet that is more than 750 GiB full, the system moves cycles from the canister’s main balance into a reserved cycles balance to cover future storage payments for those bytes. This reservation is non-transferable and grows linearly as the subnet fills toward its 2 TiB capacity.

Messaging

Section titled “Messaging”
Message typeCost
Query callFree
Ingress update (user → canister)1.2M base + 2K cycles/byte, paid by receiving canister
Inter-canister call260K base + 1K cycles/byte, paid by sending canister
Canister creation500B cycles (≈$0.68, May 2025)

Replication factor

Section titled “Replication factor”

Every canister is replicated across all nodes on its subnet. Costs scale with subnet size: a 34-node subnet charges 34/13 times the base rate compared to a 13-node subnet. Choosing a 13-node subnet minimizes cost; 34-node subnets offer higher replication and security for sensitive workloads.

How charging works

Section titled “How charging works”

Each resource category is metered and charged differently:

Memory is charged at regular intervals (not every consensus round). The protocol tracks total memory in use and deducts from the canister’s cycle balance periodically.

Computation is charged at the time the instructions execute. ICP counts the number of WebAssembly instructions processed while handling a message. There is an upper bound on instructions per consensus round. If a message exceeds this limit, execution is paused and resumes in the next round; the cycles consumed each round are charged at round end. This is the mechanism behind deterministic time slicing.

Messaging costs are charged to the sending canister. Ingress messages (user to canister) are charged to the receiving canister. Each inter-canister call has a fixed base cost plus a per-byte variable cost. The calling canister also prepays the maximum-size reply cost upfront; if the actual reply is smaller, the difference is refunded.

Special features (HTTPS outcalls, threshold signatures, Bitcoin API calls) charge the calling canister an additional amount on top of standard messaging costs. These features require extra protocol-level work and are priced accordingly.

Cycles ledger

Section titled “Cycles ledger”

The cycles ledger (um5iw-rqaaa-aaaaq-qaaba-cai) is an NNS-controlled canister on the uzr34 system subnet that provides a shared cycles balance for principals. It complies with the ICRC-1, ICRC-2, and ICRC-3 standards, so cycles can be transferred, approved, and spent using the same interfaces as any other token. An accompanying index canister (ul4oc-4iaaa-aaaaq-qaabq-cai) runs on the same subnet.

The cycles ledger replaces the old cycles wallet model: instead of each developer deploying and managing their own cycles wallet canister, everyone shares the same ledger. Cycles are credited to a principal ID and subaccount just like any ICRC token.

Cycles ledger architecture: the ledger interacts with the CMC and user canisters to provide deposit, withdraw, and canister creation

Key operations:

  • deposit: credits attached cycles to a given account (principal + optional subaccount). Minimum 100M cycles must be attached; the 100M cycle fee is deducted.
  • withdraw: sends cycles to a canister. The cycles are removed from the sender’s ledger balance.
  • withdraw_from: same as withdraw, but uses an ICRC-2 approval to draw from a different account.
  • create_canister: creates a new canister funded from the caller’s cycles ledger balance. Delegates to the CMC, which handles subnet placement.
  • create_canister_from: same as create_canister, but uses an ICRC-2 approval to draw funds from a different account.

Every state-changing operation (each block created) costs 100M cycles as a fee. The full interface specification is available in the cycles ledger reference.

The cycles ledger does not support calling arbitrary canisters with cycles attached, because open call contexts can cause the ledger to become stuck. Two patterns address this:

  • Top up the target canister first: if you control the canister, transfer cycles to it using withdraw or icp canister top-up, then let the canister attach cycles internally from its own balance. This is the preferred pattern for canisters you deploy and control.
  • Proxy canister: if you need to call a canister method with cycles attached from the CLI or an external agent, deploy a proxy canister using the proxy template and route the call through it. See Calls with attached cycles for the how-to.

Developer responsibility

Section titled “Developer responsibility”

Topping up: canisters burn cycles continuously for storage and on every update call. Developers must monitor balances and keep canisters funded. A canister that runs out of cycles freezes immediately and stops responding to all calls.

Freezing threshold: each canister has a configurable freezing threshold (default: 30 days of idle burn). If the cycle balance falls below this threshold, the canister is frozen before it can be deleted, giving developers time to top up. Increase this threshold for production canisters as a safety buffer.

Deletion: a frozen canister that is not topped up within the threshold window is eventually deleted by the network, along with all its data. Deletion is permanent and irreversible.

These responsibilities can be automated. Tools like CycleOps monitor balances and top up canisters automatically.

Cost predictability

Section titled “Cost predictability”

The XDR peg and flat per-resource pricing make ICP costs predictable:

  • No surge pricing: cycle prices are set by the NNS (ICP’s governance system) and change infrequently. There are no congestion fees.
  • No per-transaction fees for users: apps absorb all costs, like SaaS businesses absorb server bills.

The tradeoff is that developers must forecast and fund usage upfront rather than letting users pay as they go.

Section titled “Related”