Can Canisters hold ICP?

Developers
1

Can non NNS canisters own or store ICP? Is this a possibility in the current setup?

2

It seems they can own ICPs but to be allowed to send them, they require to be on a whitelist send_whitelist.

cf. ic/main.rs at master · dfinity/ic · GitHub

4 Likes
3

Cool, thanks for this. Seems like a canister can also be self authenticating to send. Do you know what that means?

pub fn is_self_authenticating(&self) -> bool {
    let blob = self.as_slice();
    if blob.len() != Self::HASH_LEN_IN_BYTES + 1 {
        return false;
    }
    if blob.last() != Some(&Self::TYPE_SELF_AUTH) {
        return false;
    }
    true
}
4

I think self authentication mean that the caller() from cdk-rs is a regular identity (and not a canister).

I am not sure if we could have a canister generates a self authenticating identity (a private key) and signs and send a message :thinking:

1 Like
5

You’re correct, self-authenticated ids are which humans have (or something with a key pair).

Until there are enclaves out there, there is no way for a canister to have a key pair, since dishonest nodes are able to publish them.

1 Like
6

I was wondering about a similar question, which is can I cannister run a service or return a result which the caller has to pay for. Like if I had wanted to run an App called “show me the animal” which cost a nickel, and if you pay a nickel it returns a picture of the animal. And also whether or not the canister could take the nickel it earned from showing somebody a picture of a goat and send the nickel to pay for some other service like provided some other canister. LIke if there was another canister called “draw an animal”, which cost a penny. So If somebody called show me tha animal (goat) the canister coud call “draw the animal” (goat) pay a penny, and make a cool 4 cents profit, once the picture was returned to the original caller. I dont 'see anything in the Motoko documentation which shows how to do things like that using the ICP tokens.

1 Like
7

Whoa. So canisters can’t have ICP right now? Or at least can’t send them?

Who controls the whitelist?

Could we use the key sharing that Dom mentioned in the ethereum integration post to generate a key that doesn’t really exist but that can be recombined?

This seems to break a large number of applications that I was considering.

1 Like
8

We at our small local dfinity community think that they’re preventing another ICO boom this way.

Maybe we could vote it out in nns… I don’t know.
We need an on-chain exchange and some other tokens, to transfer value automatically. ICP won’t work.

2 Likes
9

But why? It just seems odd. It looks like you can send the ICP to a canister and you can notify the canister via notify that it was sent ICP, but once it is there, it can not leave? Maybe this interface is just for cycles?

I think it will return to the controller of the canister if the canister is destroyed, but I haven’t confirmed that. Maybe they can be converted to cycles by the canister? This would be a decent loop. It looks like the Fund type in the ledger can be either cycle or ICP, but I’m having trouble figuring out how the code uses or distinguishes those?

Overall I don’t understand why an actor can send cycles to other actors but can’t send ICP. Don’t they use the same ledger?

1 Like
10

I think ICP balances are recorded in a NNS Ledger Canister, but cycle balances are maintained as internal state in each individual canister.

Not sure what the reason is for this distinction.

1 Like