Hi everybody! Here’s our plan for enabling all principals to transfer ICP, including canisters. We’ll be happy to receive feedback!
NNS Proposal: Enable all principals to transfer ICP
Objective
Enable canisters to transfer ICP.
Background
Currently canisters can receive ICP, since you can send ICP to any address. An address is derived from a principal and an optional subaccount, so each canister automatically has many addresses associated with it just like any other principals.
Canisters are blocked from transferring ICP though. This block is implemented by a check in the ledger that only self-authenticating principals (i.e. allows principals ending in 0x02), and specific whitelisted canisters to transfer ICP. Canisters do not have self-authenticating principals and can therefore not transfer ICP.
Proposal
Remove the restriction such that any principal is allowed to transfer ICP with the exception of the anonymous principal.
Backwards compatibility
All self-authenticating and whitelisted canisters can continue to transfer ICP, this proposal just permits other principals to transfer ICP too.
Security
Enabling canisters to transfer ICP may put control over significant value in the hands of canisters on application subnets. This is a significant change, previously only whitelisted canisters that all lived on the root subnet could transfer ICP.
A canister holding ICP may for instance be co-located with a canister developed by an attacker, which could try to do a jailbreak and steal ICP. We have therefore been thinking hard about security and will continue to analyze security aspects of enabling all principals, including canisters, to transfer ICP.
Canister smart contracts on the Internet Computer are unique in the sense that they can be easily updated by the controller of the canister. This ability enables developers writing their business logic on smart contracts to continue evolving their applications without having to deploy new contracts. However, this also means that if an end-user were to send ICP to these canister smart contracts they will be trusting the controller of the canister.
This implies a risk of malicious developers trying to do fraud on the Internet Computer. Anybody can deploy a canister. Moreover, the controller of a canister can upgrade the Wasm code running the canister. So users need to be wary of rug pull operations: set up a canister running benign Wasm code and get people to transfer ICP to it, then change the Wasm code to steal the ICP.
We are working on mitigations: sandboxing of canisters (which will take a while); providing guidance on how to check which principal controls a canister and it could potentially be a dummy principal so the canister is immutable; and how to verify the Wasm module corresponds to a piece of source code.
In particular, providing the ability check that a canister is immutable and the ability to verify the code of a canister are necessary features to allow opting in to a similar trust model to existing “smart contracts” that predate the launch of the IC. However, it must be stressed that this is an opt-in. Even with these solutions in place, there is a risk that people will treat mutable canisters as immutable smart contracts and fall victim to a rug pull. We would be interested in feedback whether this is an acceptable risk.
Enabling canisters to trade ICP also enables an additional path to make off-the-record ICP transactions, because canister controllers are not ledgered. Agreeing to this proposal means accepting the lack of traceability.
Another risk is that currently canister developers do not have control over which application subnet their canister is created on. We expect in the future the Internet Computer will offer better control and better means for developers and end users to understand the risks of transacting ICP in each subnet depending on node distribution and other properties.
Some of the mitigations, e.g., sandboxing of canisters will take time to develop and will not be ready before this proposal. We do not consider the mitigations and additional security features as blocking the proposal. But we consider the ability for canisters to transfer ICP to be in an experimental phase. We encourage experimentation with small amounts of ICP but discourage large amounts of ICP.
Rollout plan
The main change is just a few lines of code in the ledger to enable all principals, except the anonymous principal, to send ICP. We will make this an NNS proposal.
At the same time, we communicate widely that we view this proposal as being in an experimental phase. As long as the Internet Computer is in Beta, we strongly discourage sending large amounts of ICP to a canister.
Once we have rolled this proposal out, it is hard to take back since many canisters will rely on being able to transfer ICP. In the worst case, while rollback is hard it would be possible to blacklist some principals just like the anonymous principal is blacklisted, but we prefer not to go there. We therefore do not call this an experimental feature, but we want to start with an experimental phase.