Research · ICP
The reverse-gas model
Last reviewed 2026-09-21Source: ICP Developer Docs — Cycles, cycle costs and canister settingsThe model is described here; per-operation prices are not quoted because they vary with subnet replication factor and are subject to change.
The canister-pays model
Every canister runs on real hardware operated by independent node providers distributed across the world. Unlike a conventional cloud, there is no single company to bill: no account, no card, no monthly invoice. The network handles payment at the protocol level. A canister pays for its own compute, storage and bandwidth using cycles, and the network deducts them automatically as the canister runs.
The consequence is that the end user never needs a token, a wallet or a signature to use an application. A visitor loads a page and clicks a button; the canister's balance absorbs the cost. The documentation frames this as the reason users interact with apps for free, the same way they use any web service. Anyone can top up a canister — the developer, another canister, a user, or an automated service — so funding is a separate concern from usage.
This is the inversion the term describes. On Bitcoin, a transaction fee is paid by whoever broadcasts the transaction, and the fee is what gets a transaction into a block. On the Internet Computer, the cost of executing a message is borne by the canister that receives it, and the user's role is to send the message rather than to fund it.
What cycles pay for
The documentation groups the charges into categories. Compute covers executing instructions, including update calls, timers and heartbeats. Storage covers both WebAssembly heap memory and stable memory, charged per byte per second. Messaging covers ingress messages from users, inter-canister calls and their responses. Threshold cryptography covers ECDSA and Schnorr signing and key derivation. External integrations cover HTTPS outcalls and the chain-specific services such as the Bitcoin integration.
Computation is charged as instructions execute. The network counts the WebAssembly instructions processed while handling a message, and there is an upper bound on instructions per consensus round. A message that exceeds the limit is paused and resumes in the next round, with the cycles consumed each round charged at round end. This is the mechanism behind deterministic time slicing, and it is why a long-running computation does not fail but instead spreads across rounds.
Query calls are the exception. A query is answered by a single replica without going through consensus, and the documentation lists query calls as free. That is a meaningful asymmetry: reading data costs the canister nothing, while writing it costs cycles. The cycles page covers the accounting unit itself, including how it is obtained and what happens when a balance runs low.
Compute allocation
By default a canister is scheduled best-effort: the subnet runs it when capacity is available. That is adequate for most applications and costs nothing when the canister is idle. A canister that needs a guarantee can set a compute allocation, expressed as a percentage of one execution core, which reserves execution slots on a fixed schedule.
The documentation gives the schedule in terms of rounds: a one percent allocation is scheduled at least every hundred rounds, two percent at least every fifty, and a hundred percent every round. The total allocatable compute capacity per subnet is bounded, so allocation is a scarce resource rather than a free setting.
Allocation is a rental, not a usage charge. The fee accrues with time and allocation percentage regardless of whether the canister actually executes, which increases idle consumption. That is the trade-off: a canister that reserves compute pays for the reservation even when it has nothing to do, and a canister that does not reserve compute may wait under load.
Ingress and inter-canister costs
An ingress message is a call from outside the network — a browser, a command-line tool, another service. The canister that receives it pays for its induction and execution. An inter-canister call is a message from one canister to another, and it is charged to the sender: the request, the response, and the instructions on both sides. A canister that fans out to many others therefore pays for the fan-out, which makes call topology a cost decision as well as an architectural one.
Some operations require cycles to be attached explicitly rather than deducted from a balance. The documentation lists canister creation, threshold signing, key derivation and HTTPS outcalls among the methods that fail if insufficient cycles are provided. In Rust the CDK attaches the required amount automatically; in Motoko the developer attaches it. The HTTP outcalls page covers the outcall case, where the cost depends on the request size and the maximum response size.
The honest summary is that the reverse-gas model moves the funding question from the user to the developer, and it does not make computation free. A canister that is popular costs its operator more than one that is not, and a canister that runs out of cycles stops serving update calls. The model changes who pays and when, not whether anything is paid.
Sources and references
The billing model, the charge categories and the compute-allocation schedule are described from the Internet Computer's own documentation. Prices are deliberately not quoted, because the documentation states that they vary with subnet replication factor and are subject to change.
- The canister-pays model and what cycles cover. ICP Developer Docs, Cycles: describes the charge categories, the compute-allocation schedule and deterministic time slicing.
- Per-operation costs and the free query call. ICP Developer Docs, Cycle costs: lists the operations, who pays for each, and the replication-factor dependence of the price.
- Compute allocation as a canister setting. ICP Developer Docs, Canister settings: documents the allocation range, the default best-effort scheduling, and the rental fee that accrues regardless of use.
Related reading
- Research HubEvery dataset on the site, with methodology and provenance.
- Altcoin ResearchAltcoins measured against Bitcoin: design intent, consensus, execution, scaling and market structure.
- The ETH-BTC Correlation RecordHow the correlation is measured, how it behaves across windows, and where it breaks down.
- The ETH/BTC RatioWhat the ratio measures, how to read its trend, and why it is not a forecast.
- ETH During Bitcoin Bull PhasesAssociation within a common market factor, and what co-movement cannot establish.
- ETH During Bitcoin Bear PhasesDrawdown depth and duration compared over identical windows, and the limits of the comparison.