Enable Canisters to Hold ICP

We’re not planning to enable canisters to stake neurons. You’re correct that if we did, then indeed one could transfer neurons via transferring controllers.


Nope, we’re not planning to let canisters control neurons. Agree with your in-principle analysis but in either case I think it would be best to take one step at a time.


I see very little chance of the proposal creating or exposing any new vulnerabilities of the IC. My own concern is more about increasing adversarial incentives.
As @nomeata says in his reply, users may already have value in the canister logic today. But ECDSA signatures are not there yet, and putting ICP in canisters may add value beyond what is currently in canister logic today, so I think the proposal makes application subnets juicier targets.


Threshold ECDSA and related ideas will take months to implement. Also, due to the greater simplicity of native ICP handling, it is easier to analyze from a security perspective.


Make sense with a schedule like that. I think this is the first we’ve heard that the signature stuff is months out.

1 Like

Yes, sorry, I put the timeline of “months” friday evening PST.


Based on the questions on this thread, I will push back voting 1 more day to September 15th to give people the ability to dive deep. If people want more time, we can do that, but hopefully, 1 day is enough.

Update: we are on track to submit NNS motion proposal on Wednesday September 15, at 15:00 UTC.


does this mean the start of DeFi on the IC?

I think there is some emerging Defi apps on IC already, but I think it safe to say this would greatly accelerate it.

NNS motion proposal is live: https://dashboard.internetcomputer.org/proposal/20588


How long would this take? How intense has security analysis of the execution layer been?

I am feeling hesitant that there are obvious improvements to security that could be made (multiple independent security audits, bug bounties, process sandboxing), but that won’t have been made before we open up this capability.

And considering the main reason for this limitation in the first place is security, perhaps we should proceed more carefully.

What if we waited until one or more of the following were done, or perhaps made these prerequisites to deploying the change?

  • Internal analysis of security of multi-canister execution environment within a replica, with publication of that analysis
  • Multiple independent analyses of the above, with publications
  • Bug bounties focused on execution environment for a sufficient amount of time
  • Process sandboxing implemented

I would not underestimate how quickly honeypots of ICP will start forming within canisters, and hacks will do no favors for those hacked nor for the Internet Computer nor for DFINITY.


Relevant in here too:

1 Like

I think the most important thing for me to understand is how involved and especially how long process sandboxing of canisters will take. This is an obvious improvement to the security of the canister environment, and if it won’t take too long (I am not sure what too long would be), then I think we should wait until it is implemented before moving forward with anything that will allow canisters to control lots of monetary value. This includes the Bitcoin and Ethereum integrations.


“Canister controllers are not ledgered.” - is the objective to build a money washer if ICP transactions are not recorded in a ledger? Also, if A pays for a service through a Canister - how does one know the transaction completed correctly if there is no transaction recorded? I think I am missing something here.

I also wonder about node operator security requirements. SEV has not et been implemented. Are their any integrity constraints placed on node operators (physical security, operational security, personnel, etc)? No ICP transaction on the ledger will impact the risk profile of a node operator - it now shifts.


Don’t Trust, Verify

If there is a place to verify the logic of the canister wasm, then the crooks are hard to succeed. So this risk is acceptable.

At the same time, I think this kind of infrastructure is needed:

Some possible requirements of ​Verified canister:

  1. Open source
  2. Its logic conforms to its Ricardo contract description

I totally agree that a “canister verification” service is absolutely necessary in the near future, one that can verify that a canister is:

  1. Autonomous (i.e. black hole controller)
  2. Running wasm code that’s compiled from some published open source code

It’d be even better if this canister verification service was itself an open internet service, i.e. an autonomous canister.

I’m not too familiar with a Ricardian contract, but from wikipedia it seems that it needs to be legally binding and human readable. I’m not sure how much that applies here.


Note that the system already provides the building blocks, and anyone can build such a service now. Don’t just wait for DFINITY to build everything you want, there is only so much one org can do here! Better let them focus on features that can’t be done by others (system features), and have the community build the ecosystem. I’m happy to advise anyone who wants to build this.


The above comment needs to be stickied and immortalized.

I’ve gone through the 5 stages of IC since discovering it (sometimes bouncing between them) :

  1. Curiosity
  2. Excitement
  3. Invested
  4. Doubt
  5. Acceptance

This is for you! It was made for you, the community! Dfinity provides the match, it’s up to YOU if you want to start a fire for warmth and cooking or go burn something down.

It’s laid out in the documentation. This is a democracy. If YOU don’t agree with something, YOU have to vote, and help educate others in order to make an educated vote. The capability to follow other neurons will become so powerful! There will be parties established. There will be easily accessible voting records. There will be revolutions!

I accept. I accept that Dfinity has provided a stage and it’s up to us to execute a successful performance.

If it matters to anyone, I voted no due to the following. Your risk tolerance might be higher, so please understand how it impacts you.

I think it would be unfortunate for someone to create a defi dapp with the general population assuming it behaves like other blockchains. I believe the other features should exist (immutability assurance and WASM/source code validation) before being made available for public consumption.

One could also vote Yes at this time, and wait for the next proposal (which will include the code updates). That way, you have more time to evaluate the impact.


If canisters can break out of the Wasm sandbox, then the logic verification doesn’t matter.

1 Like