Let’s begin with the term “cycles”.
What are Cycles?
According to the Internet Computer documentation, cycles are the fuel of the Internet Computer.
On the Internet Computer a cycle is the unit of measurement for resources consumed, including processing, memory, storage, and network bandwidth. Every canister has a cycles account that is charged for the resources it uses. The Internet Computer’s utility token (ICP) can be converted into cycles and transferred to a canister. Additionally, cycles can be transferred between canisters by attaching them to an inter-canister message.
This concept of cycles to power the Internet Computer is also known under the term “reverse gas model”. The reverse gas model of the Internet Computer operates differently from traditional blockchain models. Instead of users paying for transaction fees, developers provision canisters with cycles. These cycles are consumed as the canister executes operations, covering costs for processing, memory, storage, and network bandwidth. This model shifts the cost burden from end-users to developers who need to ensure their canisters are adequately funded with cycles to handle user interactions, thus providing a more predictable and user-friendly experience.
ICPs can always be converted to cycles based on the current price of ICP measured in XDR, following the convention that one trillion cycles correspond to one XDR.
XDR is the currency code for special drawing rights (SDR). SDRs are supplementary foreign exchange assets defined and maintained by the International Monetary Fund (IMF). Although SDRs are not a currency themselves, they represent a claim to a currency held by IMF member countries, which can be exchanged. The currencies basket consists of the following fiat currencies: Chinese yuan, Euro, Japanese yen, U.K. pound and U.S. dollar.
The relationship between cycles and XDR (special drawing rights) on the Internet Computer is that the price of cycles is fixed relative to the price of XDR. Specifically, 1 trillion cycles equal 1 XDR. This fixed relationship ensures that the cost of canister operations remains predictable and independent of the price fluctuations of ICP, the Internet Computer Protocol’s utility token.
The fixed price of cycles in terms of XDR is designed to provide stability. While the value of an ICP token is volatile, cycles are pegged to XDR. This pegging helps to ensure that the cost of resource consumption on the Internet Computer remains relatively stable, though not constant.
As of June 17, 2024, the exchange rate for 1 XDR = 1.317620 USD. Please note that the USD/XDR exchange rate may fluctuate over time.
That means that 1 trillion (T) cycles are 1_000_000_000_000 in numbers and 1 XRD = 1.317620 USD. Or 1 ICP corresponds to approximately 6.325 trillion cycles.
In the table below, you can see that the price per trillion cycles remains constant due to the fixed SDR/USD exchange rate. Even when the ICP price fluctuates, the price per cycle stays the same.
I provide a numerical and practical example of the costs involved: To create a canister it needs approximately 100_000_000_000 cycles (100 billion cycles) that corresponds to approx. 0,13 USD.
Note that the cycle prices mentioned here are calculated based on a 13-node subnet. On a 34-node (Fiduciary) subnet, the prices are slightly higher, e.g. 0,13 / 13 * 34 = 0,34 USD per canister creation.
In the context of the Internet Computer and its programming language Motoko, the underscore _ is used to group digits in numbers for better readability. This is a common practice in many programming languages.
For instance, 1_000_000 is the same as 1000000. The underscore doesn’t change the value of the number, it’s just a visual aid to make the number easier to read. In decimal number, digits are typically grouped by 3 (like 1_000_000 for one million), and in hexadecimal notation they are grouped by 4.
let billion = 1_000_000_000;
let pi = 3.141_592_653_589_793_12;
let mask : Nat32 = 0xff00_ff0f;
In this example above, 1_000_000_000 represents one billion, 3.141_592_653_589_793_12 represents the value of pi, and 0xff00_ff0f is a hexadecimal number.
Now that we have an understanding of cycles, let’s move on to how we can use them in practice.
During my participation in the Open Internet Summer I have created a drawing under the name: A Cycles Wallet - Cheat Sheet or how I use the Cycles Wallet.
In this document, I have outlined two different use cases for creating a canister in relation to cycles management:
- A multiple canister setup, e.g. for Frontend / Backend development.
- A single canister setup, e.g. for a static website.
Multiple Canister Setup
In use case one, the multiple canister setup e.g. for frontend / backend development, I have used a cycles wallet deployed to the European subnet to create and power new canisters.
For me, the most important takeaway is the understanding that the cycles wallet is a separate canister, and both the frontend and backend canisters are topped up with cycles from this cycles wallet canister. The frontend and backend canister run independently from the cycles wallet aka cycles wallet canister.
Everything begins with a developer identity (DI). From that identity, you obtain a principal identifier and a ledger account identifier, both of which are needed in this scenario.
The two steps for setting this up are summarised below.
Create an empty canister with a specific amount of cycles in ICP. These ICP tokens come from the ledger account identifier on the IC mainnet of the currently used DI. Ensure you have sufficient ICP in that ledger account identifier; if not, transfer some to it.
We have two commands for creating a canister:
- dfx ledger create-canister
- dfx canister create
In this context, we use the dfx ledger command to create a new canister on a specific subnet for a designated owner, with a specified amount of cycles based on an amount of ICP. The ICP amount will be automatically converted to cycles.
dfx ledger --network ic create-canister --amount 3 --subnet-type european q7d44-...-ijbtz-aqe
>>The wallet canister on the "ic" network for user "projectA" is "xxxx-...-aaaca-cai"
Install the cycles wallet source code. As the cycles wallet is a regular canister with specialised software - the cycles wallet source code - you need to install this source code in an additional step. For that, we use the dfx identity command.
dfx identity --network ic deploy-wallet xxxx-...-aaaca-cai
What happens now is that the dfx identity command links the current DI to this canister identifier which is the identifier of the cycles wallet canister we created earlier. The dfx identity command also installs the specific cycles wallet source code into that canister.
At this point, you have a cycles wallet, also known as a cycles wallet canister, running on the IC mainnet in the designated subnet. Note that all subsequent canisters utilising this cycles wallet canister will be deployed in the same subnet as the cycles wallet canister. Be aware of this fact. According to the documentation, the reason for this is performance.
Now you can use the command dfx deploy command to deploy your project to the IC mainnet.
Use the dfx deploy command to register, build, and deploy an application on the local canister execution environment, the Internet Computer, or a specified testnet. By default, this command deploys all canisters defined in the project’s dfx.json configuration file. This command simplifies the developer workflow by enabling you to run one command instead of running the following commands as separate steps:
dfx canister create --all
dfx build
dfx canister install --all
As you can see, in this case, the dfx canister create command is used to create the frontend and backend canisters. During this process, a default amount of cycles is transferred into these canisters from the linked cycles wallet canister.
I’m not entirely sure what the default amount of cycles is. I found a hint in the forum suggesting it might be 3 trillion cycles , whereas using the NNS for canister creation might provide 2 trillion cycles.
Keep in mind that you can control the amount of cycles by a separate —with-cycles option. This option specifies the initial cycle balance to deposit into the newly created canister. The specified amount needs to take the canister creation fee into account. This amount is deducted from the wallet’s cycle balance.
Single canister environment
The second use case represents a single canister application, e.g. a static website. For me, a perfect use case to bring the power of the Internet Computer on the ground and use it in real projects to replace traditional IT infrastructure. Especially for European citizens and companies it is important to have GDPR compliant and secure hosting possibilities.
In this example, I used the dfx ledger command to create a new canister in a dedicated subnet for a specified controller. The process is essentially the same as when creating the cycles wallet canister. However, in this case, instead of installing the cycles wallet source code, you install the application code for an asset canister.
This highlights that a cycles wallet canister is built on the same canister infrastructure as any other canister running on the Internet Computer.
On the cheat sheet, you will find all the needed steps to implement this scenario, as well as the URL to the deployed canister, which is still running on the Internet Computer at the following URL: https://tqqoy-uiaaa-aaaas-aaada-cai.icp0.io
Wrap up
The cycles wallet seems sometimes a little bit mysterious. However, it is definitely worth taking a closer look. Maybe that is the reason why there is a new concept in preparation, the cycles ledger.
I can draw two personal insights from this debate:
First, the cycles wallet is a separate canister that can hold cycles, and those cycles will be transferred to the application canister when needed.
Second, the price of cycles remains consistent as long as the SDR conversion rate remains unchanged.
