diff --git a/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles-ledger.md b/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles-ledger.md deleted file mode 100644 index 12d6eea..0000000 --- a/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles-ledger.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -learn_hub_id: 45034096457748 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/45034096457748-Cycles-Ledger" -learn_hub_title: "Cycles Ledger" -learn_hub_section: "Canister Smart Contracts" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# Cycles Ledger - -The [cycles ledger](https://github.com/dfinity/cycles-ledger) is a canister that simplifies the management of cycles. - -Instead of creating one or more cycles wallets, which the developer controls and manages, the cycles ledger is a global ledger under the control of the NNS. That is, the burden of managing cycles wallets is lifted. - -The cycles ledger complies with the [IRCR-1](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md), [ICRC-2](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-2/README.md), and [ICRC-3](https://github.com/dfinity/ICRC-1/tree/main/standards/ICRC-3) standards. As a result, the cycles ledger can also be integrated into applications and services that work with ICRC tokens. - -The cycles ledger (canister ID: `um5iw-rqaaa-aaaaq-qaaba-cai`) runs on the [uzr34 system subnet](https://dashboard.internetcomputer.org/subnet/uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe). The corresponding index canister (canister ID: `ul4oc-4iaaa-aaaaq-qaabq-cai`) runs on the same subnet. - -## Architecture - -The following figure depicts the involved components and their interactions at a high level. - -![](https://learn.internetcomputer.org/hc/article_attachments/45034096454164) - -The cycles ledger interacts with the cycles minting canister of the NNS and user canisters to provide the cycles ledger-specific functionality, such as transferring cycles as well as creating canisters with cycles. Concretely, it provides the following functionality: - - 1. `deposit` credits the sent cycles to the given principal ID. - 2. `withdraw` sends the given number of cycles to the given canister. - 3. `withdraw_from` sends the given number of cycles to the given canister taking the funds from a given account. - 4. `create_canister` creates a new canister using cycles. - 5. `create_canister_from` creates a new canister using cycles taken from a given account. - - - -The cycles balance of an account on the cycles ledger can be increased in the following ways: - - 1. Calling `deposit` with cycles attached. - 2. Calling `notify_mint_cycles` on the cycles minting canister (CMC) after having deposited ICP in a user-specific subaccount of the CMC's account on the ICP ledger. - 3. Calling `icrc1_transfer` or `icrc2_transfer_from` on the cycles ledger to transfer cycles. - - - -Due to the tight interaction with the NNS, in particular the CMC, the cycles ledger is controlled by the [NNS root canister](https://dashboard.internetcomputer.org/canister/r7inp-6aaaa-aaaaa-aaabq-cai). - -It is important to point out that the cycles ledger does not provide the functionality to call arbitrary other canisters with cycles. The reason is that open call contexts may cause the cycles ledger to become stuck. - -If this functionality is needed, a developer can still spin up a cycles wallet - and load it with cycles using the cycles ledger. - -## Technical Details - -As mentioned above, the cycles ledger complies with the ICRC-1, ICRC-2, and ICRC-3 standards, providing all the necessary endpoints. All endpoints are listed in the [Candid file](https://github.com/dfinity/cycles-ledger/blob/main/cycles-ledger/cycles-ledger.did). - -Every endpoint that causes a state change (in particular, the creation of a block) on the cycles ledger incurs a fee of **100 million cycles**. - -This fee is also levied for the cycles ledger-specific endpoints discussed next. - -### Depositing Cycles to the Cycles Ledger - -The function `deposit` provides the means to accept cycles from other canisters. - - - type DepositArgs = record { - to : Account; - memo : opt vec nat8; - }; - - type DepositResult = record { balance : nat; block_index : BlockIndex }; - - deposit : (DepositArgs) -> (DepositResult); - - -The parameters are the account, i.e., a principal ID-subaccount pair, that should be credited for this transfer, and an optional memo. The memo can later on be retrieved when querying the transaction at the returned block index. - -The cycles are attached to the call itself. The cycles ledger checks that at least 100 million cycles are attached and then increases the balance of the account by the number of attached cycles minus the fee. If fewer than 100 million cycles are attached, an error is returned. - -### Withdrawing Cycles from the Cycles Ledger - -The user invokes the function `withdraw` to instruct the cycles ledger to send the given number of cycles to the specified canister. Alternatively, the function `withdraw_from` can be called to make use of an ICRC-2 approval to get the cycles from an account with a different principal ID. - - - type WithdrawArgs = record { - amount : nat; - from_subaccount : opt vec nat8; - to : principal; - created_at_time : opt nat64; - }; - type WithdrawError = variant { - GenericError : record { message : text; error_code : nat }; - TemporarilyUnavailable; - FailedToWithdraw : record { - fee_block : opt nat; - rejection_code : RejectionCode; - rejection_reason : text; - }; - Duplicate : record { duplicate_of : nat }; - BadFee : record { expected_fee : nat }; - InvalidReceiver : record { receiver : principal }; - CreatedInFuture : record { ledger_time : nat64 }; - TooOld; - InsufficientFunds : record { balance : nat }; - }; - type WithdrawFromArgs = record { - spender_subaccount : opt vec nat8; - from : Account; - to : principal; - amount : nat; - created_at_time : opt nat64; - }; - type WithdrawFromError = variant { - GenericError : record { message : text; error_code : nat }; - TemporarilyUnavailable; - FailedToWithdrawFrom : record { - withdraw_from_block : opt nat; - refund_block : opt nat; - approval_refund_block : opt nat; - rejection_code : RejectionCode; - rejection_reason : text; - }; - Duplicate : record { duplicate_of : BlockIndex }; - InvalidReceiver : record { receiver : principal }; - CreatedInFuture : record { ledger_time : nat64 }; - TooOld; - InsufficientFunds : record { balance : nat }; - InsufficientAllowance : record { allowance : nat }; - }; - - withdraw : (WithdrawArgs) -> (variant { Ok : BlockIndex; Err : WithdrawError }); - withdraw_from : (WithdrawFromArgs) -> (variant { Ok : BlockIndex; Err : WithdrawFromError }); - - -The function `withdraw` has four parameters: the number of cycles to be sent, an optional subaccount, the principal ID of the targeted canister, and an optional timestamp to indicate the time when the request was created. - -Note that the sum of the transferred amount and the fee of 100 million cycles is deducted from the user’s account derived from the user’s principal ID and the provided subaccount (if any). The memo in the recorded burn transaction is an encoding of the principal ID of the targeted canister, which makes it possible for the user to verify that the cycles were sent to the right canister when querying the corresponding transaction. - -The effective fee of burn blocks of 100 million cycles is different from other ledgers, particularly the ICP ledger and standard ICRC ledgers, where the effective fee of burn blocks is 0. This is because withdrawing cycles is fundamentally different from just burning tokens. - -The function `withdraw_from` is almost identical but it makes it possible to specify a `from` account, i.e., the cycles are meant to be withdrawn from an account with a different principal ID. If the spender's principal ID plus optional subaccount has not been approved to retrieve at least the specified amount, an `InsufficientAllowance` error is returned. - -### Creating Canisters Using the Cycles Ledger - -A canister can be created by calling the `create_canister` function, which has four parameters: - - * An optional subaccount from which the funds are taken. If no subaccount is provided, the default account (with the all-zero subaccount) is used. - * An optional timestamp to mark the time when the request has been created. - * The number of cycles to be used. - * The canister creation arguments for the cycles minting canister. - - - -There is also the function `create_canister_from`, which in addition requires a `from` account. - - - type CreateCanisterArgs = record { - from_subaccount : opt vec nat8; - created_at_time : opt nat64; - amount : nat; - creation_args : opt CmcCreateCanisterArgs; - }; - - type CreateCanisterFromArgs = record { - from : Account; - spender_subaccount : opt vec nat8; - created_at_time : opt nat64; - amount : nat; - creation_args : opt CmcCreateCanisterArgs; - }; - - type CmcCreateCanisterArgs = record { - settings : opt CanisterSettings; - subnet_selection : opt SubnetSelection; - }; - - type CanisterSettings = record { - controllers : opt vec principal; - compute_allocation : opt nat; - memory_allocation : opt nat; - freezing_threshold : opt nat; - reserved_cycles_limit : opt nat; - }; - - type SubnetSelection = variant { - Subnet : record { - subnet : principal; - }; - Filter : SubnetFilter; - }; - - type SubnetFilter = record { - subnet_type : opt text; - }; - - type CreateCanisterSuccess = record { - block_id : BlockIndex; - canister_id : principal; - }; - - type CreateCanisterError = variant { - InsufficientFunds : record { balance : nat }; - TooOld; - CreatedInFuture : record { ledger_time : nat64 }; - TemporarilyUnavailable; - Duplicate : record { - duplicate_of : nat; - canister_id : opt principal; - }; - FailedToCreate : record { - fee_block : opt BlockIndex; - refund_block : opt BlockIndex; - error : text; - }; - GenericError : record { message : text; error_code : nat }; - }; - - type CreateCanisterFromError = variant { - InsufficientFunds : record { balance : nat }; - InsufficientAllowance : record { allowance : nat }; - TooOld; - CreatedInFuture : record { ledger_time : nat64 }; - TemporarilyUnavailable; - Duplicate : record { - duplicate_of : nat; - canister_id : opt principal; - }; - FailedToCreateFrom : record { - create_from_block : opt BlockIndex; - refund_block : opt BlockIndex; - approval_refund_block : opt BlockIndex; - rejection_code : RejectionCode; - rejection_reason : text; - }; - GenericError : record { message : text; error_code : nat }; - }; - - create_canister : (CreateCanisterArgs) -> (variant { Ok : CreateCanisterSuccess; Err : CreateCanisterError }); - create_canister_from : (CreateCanisterFromArgs) -> (variant { Ok : CreateCanisterSuccess; Err : CreateCanisterFromError }); - - -It is possible to specify canister settings, which are applied to the newly created canister. If not specified, the caller is the controller of the canister and the other settings are set to default values. - -It is further possible to target a specific subnet by specifying the principal ID of a subnet in the `subnet_selection` field. Alternatively, a subnet type such as "fiduciary" may be specified. If the subnet selection is left empty, the new canister is installed on a random subnet. - -Since only the cycles minting canister has the power to create canisters on arbitrary subnets, the cycles ledger simply invokes the function `create_canister` on the cycles minting canister, attaching the user-specified number of cycles to the call. If a canister is created successfully, the cycles ledger returns both the block index of the transaction that burned the cycles on the cycles ledger and the principal ID of the newly created canister. - -## Additional Information - - * [Developer documentation](https://docs.internetcomputer.org/defi/token-ledgers/cycles-ledger) - * [Chain-key tokens](https://learn.internetcomputer.org/hc/en-us/articles/34211397080980) - * [Tokens & cycles](https://docs.internetcomputer.org/building-apps/getting-started/tokens-and-cycles) - - - diff --git a/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles.md b/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles.md deleted file mode 100644 index bec2efe..0000000 --- a/.migration/learn-hub/how-does-icp-work/canister-smart-contracts/cycles.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -learn_hub_id: 34573913497108 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/34573913497108-Cycles" -learn_hub_title: "Cycles" -learn_hub_section: "Canister Smart Contracts" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# Cycles - -As they execute, canisters use resources in the form of memory, computation, and network bandwidth, and may also use certain special APIs. On the Internet Computer, all of these are paid for using a unit called _cycles_. Each canister maintains a local cycle account from which cycles are deducted as execution proceeds. - - * **Memory usage:** Charging for memory usage is straightforward. The protocol keeps track of the memory used by the canister and regularly charges the canister’s balance. This charging happens at regular intervals but not every round. - * **Computation:** Charging for computation occurs at the time the computation is performed. The canisters are instrumented with code that allows the Internet Computer to count the number of instructions executed while processing a message. There is an upper bound on the number of instructions that can be executed during a round. If this limit is exceeded, execution is paused and continued in a subsequent round, but cycles for the computation performed during any round are charged at the end of that round. - * **Bandwidth:** Charging for bandwidth occurs when a canister receives an ingress message from a user or sends a message to another canister. The protocol calculates the number of cycles required for the outgoing call, which includes a fixed cost and a variable cost based on the payload size. Additionally, the protocol deducts the cost of sending a maximum-size reply from the callee, as the caller pays for the reply. If the actual reply size is smaller, the difference in cycles is refunded to the canister when the reply arrives. - * **API calls:** Calls for [reading data from the Bitcoin blockchain](https://learn.internetcomputer.org/hc/en-us/articles/34211154520084), [making HTTP calls](https://learn.internetcomputer.org/hc/en-us/articles/34211194553492) to web servers, or creating [chain-key signatures](https://learn.internetcomputer.org/hc/en-us/articles/34209497587732) require additional payment charged to the canister's cycles balance. - - - -Canisters have a freezing threshold to prevent sudden deletion when they run out of cycles. When a canister’s balance falls below this threshold, it stops processing new requests but continues handling replies. If a canister runs out of cycles completely, it is uninstalled, deleting its code and state but retaining the canister id so it cannot be accidentally reused. - diff --git a/.migration/learn-hub/how-does-icp-work/sns/tokenomics.md b/.migration/learn-hub/how-does-icp-work/sns/tokenomics.md deleted file mode 100644 index 585c724..0000000 --- a/.migration/learn-hub/how-does-icp-work/sns/tokenomics.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -learn_hub_id: 34088279488660 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/34088279488660-Tokenomics" -learn_hub_title: "Tokenomics" -learn_hub_section: "SNS - Service Nervous System" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# Tokenomics - -Each SNS can be individually configured with [parameters](https://learn.internetcomputer.org/hc/en-us/articles/34142964565396) that define, among other things, the tokenomics of an SNS and the dapp that it governs. - -## What is tokenomics? - -A token is a digital asset on a blockchain. Tokenomics describes the economics of a token system on a blockchain. It is a game changer for decentralized autonomous organization (DAOs) compared to traditional apps running on a Web 2.0 infrastructure, because it enables the introduction of new incentive systems and use cases. Tokenizing a DAO allows, for instance, that anyone in the world can purchase a DAO's tokens and thereby contribute to the initial funding for the DAO. Moreover, tokens can be tranferred to early adopters and active users, which will help attract users. - -Tokenomics covers a wide range of topics, such as - - * How tokens are used. - * Allocation of tokens to participants of the DAO. - * Incentive mechanisms, e.g., providing tokens to early adopters. - * Development of token supply & demand over time. This includes creating new tokens (minting) and destroying tokens (burning). - - - -### Supply and demand - -The supply of a token is defined as the amount which token holders are willing to sell at a given price. Likewise, token demand is the amount of tokens which buyers are willing to buy for a given price. The following graph depicts the typical relationship between the supply, demand and price for an example good, which in our case could be a token priced in USD. - -![graph_supply_demand.png](https://learn.internetcomputer.org/hc/article_attachments/34146812547476) - -_(Image source: epthinktank.eu)_ - -Typically supply increases with increasing prices. For example, if the price of Bitcoin increases, typically more Bitcoin holders will be willing to sell at the higher price on the market. On the other hand, demand typically decreases with increasing prices. The intersection of the two curves determines the so-called equilibrium price, depicted by P_2 in the picture. - -How does it end up at the equilibrium price? - - * If P_1 > P_2: There is a surplus, i.e., more supply than demand. This creates downward pressure on the price. - * If P_3 < P_2: There is a shortage, i.e., more demand than supply. This creates upward pressure on the price. - - - -### Token emission over time - -A token emission schedule defines the rate at which new tokens are minted over time. The design of a token emission schedule is crucial for the success of a DAO. - -On the one hand, token emissions generate _liquidity_ of tokens. It should be ensured that sufficient amounts of tokens are available from the start so that people can participate in activities on the DAO. - -On the other hand, token emissions contribute to the token supply and hence influence the token price. Therefore, limiting the token emission schedule can have a positive impact on the token price. - -As a consequence, emission schedules are typically designed as follows: Initially, high amounts of tokens are issued to kickstart the token economy and to incentivize early participation. Over time, the marginal increase of the token supply goes down to limit the impact on the token price and to create scarcity, i.e., limited availability. - -### Token use cases - -Tokens can cover many different (potentially overlapping) use cases. For example - - * **Governance** : tokens may give holders the right to vote on proposed changes of a DAO. -To incentivize long-term thinking and commitment, systems often require staking of tokens. Staking means that token holders lock up a portion of tokens for a period of time. In exchange, stakers can earn rewards. - * **Currency** : a form of digital money that functions as a medium of exchange, unit of account, and store of value. - * **Operations** : facilitate operations on the blockchain, for example to cover resource consumption with fees to store information and execute transactions. - * **Decentralized Finance (DeFi)** : financial functions (e.g. lending, saving, trading) on a blockchain. DeFi tokens incentivize users to facilitate these functions, e.g. providing liquidity. - * **Social Finance (SoFi)** : tokens underpinning social networks. This includes the tokenization of popularity & reputation. For example participants could receive tokens if they have a lot of followers or views. - - - -## Tokenomics aspects to consider in a DAO - -In a DAO, (at least) the following aspects are important for tokenomics. - -### Token utility - -Define concisely for which use cases the token (or several tokens) of the DAO will be used (see prior section on use cases). In particular, it should be considered how the token(s) could be used for - - * Participation in governance. - * Rewarding active participation in services offered by the DAO. - * Rewarding contributions to the growth of the DAO. - - - -### Initial token allocation - -For the initial token allocation, i.e., defining which groups/accounts should receive how many tokens, consider the following main blocks. - - * **DAO treasury** : these are tokens which are at the disposition of the DAO. They can be used according to predefined rules defined in the protocol of the DAO or distributed ad-hoc subject to voting. For example, they might be used for community bounties & user rewards. - * **Decentralization swap** : distribution to the community via an initial or subsequent decentralization swap. - * **Seed funders** : distribution to funders (if you choose to have them) who invested in the project prior to the launch of the DAO. - * **Funding development team** : developers who created the initial version of the DAO. - - - -To facilitate a healthy DAO from the start the initial allocation should ensure the following. - - * At least as many tokens are allocated to the decentralization swap as granted to the seed funders and the funding development team (enforced at the time of SNS initialization). - * A significant part of the tokens is allocated to the DAO treasury, allowing the treasury to incentivize and reward users over time. - - - -### Voting power and decentralization - -The voting power should be distributed over many, independent entities such that there is not one single or a few entities that can decide by themselves how the DAO evolves. - -As mentioned above, participation in governance typically requires the staking of tokens for a certain amount of time. To incentivize long-term thinking and commitment, DAOs can provide more voting power to those token holders who stake for a longer time period. The configuration of the voting power should also consider the (initial) allocation of tokens, to ensure decentralization from the start. For example, it should be ensured that the voting power of the funding developer team is below 50% of the total voting power. - -Find more information on how to configure [voting rewards](https://learn.internetcomputer.org/hc/en-us/articles/34143058069396). - -### Are SNS tokens inflationary or deflationary? - -This depends on the specific SNS configuration. An SNS DAO can have both inflationary and deflationary pressures. - -Inflationary: - - * An SNS DAO can be set up to mint voting rewards for people who participate in governance (similar to ICP). - * An SNS DAO can mint tokens if voted on by SNS token holders. For example: a game mints 2% of total supply each year and distributes it among players. - - - -Deflationary: - - * SNS tokens are burnt for every transaction. - * Locking SNS tokens into neurons removes them from circulation. While not technically deflation, it acts as a deflationary pressure. - - - -## Additional resources - -On [this page ](https://wiki.internetcomputer.org/wiki/How-To:_SNS_tokenomics_configuration)you will find further material enabling teams to choose a suitable tokenomics set-up for their SNS DAO. It provides documentation links to SNS tokenomics key concepts as well as a SNS -tokenomics tool. - diff --git a/.migration/learn-hub/how-does-icp-work/tokens-governance/how-token-ledgers-work-on-the-internet-computer.md b/.migration/learn-hub/how-does-icp-work/tokens-governance/how-token-ledgers-work-on-the-internet-computer.md deleted file mode 100644 index 0a8fd7c..0000000 --- a/.migration/learn-hub/how-does-icp-work/tokens-governance/how-token-ledgers-work-on-the-internet-computer.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -learn_hub_id: 44969820125972 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/44969820125972-How-Token-Ledgers-Work-on-the-Internet-Computer" -learn_hub_title: "How Token Ledgers Work on the Internet Computer" -learn_hub_section: "Tokens & Governance" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# How Token Ledgers Work on the Internet Computer - -## - -The Internet Computer supports decentralized token ledgers that power balances, transfers, transaction history, and fees for both the native ICP token and other fungible tokens. This article explains how those ledgers work from a user perspective — what they are, how they record transactions, how fees work, and why different address formats exist. - -## What Is a Ledger? - -A **ledger** on the Internet Computer is a canister that defines who owns a token and permanently logs every transfer or balance change. - -Unlike a traditional bank book kept privately by one company, ledgers on the Internet Computer are: - - * **Publicly verifiable** — anyone can see transaction history through explorers. - * **Append-only** — once a transaction is recorded it isn’t removed. - * **Transaction-centric** — each change to balances goes into a permanent history. - - - -Ledgers ensure that token ownership and movement are transparent, reliable, and tamper-resistant. On the Internet Computer, there is no single global ledger. Each token is managed by its own ledger canister, which is controlled by the entity that deploys and governs that token. While multiple implementations exist, this article describes the DFINITY-maintained ledger suite, which is the most widely used and underlies the ICP - -## Two Kinds of Ledgers and Addresses - -The Internet Computer uses different ledger designs and address formats for different kinds of tokens. The key distinction users encounter is between the ICP Ledger and ICRC Token Ledgers. - - -### ICP Token Ledger - -The ICP Ledger is the native ledger used to manage ICP, the Internet Computer’s native utility token. ICP is the token you stake for governance, convert to cycles to pay for compute, or send to other users. The ICP Ledger uses a single, flat address format called an **AccountIdentifier** that uniquely identifies an account. - -### ICRC Token Ledgers - -While ICP itself is a token, it uses a dedicated native ledger. Most other fungible tokens on the Internet Computer use ledgers that follow the ICRC standard, which defines a common model for token balances, transfers, and addresses. - -These ledgers use a two-part account format: - - * A **principal** , which represents the identity of the holder (for example, a wallet). - * An optional **subaccount** , which lets a holder manage multiple internal accounts under the same principal. - - - -This account model gives wallets and services flexibility while keeping token handling consistent across different assets. - -## How Transactions Are Recorded - -Each ledger maintains its own append-only transaction log. Transfers and other token adjustments are added to the end of this log and never removed or rewritten. - -This design allows wallets and explorers to present a clear transaction history—similar to a bank statement—while enabling the history to be efficiently verified and cryptographically certified. - -As a result, users can reliably trace how their balance changed over time and independently verify past transactions. - -## -How Ledgers Scale: Archives and Indexes - -As ledgers grow over time, they accumulate a large number of transactions. To remain scalable and efficient, Internet Computer ledgers use additional components behind the scenes. - -### Archives - -Older transaction blocks may be moved into archive canisters. Archives were originally introduced to work around storage limits in individual canisters, and today they are primarily used to allow ledgers to scale beyond a single subnet. - - -From a user perspective: - - * The ledger still has a complete transaction history. - * Older transactions remain accessible through explorers and tools. - - - -Archiving is purely an internal optimization — it does not change balances, ownership, or the visibility of past transactions. - -### Index Canister - -Many ledgers are accompanied by an index canister, which is designed to make wallets and explorers faster and easier to use. - -The index organizes transaction data by address, allowing wallets to: - - * Quickly fetch all transactions related to a specific account. - * Display balances and history without scanning the entire ledger. - * Load transaction lists efficiently, even for long-lived accounts. - - - -While the ledger itself remains the authoritative source of truth, the index enables smooth user experiences in wallets and dashboards. - -### How This Fits Together - - * The ledger records transactions and balances. - * Archives store older transactions for scalability. - * The index helps wallets and explorers retrieve data efficiently. - - - -Together, these components ensure that ledgers on the Internet Computer remain transparent, scalable, and user-friendly — even as transaction history grows over time. - - -## Transaction Fees: What They Are and Who Pays - -Most token transfers on ledgers incur a small transaction fee. This helps deter spam and ensures that the cost of operating the ledger is shared by users making transfers. - - * The sender usually pays the fee when initiating a transfer. - * Fees are either burned (permanently removed from the total supply) or collected in a designated fee account, depending on how the token’s ledger is configured. - - - -Fees are generally small and predictable, and you’ll see them reflected in the final balance after a transfer. - -## What This Means for You - -As a wallet user or token holder on the Internet Computer, understanding ledgers helps you: - - * Know why and how your balance changes after transfers. - * Use the correct address format for different tokens. - * Trust that your transaction history is transparent and verifiable via explorers. - - - -Whether you’re sending ICP, receiving a stablecoin, or inspecting your transaction history, ledgers are the foundational technology that makes token ownership and movement trustworthy on the Internet Computer. - diff --git a/.migration/learn-hub/how-does-icp-work/tokens-governance/tokenomics.md b/.migration/learn-hub/how-does-icp-work/tokens-governance/tokenomics.md deleted file mode 100644 index f0c0057..0000000 --- a/.migration/learn-hub/how-does-icp-work/tokens-governance/tokenomics.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -learn_hub_id: 34090810571284 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/34090810571284-Tokenomics" -learn_hub_title: "Tokenomics" -learn_hub_section: "Tokens & Governance" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# Tokenomics - -## The ICP utility token - -The Internet Computer Protocol (ICP) makes use of a utility token called ICP. This token is used as follows in the protocol: First, any ICP holder can participate in the [governance of the Internet Computer](https://learn.internetcomputer.org/hc/en-us/articles/33692645961236) by staking ICP and then vote on or submit governance proposals and earn [voting rewards](https://learn.internetcomputer.org/hc/en-us/articles/34142993417108). Second, ICP can be transformed into cycles and pay for Internet Computer resources. Third, ICP tokens are used to reward node providers who operate node machines that contribute to the Internet Computer. Last but not least, ICP can be used to participate in [token swaps of decentralized autonomous organizations (SNS DAOs)](https://learn.internetcomputer.org/hc/en-us/articles/34141180048404) on the IC. These four protocol use cases are eloborated on in the following. However, ICP can of course also be used as a medium of exchange to pay for goods and services such as NFTs, subscriptions, etc. - -## Governance and voting rewards - -Anyone can participate in the governance of ICP by staking ICP tokens in so-called [neurons](https://learn.internetcomputer.org/hc/en-us/articles/34084120668692). Neuron holders can vote on proposals, which are suggestions on how ICP should be changed. The neurons’ voting power for decision making is proportional to the number of ICP staked inside and some other characteristics of the neuron such as the staking duration. The increased voting power for neurons with longer staking time creates an incentive to vote on proposals with the aim of driving decisions that maximize the value of their staked ICP over the long term. - -For participation in governance, the voting neurons' maturity increases. Maturity can then be used to mint ICP. Every day, the IC calculates a [voting reward](https://learn.internetcomputer.org/hc/en-us/articles/34142993417108) pot according to a schedule, which it then divides among all eligible neurons according to their relative voting power and participation. The schedule for voting rewards is designed to incentivize early adoption: Initially at genesis, maturity corresponding to 10% of the total supply of ICP is distributed in voting rewards on an annualized basis. Over the course of eight years, this number falls to 5%. - -As the daily reward amount is independent of the overall amount of staked ICP in the system and is distributed to neurons in proportion to their voting power and ratio of the proposals they voted on. This mechanism creates a natural incentive to stake ICP and participate in governance: the lower participation is the higher the rewards are. A significant part of staked ICP is staked for the maximum time of 8 years expressing the long-term commitment of these stakers. For current estimates of annualized voting rewards, refer to the ICP [Dashboard’s Governance page](https://dashboard.internetcomputer.org/governance). - -## Cycles as fuel for computation and other resources - -ICP can be used to pay for the usage of resources. More specifically, ICP tokens can be converted to **cycles** (i.e., burned), and these cycles are used by developers to pay for installing smart contracts, called canisters on ICP, and for the resources that canisters use (storage, CPU, and bandwidth). The cycle price is pegged to a basket of fiat currencies, so the conversion rate ICP to cycle fluctuates with the market price of ICP. Hence the cost to developers of acquiring fuel to run their application is predictable. - -In this so-called _reverse gas model_ of ICP, developers pre-pay costs by loading canisters with computation cycles. As a consequence, users can interact with a decentralized application (dapp) without needing tokens or dealing with seed-phrases. As cycles are stable in cost, developers know in advance how much they will need to spend on computation, storage, and other resources. - -## Node provider rewards - -ICP tokens are used to reward node providers—these are the entities that own and operate the computing nodes that run the Internet Computer Protocol. Node provider rewards are paid via newly minted ICP. The rewards they receive are fixed per node and tightly related to their actual costs. It depends on two parameters: - - 1. The location of the node, as hosting prices differ between locations. - 2. The type of the node, i.e., the hardware and connectivity specifications. - - - -To cover the investment and running cost of nodes, which occur in fiat currency terms, node provider rewards are specified in XDR, and are converted into ICP based on the average exchange rate over the last 30 days. - -### How the average exchange rate is computed - -The cycles minting canister fetches the ICP/XDR rate every 5 minutes from the exchange rate canister, which fetches the rates from various external sources. The cycles minting canister also stores the start-of-day rates (UTC). - -The 30-day-moving average uses the start-of-day rates for the past 30 days, this can be [verified in the code](https://github.com/dfinity/ic/blob/4344a924bcb12bc3d1510805dbb37391179df887/rs/nns/cmc/src/main.rs#L930). The current conversion rate can be viewed on the [ICP dashboard](https://dashboard.internetcomputer.org/network), or pulled automatically directly from the [CMC metrics](https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp0.io/metrics). - -## ICP ecosystem (SNS launch) - -The SNS framework enables developers to create an [SNS DAO](https://learn.internetcomputer.org/hc/en-us/articles/34084394684564) and to transfer control of their dapps unter the decentralized control of that DAO. - -As part of a so-called decentralization swap during an [SNS launch](https://learn.internetcomputer.org/hc/en-us/articles/34141180048404), users can commit some ICP to a new SNS DAO. In return, when the decentralization swap is complete, these users will receive tokens of the DAO with everyone paying the same price. Developers can specify a time period and minimum & maximum funding target of ICP to be collected, which determines when the swap is over. - -The ICP funds raised by the decentralization swap are retained within the reserves of the fully autonomous DAO, rather than being forwarded to the original developers of the dapp or service. These funds can be used to pay for future computation needs of the dapp and also to pay code bounties for future dapp enhancements. - -The SNS framework acts like rocket fuel for the ICP ecosystem. It provides easy and transparent access to exciting Web3 projects and channels funds to productive usage of the platform. - -## Development of total supply - -ICP has inflationary and deflationary mechanisms. Governance participants can convert voting rewards to newly minted ICP. Also, node providers receive rewards in the form of newly minted ICP tokens. On the other hand, ICP is converted to cycles (i.e., burned) in order to pay for computation and storage. This is depicted in the following picture. - -## ![deflation_inflation.png](https://learn.internetcomputer.org/hc/article_attachments/34277843713940) - -## - -In summary, there are the following mechanisms. - -Deflationary mechanisms: - - * Minting cycles to pay for compute and storage burns ICP to create cycles. - * Transaction fees for the ICP token. - * Fees for failed proposals of neurons; note that this only happens at disbursement or merging of neurons, so accumulated fees can persist for a while before visible in the total supply. - - - -Inflationary mechanisms: - - * Node providers are paid by minting ICP. - * [Voting rewards](https://learn.internetcomputer.org/hc/en-us/articles/34142993417108), once spawned and converted to ICP. - - - diff --git a/.migration/learn-hub/how-does-icp-work/tokens-governance/tokens-governance.md b/.migration/learn-hub/how-does-icp-work/tokens-governance/tokens-governance.md deleted file mode 100644 index cb1a19e..0000000 --- a/.migration/learn-hub/how-does-icp-work/tokens-governance/tokens-governance.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -learn_hub_id: 34574082263700 -learn_hub_url: "https://learn.internetcomputer.org/hc/en-us/articles/34574082263700-Tokens-Governance" -learn_hub_title: "Tokens & Governance" -learn_hub_section: "Tokens & Governance" -learn_hub_category: "How does ICP work?" -migrated: false ---- - -# Tokens & Governance - -The Internet Computer's tokenomics model is centered around two native tokens: [cycles](https://learn.internetcomputer.org/hc/en-us/articles/34573913497108) and ICP. The ICP token plays a critical role in the decentralized network governance and operation. Decentralized applications (dapps) running on the Internet Computer can also use a token-based governance, based on their own, application-specific token. - -In this section, you will find articles describing: - - * [Tokenomics](https://learn.internetcomputer.org/hc/en-us/articles/34090810571284): the economic model of the Internet Computer, encompassing token creation, distribution, and usage that influence its value and overall ecosystem, - * [Network Nervous Systems](https://learn.internetcomputer.org/hc/en-us/articles/33692645961236): onchain decentralized autonomous organization (DAO) that governs the Internet Computer Protocol, - * [Service Nervous System:](https://learn.internetcomputer.org/hc/en-us/articles/34084394684564) framework for creating and maintaining DAOs to govern dapps on the Internet computer. - - - diff --git a/docs/concepts/cycles.md b/docs/concepts/cycles.md index 58aae02..0d7ffdb 100644 --- a/docs/concepts/cycles.md +++ b/docs/concepts/cycles.md @@ -61,6 +61,33 @@ When a canister allocates new storage bytes on a subnet that is more than 750 Gi 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 + +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 + +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. + +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. + +Every state-changing operation (each block created) costs 100M cycles as a fee. The cycles ledger does not support calling arbitrary canisters with cycles attached, because open call contexts can cause the ledger to become stuck. If you need to call a canister with cycles, top up the canister first and let it manage its own balance. + ## 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. @@ -86,4 +113,4 @@ The tradeoff is that developers must forecast and fund usage upfront rather than - [Cycles Costs Reference](../references/cycles-costs.md): exact cost tables for all operations - [Canisters](./canisters.md): canisters as the paying entity for compute and storage - + diff --git a/docs/concepts/governance.md b/docs/concepts/governance.md index ad36b19..7766da3 100644 --- a/docs/concepts/governance.md +++ b/docs/concepts/governance.md @@ -1,11 +1,11 @@ --- title: "Governance" -description: "How ICP is governed: the NNS, SNS for app governance, neurons, proposals, and tokenomics fundamentals" +description: "How ICP is governed: the NNS, SNS for app governance, neurons, proposals, and economics fundamentals" sidebar: order: 13 --- -The Internet Computer Protocol uses two governance systems: the **Network Nervous System (NNS)** governs the protocol itself, and the **Service Nervous System (SNS)** provides a framework for app developers to hand control of their applications to a community-owned DAO. +The Internet Computer Protocol uses two governance systems: the **Network Nervous System (NNS)** governs the protocol itself, and the **Service Nervous System (SNS)** provides a framework for app developers to hand control of their applications to a community-governed SNS. Understanding both systems is important for developers. NNS proposals can affect canister behavior (for example, proposals that update system canisters or modify subnet configurations). SNS gives developers a standardized path to decentralize their app. @@ -19,13 +19,13 @@ Decisions made through the NNS include: - Creating and managing subnets (adding capacity, changing subnet membership) - Setting economic parameters such as the ICP-to-cycles conversion rate - Authorizing new node providers and their hardware -- Creating new SNS DAOs for apps +- Creating new SNS instances for apps The NNS governance canister (`rrkah-fqaaa-aaaaa-aaaaq-cai`) is the entry point for all proposal submissions and voting. See [system canisters](../references/system-canisters.md) for the full list of NNS canister IDs. -## ICP tokens and the ledger +## ICP and the ledger -ICP is the native utility token of the Internet Computer. It plays three roles: +ICP is the native digital asset of the Internet Computer. It plays three roles: - **Governance participation**: ICP can be locked into neurons to vote on proposals and earn voting rewards. - **Compute fuel**: ICP can be converted into cycles, which power canister computation and storage. The NNS sets the ICP-to-cycles conversion rate to keep cycle costs stable in fiat terms (anchored to the IMF SDR). @@ -35,7 +35,7 @@ The ICP ledger, hosted within the NNS, records all ICP balances. Each account ha ## Neurons -A neuron is a governance participant created by locking ICP tokens in the NNS governance canister. Neurons are the atomic units of voting power. +A neuron is a governance participant created by locking ICP in the NNS governance canister. Neurons are the atomic units of voting power. **Key neuron attributes:** @@ -68,7 +68,7 @@ An NNS proposal is a governance action submitted by a neuron and voted on by the - *UpgradeNnsCanister* and *UpgradeRootCanister*: Update protocol canisters. May change interfaces developers rely on. - *CreateSubnet* / *AddNodeToSubnet*: Affect where canisters run. - *UpdateCanisterSettings* for NNS canisters: Can change the behavior of system canisters. -- *CreateServiceNervousSystem*: Authorizes a new SNS DAO, launching the decentralization process for an app. +- *CreateServiceNervousSystem*: Authorizes a new SNS, launching the decentralization process for an app. See [system canisters](../references/system-canisters.md) for the full list of NNS proposal topics and types. @@ -78,11 +78,11 @@ Neurons that vote (directly or through following) earn voting rewards. The proto Rewards accumulate as **maturity** rather than ICP directly. Neurons can convert maturity to ICP (with a modulation of ±5% applied to the mint amount) or merge maturity back into their stake to compound future rewards. -The reward rate declines over time as the protocol matures, converging toward a lower floor rate over roughly a decade. See the [ICP tokenomics overview](https://learn.internetcomputer.org/hc/en-us/articles/34090810571284) for details on the reward rate schedule. +The reward rate declines over time as the protocol matures, converging toward a lower floor rate over roughly a decade. See [Network economics](network-economics.md) for details on the reward rate schedule and supply dynamics. ## The Service Nervous System -The SNS is a governance framework that allows app developers to create a community-owned DAO for their application. When an app is governed by an SNS, token holders vote on proposals to upgrade the app's canisters, manage treasury funds, and adjust governance parameters. +The SNS is a governance framework that allows app developers to create a community-governed SNS for their application. When an app is governed by an SNS, asset holders vote on proposals to upgrade the app's canisters, manage treasury funds, and adjust governance parameters. Unlike the NNS, which is a singleton governing the entire protocol, each SNS is a separate set of canisters specific to one app. SNSes live on a dedicated SNS subnet. @@ -93,27 +93,27 @@ An SNS consists of six canisters deployed by SNS-W (the SNS Wasm modules caniste | Canister | Purpose | |----------|---------| | **Governance** | Proposal submission, voting, neuron management | -| **Ledger** | SNS token transfers (ICRC-1 standard) | +| **Ledger** | SNS asset transfers (ICRC-1 standard) | | **Root** | Sole controller of all app canisters post-launch | -| **Swap** | Runs the decentralization swap (ICP for SNS tokens) | +| **Swap** | Runs the decentralization swap (ICP for SNS assets) | | **Index** | Transaction indexing for the SNS ledger | | **Archive** | Historical transaction storage | -Once an SNS is live, the SNS Root canister is the sole controller of the app's canisters. Upgrades happen through governance proposals voted on by SNS token holders. +Once an SNS is live, the SNS Root canister is the sole controller of the app's canisters. Upgrades happen through governance proposals voted on by SNS asset holders. -### Token economics +### Digital asset economics -Each SNS has its own governance token. The initial token distribution is defined in the SNS configuration file and includes: +Each SNS has its own governance asset. The initial distribution is defined in the SNS configuration file and includes: -- **Developer neurons**: Tokens allocated to the original developers and seed funders, typically with vesting periods and dissolve delays to signal long-term commitment. -- **Treasury**: Tokens owned by the SNS governance canister, spendable by DAO proposal. -- **Swap allocation**: Tokens sold during the decentralization swap in exchange for ICP. +- **Developer neurons**: Assets allocated to the original developers and seed funders, typically with vesting periods and dissolve delays to signal long-term commitment. +- **Treasury**: Assets owned by the SNS governance canister, spendable by governance proposal. +- **Swap allocation**: Assets sold during the decentralization swap in exchange for ICP. -The SNS ledger implements the ICRC-1 token standard. SNS neurons work similarly to NNS neurons: stake governs voting power, dissolve delay grants a bonus (up to 2x at the configured maximum), and age grants an additional bonus. +The SNS ledger implements the ICRC-1 standard. SNS neurons work similarly to NNS neurons: stake governs voting power, dissolve delay grants a bonus (up to 2x at the configured maximum), and age grants an additional bonus. ### The decentralization swap -The decentralization swap is the mechanism by which SNS tokens are distributed to the public. Participants send ICP to the SNS Swap canister during the swap window; when the swap closes, the exchange rate is determined and participants receive SNS tokens in a basket of neurons with vesting schedules. +The decentralization swap is the mechanism by which SNS assets are distributed to the public. Participants send ICP to the SNS Swap canister during the swap window; when the swap closes, the exchange rate is determined and participants receive SNS assets in a basket of neurons with vesting schedules. The swap has minimum and maximum ICP participation thresholds. If the minimum is not reached, the swap fails: all ICP is refunded and control of the app returns to the original developers (via the fallback controllers defined in the configuration). If the maximum is reached before the end time, the swap closes early. @@ -126,7 +126,7 @@ SNS governance mirrors the NNS design but is customized per app: | Aspect | NNS | SNS | |--------|-----|-----| | What it governs | Protocol and network | A specific app | -| Token | ICP | Project-specific ICRC-1 token | +| Digital asset | ICP | Project-specific ICRC-1 asset | | Governance canisters | Singleton on NNS subnet | Per-app on SNS subnet | | Launch authority | N/A (pre-existing) | NNS must approve creation | | Proposal types | Protocol updates, subnet management, economics | App upgrades, treasury transfers, parameter changes | @@ -136,12 +136,12 @@ SNS governance mirrors the NNS design but is customized per app: When an app is governed by an SNS, the original developers no longer have direct control. Key implications: - **Upgrades require proposals**: All changes to app canisters must go through SNS governance votes. Development slows down compared to centralized control. -- **Treasury spending requires votes**: Any use of DAO funds requires a governance proposal. +- **Treasury spending requires votes**: Any use of SNS treasury funds requires a governance proposal. - **Upgrade path is transparent**: Community members can verify new canister wasm modules before voting. Reproducible builds allow independent verification. -- **Responsibility is distributed**: Post-launch, the development team typically continues leading the project but must engage the token-holding community for major decisions. -- **Custom proposals**: Apps can register custom proposal types (generic functions) that allow the DAO to call specific canister methods, enabling fine-grained governance without unrestricted code upgrades. +- **Responsibility is distributed**: Post-launch, the development team typically continues leading the project but must engage the community of asset holders for major decisions. +- **Custom proposals**: Apps can register custom proposal types (generic functions) that allow the SNS to call specific canister methods, enabling fine-grained governance without unrestricted code upgrades. -Developers preparing for an SNS launch should ensure their codebase is stable, open-sourced, and reproducibly buildable before the decentralization swap. The NNS community votes on the creation proposal and expects evidence of product-market fit, sound tokenomics, and a realistic roadmap. +Developers preparing for an SNS launch should ensure their codebase is stable, open-sourced, and reproducibly buildable before the decentralization swap. The NNS community votes on the creation proposal and expects evidence of product-market fit, sound asset economics, and a realistic roadmap. ## Next steps @@ -149,4 +149,4 @@ Developers preparing for an SNS launch should ensure their codebase is stable, o - [Manage a live SNS](../guides/governance/managing.md): proposals, upgrades, and treasury management after launch - [System canisters reference](../references/system-canisters.md): NNS canister IDs and interfaces - + diff --git a/docs/concepts/index.md b/docs/concepts/index.md index 8944cc1..df19879 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -31,3 +31,5 @@ Understand the ideas behind the Internet Computer before you build on it. These - **[Security Model](security.md)**: Canister isolation, trust boundaries, and the threat model for app developers. - **[Governance](governance.md)**: The NNS, SNS for app governance, neurons, and proposals. +- **[Network economics](network-economics.md)**: ICP uses, governance rewards, supply dynamics, and SNS asset configuration. +- **[Ledgers](ledgers.md)**: How ICRC and ICP ledgers work, address formats, and scaling architecture. diff --git a/docs/concepts/ledgers.md b/docs/concepts/ledgers.md new file mode 100644 index 0000000..2d7c8eb --- /dev/null +++ b/docs/concepts/ledgers.md @@ -0,0 +1,73 @@ +--- +title: "Ledgers" +description: "How ledgers work on ICP: the ICP ledger, ICRC ledgers, addresses, transactions, archives, and fees" +sidebar: + order: 14 +--- + +Every digital asset on ICP is managed by a **ledger canister**: a canister that records ownership and permanently logs every transfer and balance change. This page explains how ledgers are structured, how they scale, and what the different address formats mean. + +## What a ledger canister does + +A ledger canister is the authoritative source of truth for an asset. It: + +- Records the current balance of every account. +- Logs every transfer, mint, and burn operation in an append-only transaction history. +- Validates and executes transfer requests. +- Enforces transaction fees. + +Unlike a traditional bank, ledger canisters are publicly readable: anyone can query transaction history through explorers and verify balances independently. + +There is no single global ledger on ICP. Each asset is managed by its own ledger canister, deployed and governed by whoever controls that canister. ICP has its own ledger. Every [ICRC](../references/icrc-standards.md)-standard asset has its own ledger. [Chain-key tokens](chain-fusion.md) such as ckBTC and ckETH each have their own ledger canisters. + +## Two ledger designs + +ICP has two ledger designs in common use, each with a different address format. + +### ICP ledger + +The ICP ledger manages the native ICP asset. It uses an address format called an **AccountIdentifier**: a 32-byte hash derived from a principal ID and an optional subaccount. AccountIdentifiers are displayed as 64-character hex strings. + +### ICRC ledgers + +Most fungible assets on ICP (including chain-key tokens like ckBTC and ckETH) use the ICRC standard. ICRC ledgers use a two-part account format: + +- **Principal**: the identity of the holder (a user principal or canister principal). +- **Subaccount** (optional): a 32-byte value that lets a single principal manage many internal accounts. + +This model gives wallets and services flexibility: a single canister can track individual user balances in separate subaccounts without deploying a separate canister per user. + +The [ICRC](../references/icrc-standards.md) standard defines a family of interfaces. ICRC-1 covers basic transfers. ICRC-2 adds approval and transfer-from semantics (like ERC-20 allowances). ICRC-3 standardizes the transaction log format. All DFINITY-maintained asset ledgers implement at least ICRC-1 and ICRC-2. See [Digital assets guide](../guides/digital-assets/ledgers.md) for the API. + +## How transactions are recorded + +Ledgers maintain an append-only transaction log. Every transfer, mint, and burn creates a new block at the end of the log. Blocks are never removed or rewritten, making the history fully auditable. + +Each block contains the operation type, the accounts involved, the amount, the timestamp, and an optional memo. This log is the basis for wallet balance displays and explorer history views. + +## Scaling with archives and index canisters + +As a ledger accumulates transactions, its storage grows. Two additional components manage this growth: + +**Archive canisters.** Older transaction blocks are moved out of the main ledger canister into archive canisters. This lets the ledger scale well beyond a single canister's storage limit and across subnet boundaries. From a user's perspective, the history remains fully accessible through explorers and tooling; archiving is an internal implementation detail. + +**Index canisters.** Most deployed ledgers have a companion index canister that organizes transaction data by account address. Wallets and explorers query the index to retrieve the transaction history for a specific account without scanning every block in the ledger. The index does not change any balances or create new transactions; it is purely a read-optimized view over the ledger's history. + +Together: the ledger records the truth, archives extend storage capacity, and the index makes retrieval fast. + +## Transaction fees + +Most transfers incur a small fee. The sender pays the fee when initiating a transfer. Depending on how the ledger is configured, fees are either: +- **Burned**: removed from the total supply permanently, creating deflationary pressure. +- **Collected**: sent to a designated fee account (as the ICP ledger does for the NNS). + +Fees are typically small and fixed (for example, the ICP transfer fee is 0.0001 ICP; the ckBTC transfer fee is 10 satoshi). Because cycle costs are stable in XDR terms, transaction fees in cycles-denominated contexts remain predictable even as ICP's market price changes. + +## Next steps + +- [Digital assets guide](../guides/digital-assets/ledgers.md): ICRC-1/2 API usage, transfer examples, balance queries +- [Network economics](network-economics.md): how ICP and SNS assets are economically designed +- [Cycles](cycles.md): cycles as the computational fuel that ledger canisters and other canisters consume +- [Chain-key tokens](chain-fusion.md): ckBTC, ckETH, and other 1:1 backed asset ledgers + + diff --git a/docs/concepts/network-economics.md b/docs/concepts/network-economics.md new file mode 100644 index 0000000..81d89f5 --- /dev/null +++ b/docs/concepts/network-economics.md @@ -0,0 +1,71 @@ +--- +title: "Network Economics" +description: "How the Internet Computer's economic model works: ICP uses, governance rewards, supply dynamics, and SNS asset configuration" +sidebar: + order: 13 +--- + +ICP's economic model is built around two native assets: **ICP** and **cycles**. They serve distinct purposes: ICP is a governance and value transfer digital asset; cycles are a stable-cost computational fuel that canisters consume to run. This separation keeps developer costs predictable regardless of ICP market price. + +## ICP uses + +ICP has four protocol-level uses: + +**1. Governance participation.** ICP holders stake ICP to create [neurons](governance.md#neurons-and-voting-power) in the NNS governance system. Neurons vote on proposals and earn voting rewards in return. Staking longer increases voting power and rewards, creating an incentive for long-term alignment with the network. + +**2. Cycle conversion.** ICP can be burned to mint cycles through the Cycles Minting Canister (CMC). Cycles are pegged to the XDR basket of currencies at a rate of 1 trillion cycles = 1 XDR. This means developer infrastructure costs are stable in fiat terms even as ICP's market price changes. See [Cycles](cycles.md) for details. + +**3. Node provider rewards.** Nodes that run the Internet Computer are owned by independent node providers. These providers are compensated in newly minted ICP. Rewards are specified in XDR and converted to ICP based on a 30-day moving average exchange rate, so providers receive stable real-world compensation regardless of price fluctuations. + +**4. SNS decentralization swaps.** Users can commit ICP to participate in the decentralization swap of an SNS. In return they receive the SNS's governance assets at a uniform price. The ICP raised enters the SNS treasury under NNS control and funds future development and operations. + +Beyond these protocol uses, ICP functions as a medium of exchange and can be used to pay for services, NFTs, subscriptions, and other onchain activity. + +## Governance rewards and maturity + +Any ICP holder can stake ICP in a neuron to participate in NNS governance. Each day the NNS calculates a voting reward pot and distributes it among eligible neurons proportionally to their voting power and participation. + +Reward rate schedule: +- **At genesis:** rewards are calibrated to distribute roughly 10% of total supply per year in annualized terms. +- **Over 8 years:** the rate declines to approximately 5% per year. + +Rewards accumulate as **maturity** within the neuron, not as liquid ICP. Maturity can be converted to ICP (spawning), which at that point triggers the actual minting. This deferred minting means the total supply grows only when neurons choose to realize rewards, giving holders flexibility over when to enter circulation. + +The daily reward amount is fixed (independent of total staked ICP), so lower overall participation means each participant earns a higher share. This self-regulating mechanism incentivizes participation. + +## Supply dynamics + +ICP has both inflationary and deflationary mechanisms: + +**Inflationary:** +- New ICP is minted to pay node provider rewards. +- New ICP is minted when neurons spawn voting rewards as maturity. + +**Deflationary:** +- ICP is burned when converted to cycles. +- ICP transaction fees are burned. +- Failed NNS proposals result in a small fee charged to the proposing neuron. + +The net effect on supply depends on market conditions: when cycle demand is high (more computation), more ICP is burned. When governance participation is high, more ICP is minted. The [NNS dashboard](https://dashboard.internetcomputer.org/governance) shows live estimates of supply, staking, and annualized voting rewards. + +## SNS economics + +Each SNS deploys its own governance asset alongside its canister, with an economics configuration set at launch. The mechanics are similar to the NNS: staking for voting power, configurable voting reward minting, transaction fee burning, and a treasury for SNS-controlled spending. + +Key parameters a team configures for their SNS: + +- **Initial asset allocation**: how assets are split between the decentralization swap (community), SNS treasury, seed funders, and the development team. The SNS framework requires that at least as many assets are allocated to the swap as to the seed funders and development team combined. +- **Voting power**: teams can weight voting power by staking duration to encourage long-term commitment. The configuration must prevent the founding team from holding more than 50% of initial voting power. +- **Reward rate**: whether and at what rate the SNS mints new assets for governance participation. +- **Transaction fees**: a per-transfer fee that is burned, creating deflationary pressure. + +SNS economics is entirely configurable and independent of the NNS economic model. Two SNS instances can have very different economic designs. + +## Next steps + +- [Governance](governance.md): NNS neurons, proposals, voting, and the SNS framework +- [Cycles](cycles.md): how cycle costs work and how ICP converts to cycles +- [Ledgers](ledgers.md): how ICP and other asset balances are tracked +- [Launching an SNS](../guides/governance/launching.md): the decentralization swap process + +