(If NNS proposal passes) implementation + testing would take around 1-2 weeks. NNS Proposal to upgrade the code with experimental feature: Week of September 27, 2021
Due to security concerns we currently only allow whitelisted canisters (i.e., canisters on the NNS) to transfer ICPs. This feature expands the ability to transfer ICP to other canisters.
What we need:
IC Interface Spec includes the calls a canister must make to query for its ICP balance and to transfer ICP. Optional: specification of how to stake/dissolve/vote with neurons.
Removal of whitelist barrier so all canisters can hold ICP (unless we for security reasons decide to restrict access)
Testing (in particular so to ensure no NNS shielding blocks transfer of ICP)
Security review (including malicious subnets, where it ought to be the case a corrupt subnet can only act on behalf of canisters it hosts; the controller cannot be faked.
Stakeholders and plan for rolling out: developers such as Fleek? phased roll-out by first labeling it as an experimental feature (potentially limiting each canister to a few ICP), later offer e.g. fiduciary subnets with higher guarantees
Consult SRE team for any operational concerns that may arise
Not necessarily in scope: staking and voting (P2), security level of canisters (developers and users may want assurance it is a high-security subnet the deploy on but we will leave the specification of e.g. fiduciary subnets to a different feature and just recommend not putting much ICP on a canister), CDK tooling to handle ICP on canisters.
The design for the Internet Computer services was always that they don’t distinguish “outside users” from “canister users”, and that their APIs are accessible from other canisters without issue. The fact that our maybe most important canister doesn’t do that is somewhat embarrassing, and I hope we can drop this code soon.
(Fun fact: With the current ledger code, canisters can hold ICPs. They just cannot use them, as the canister-banning-check is on send().)
ICP has so far been a feature that is not reflected in the Interface Spec, which describes only lower-level aspects. After all, in most ways ICP is “just” data in one particular canister, and is technically no different than data in other canisters.
I don’t think this needs to change, or that any change in the Interface Spec is needed. If there is documentation of the ledger cansiter (is there? hint hint), then that needs to change.
This may be an uninformed question, but can someone expand on why ICP storage should be expanded beyond canisters in the NNS? The description above states that it wasn’t initially allowed for security reasons, but doesn’t really provide any information about the value of expanding to other canisters. I’m just curious if the value of storing ICP in any canister justifies the effort and security risks of doing so.
Without, you can’t really do any DEFI solutions on ICP. Example a DEX or liquidity pools would all need a way to hold ICP and other tokens. No issue with other tokens, but no way to do it with ICP. This is why DEFI is currently stalled on ICP… in my book it should be the number 1 priority, but I am biased in the fact that I’m building/waiting to deploy DEFI solutions.
Enabling canisters to hold ICP is very high up on our agenda. We are having discussions with the security and research teams to map out the path forward. I hope to come back with a timeline on this shortly.