NNS Proposal: Enabling Canisters to hold ICP
Summary: Enabling canisters to hold ICP - currently only user accounts and the NNS can hold ICP
Rationale: To enable DeFi and other use cases, canisters must be able to hold ICP.
Concerns: Canisters have been prevented from holding ICP up until this point for security reasons. A poorly written canister may lose or destroy ICP contained therein. Fears about data loss during canister upgrades are well founded as developer error is a major risk. Especially for canisters written in Rust.
Mutable canisters are not smart contracts. A canister holding ICP could be drained by the canister controller.
The native security of canisters is an open question.
What is the replication factor appropriate for canisters holding ICP? Fiduciary subnets were discussed in advance of launch. It would be good to hear more from the foundation on this.
Proposal: The content of the proposal is easy to understand. There is minimal implementation work necessary to enable this feature. Most of the content relates to testing and security review.
‘. . .the “ability for canisters to hold ICP” is basically removing a line of code. Canisters have a restriction that bars holding ICP.’ - diegop
Discussion: Like other feature-enabling proposals, the rollout will be phased with the feature initially being labeled experimental. This seems sensible.
Concerns have been raised about transferring the controller of a canister holding ICP. This transaction would not be recorded in the ledger meaning the transaction would be untraceable.
Canisters will not be able to stake neurons because the ability to change the canister controller would make those neurons transferable.
The inability for canisters to hold ICP is the most lamented limitation in the IC developer ecosystem. Fleek, Departure Labs, Toniq Labs, DFinance, and InfinitySwap are sitting on products that need this functionality to go live. The implementation of this proposal is necessary for the IC to move forward.
This proposal raises some best practice considerations:
As data is automatically backed up on the IC with motoko provided the data structure has not been altered, risk of data loss is minimised. In rust, the risks are greater as the on-IC data backup procedure needs to be defined by the developer. In either case, data needs to be backed up as a security measure to prevent the loss of user account balances in the case that the canister holds user balances, as in DeFi applications. This is a major concern and all DeFi protocols should publish their backup procedures to support user due diligence.
As the canister controller will always have the ability to drain the canister of funds, it also makes sense for canisters handling public funds to be immutable. It would be nice to see a guide to developers and users relating to this.
Ideally, methods of verifying the logic inside canisters should be developed to support the safe use of DeFi applications also.
Conclusion: The roadmap-based community engagement appears to be maturing rapidly. This is wonderful to see. The discussion revolved around the consequences of canisters holding ICP, not the proposal itself.
Given the importance of this proposal and the lack of concern with the proposal itself, cycle_dao will vote Yes.