Enable Canisters to Hold ICP

When can we hold ICP in ordinary canister


Voting on enabling canisters to transfer ICP is now open


Is there a way to vote from inside NNS Dapp?

Yes, if you have staked ICP in a neuron with long enough dissolve delay in the NNS Dapp, or you have staked outside the NNS Dapp but assigned a hotkey in the Dapp


I’m voting no again, basically the same reasoning as before: Enable Canisters to Hold ICP - #77 by lastmjs


Earlier discussion previously here leads me to the decision of voting yes!

TL;DR: Due to an ongoing incident, the foundation will vote “reject” on the currently open proposal for “ICP on canisters” (proposal 30496). Once the incident is resolved, a new proposal will be submitted.

Hello, there is an ongoing incident with one of the application subnets (subnet “pjljw”). The subnet hosts a canister for which execution of messages results in different states on different replicas. Multiple teams are investigating the cause for this non-determinism right now.

The Internet Computer has a fail-safe built in for such a case causing the subnet to suspend sending messages to other subnets so that the problem can be isolated and fixed. However, this may prevent canisters on other subnets from being upgraded. The reason for this is that, to upgrade a canister, the canister needs to have processed all outstanding messages - otherwise replies might not be processable anymore by the upgraded canister due to change of code.

Unfortunately, there is thus a possibility that the Ledger canister may not be able to upgrade and stall: if there are outstanding messages from the Legder canister to the Cycles Minting Canister to top-up or create canisters on the “pjljw” subnetwork, these messages cannot obtain a reply and the Ledger canister will not be able to fully stop, which is a prerequisite for upgrading.

We view this as a high risk. Therefore, to avoid another potential incident, the DFINITY Foundation has chosen to vote “reject” the ledger upgrade proposal 30496 enabling ICP for canisters.

Please note that the incident with subnet “pjljw” is NOT related to the “Canisters can hold ICP” feature. Once the incident with subnet “pjljw” is resolved, the Foundation will resubmit the proposal upgrade the ledger canister and to enable ICP on canisters.


sad news, “pjljw” subnetwork What’s happening?

Outstanding responses preventing a ledger upgrade - it needn’t be that way.


Was the break in determinism just discovered? I know pjljw has been a hotspot for issues, but I wasn’t aware of something this big.


The break in determinism was discovered just a few hours ago because it caused the subnet finalisation rate to go down. While investigation is still on going, it is known that the metadata (ie number of pages dirtied by the canister) of a specific canister stored as part of canister state differs on different replicas. This causes CUP signing to fail as replicas did not agree on state hash, stopping execution and slowing the block rate. Will post more once more is known, team is working on a fix now.


This may not be obvious to readers of this thread (since this is his second post), so I thought I should point out for context that @Jan above is Jan Camenisch, the CTO of DFINITY. :slightly_smiling_face:


Update on enabling canisters to transfer ICP

TL;DR: The Foundation will resubmit the proposal to upgrade the ledger and enable canisters to transfer ICP. The Foundation will vote for adopting the proposal.

Yesterday, voting on proposal 30496 to upgrade the Ledger and enable canisters to transfer ICP saw 18.9% votes for adoption and less than 0.1% for rejection with only half an hour to the deadline. Unfortunately, a technical issue in application subnet “pljlw” made it risky to perform the upgrade to the Ledger canister at the same time. Important to note, the issue with subnet “pljlw” is unrelated to the ICP transferability upgrade. Fortunately, the subnet is back to running normally. As promised, the Foundation is resubmitting the upgrade proposal to update the Ledger canister and enable ICP transferability. Given the majority of the community was in favour of adoption, this time, the Foundation will vote in favor of the upgrade proposal.


I am confused why this has to do so like this, which sounds like a waste of time. You said that “the issue with subnet ‘pljlw’ is unrelated to the ICP transferability upgrade.” Why cannot jut let the ICP transferability upgrade? As per this saying, if one day there are millions of subsets and if one subset has this kind of issue and we will not be able to do any of this kind of upgrade things? Is my understanding right?

Currently, converting ICP to Cycles to top-up a canister triggers a call-tree involving the ledger and the canister to be topped up. If the canister to be topped up is on an unresponsive subnetwork, then the call-tree may not terminate and the ledger cannot be upgraded (since atm, to safely upgrade a canister the canister needs to be stopped).
We will remove this dependency (either by eliminating the need to stop the canister, or via different flows for ICP conversion to cycles so that the dependency is removed). So, upgrading the ledger will be completely independent of the behavior of other canisters/subnetworks.


Here is the resubmitted proposal.
Canisters are now able to transfer ICP!


I wonder is the phase of the nns ICP wallet when we accidentally delete it, although we still save the phase, but we can’t backup the wallet, is there any way to recreate it?

Trying to use the new interface… what am I missing?

❯ dfx canister --network ic call "ryjl3-tyaaa-aaaaa-aaaba-cai" account_balance "(record { \"account\" = blob \"\a8\137Tw\ca\0d\04KeY2r(6P\d2<\0a\c0\ac\bcnH\ca\d5\e6\fc\"})"

The Replica returned an error: code 5, message: "Canister ryjl3-tyaaa-aaaaa-aaaba-cai trapped explicitly: Panicked at 'Deserialization Failed: "Fail to decode argument 0 from table0 to record { account : vec nat8 }"', /builds/dfinity/ic/rs/rust_canisters/dfn_core/src/endpoint.rs:34:41"

Using the exact same interface (pulled from the proposal’s github link) on a local test canister works just fine:

❯ dfx canister call legends account_balance "(record { \"account\" = blob \"\a8\137Tw\ca\0d\04KeY2r(6P\d2<\0a\c0\ac\bcnH\ca\d5\e6\fc\"})"

(record { e8s = 0 : nat64 })

If you have accidentally deleted the recovery phrase then you can simply create a new recovery phrase which will be different from the phrase you had before. Is your question if you can somehow re-install the old recovery phrase into your internet identity instead of getting a new, different one?

how can i create a new phase once i have checked it in the approved devices section nns please guide me

I got exactly the same error as @jorgenbuilder

The Replica returned an error: code 4, message: "IC0503: Canister ryjl3-tyaaa-aaaaa-aaaba-cai trapped explicitly: Panicked at 'Deserialization Failed: "Fail to decode argument 0 from table0 to record { account : vec nat8 }"', /builds/dfinity/ic/rs/rust_canisters/dfn_core/src/endpoint.rs:34:41"

Context: a canister that tries to get its own balance.
You can find the code here.

EDIT: it is now fixed, the account id hash was missing.