A couple of new CMC features: ICRC memo, and automatic refunds

Developers
1

Hello, ICP developers!

I am pleased to announce a couple of new features in the Cycles Minting Canister (CMC):

1. Send ICP via ICRC Methods

You can now send ICP to the CMC via icrc1_transfer and icrc2_transfer_from. This unlocks approve+spend use cases (see the “Approve+Spend” section below).

Previously, only the (legacy) transfer method was supported. This was because you had to use the memo field of type nat64. Whereas, the newer icrc* transfer methods have a memo field of type blob.

CMC now considers these memo fields equivalent up to 64-bit unsigned little endian conversion.

The CMC methods that require ICP, along with their associated blob memos are as follows:

/* notify_create_canister */ blob "\43\52\45\41\00\00\00\00"
/* notify_top_up          */ blob "\54\50\55\50\00\00\00\00"
/* notify_mint_cycles     */ blob "\4d\49\4e\54\00\00\00\00"

2. Automatic Refund

If you send ICP to the CMC, but do not use one of the special memo values that CMC recognizes, then, you can call any of the notify_* methods, then, the CMC will send the ICP back to the address that it came from (minus one ICP transfer fee). This can be used to “undo” mistakes.

Thanks!

We really hope everyone enjoys these new features. As always, your continued support of the Internet Computer is greatly appreciated!

ADDENDUM: Approve+Spend

Earlier, we said that approve+spend use cases are enabled by these enhancements. This section expands on that. Let us explain using an example.

  1. Alice calls icrc2_approve to authorize Bob to spend Alice’s ICP.
  2. Bob transfers ICP belonging to Alice to the CMC by calling icrc2_transfer_from.
  3. Bob calls notify_mint_cycles on the CMC.
  4. CMC mints cycles, and those cycles belong to Bob.

In this way, Bob is able to get cycles using Alice’s ICP.

Note that Bob can allow Charlie to call notify_mint_cycles, and in this alternative scenario, the cycles would end up belonging to Charlie (in step 4). The principal who is authorized to call notify_mint_cycles is controlled by the CMC subaccount that Bob sends the ICP to.

Also note that other notify_* methods can be used, not just notify_mint_cycles. In each case, a different memo would be required.

9 Likes
2

nice new features thanks ser

3

is the fee really this high? :thinking:

4

No, the fee is 0.0001 ICP, but the CMC is not allowed to mint ICP and it has to pay for the transfer somehow :person_shrugging:

5

Sorry, what I meant is “1x ICP transfer fee”. I did NOT mean that the fee is 1 ICP!

1 Like
6

Why do we need to set the memo and use a specific notify_* method. Isn’t the intention clear from using the specific method?

Also, is this flow possible right now? If not, can it be enabled?

  1. Alice calls icrc2_approve to authroize the CMC to spend Alice’s ICP.
  2. Alice calls mint_cycles/top_up/create_canister on the CMC
  3. The CMC tries to icrc2_transfer_from and if successful performs the action
2 Likes
7

Why do we need to set the memo and use a specific notify_* method. Isn’t the intention clear from using the specific method?

Yes, but anyone is allowed to call notify_top_up. (This is so that a good samaritan can come along and help you complete your top up if you crash after sending the ICP, but before calling notify_top_up.) Therefore, we cannot use the caller of notify_top_up to control what operation the ICP is used towards. Instead, memo ensures that the person who sent the ICP is the one who controls what operation will be performed.

You are right that notify_top_up is redundant vs. the memo. We maybe could have come up with a generic notify_icp_sent method. In that case, CMC would read the memo and deduce the operation. It is not so clear how notify_icp_sent would be able to replace notify_create_canister though, because notify_create_canister takes additional information, i.e. information that cannot be gleaned from the transaction.

is this flow possible right now?

No. Seems like a really good idea though!

In lieu of this feature being directly in CMC itself, I think what you want might be possible via another proxy canister. So, user U authorizes this new canister, then calls the canisters mint_cycles method. Then, the canister sends U’s ICP to CMC, and also takes care of calling CMC’s notify_mint_cycles method. This proxy is ofc not as good as being a direct feature of CMC, but it has the advantage that anyone can do it right now.

1 Like
8

Thank you, that makes a lot of sense!

Yes, you’re right. Maybe it’s worth adding if enough people deem it useful. I guess the property that anyone is able to help out and call the notify_* methods on the canister is lost this way, but i think that’s fine as it’s a single step process anyways (apart from the initial approval).