# A couple of new CMC features: ICRC memo, and automatic refunds **URL:** \ **Category:** Developers\ **Tags:** nns\ **Created:** [February 19, 2025, 7:51pm UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396 "2025-02-19T19:51:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![daniel-wong](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/daniel-wong/32/6248_2.png) [@daniel-wong](https://forum.dfinity.org/u/daniel-wong)\ **Post date:** [February 19, 2025, 7:51pm UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/1 "2025-02-19T19:51:29Z")
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` `memo`s are as follows: ```plaintext /* 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](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/dfinity/ic%24+f%3Acmc%20f%3A%5C.did%20notify_.*%5C%20%3A&patternType=regexp&case=yes&sm=0), 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. ---
**Author:** ![charm](https://avatars.discourse-cdn.com/v4/letter/c/fbc32d/32.png) [@charm](https://forum.dfinity.org/u/charm)\ **Post date:** [February 20, 2025, 5:01am UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/2 "2025-02-20T05:01:33Z")
nice new features thanks ser ---
**Author:** ![marc0olo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/marc0olo/32/17290_2.png) [@marc0olo](https://forum.dfinity.org/u/marc0olo)\ **Post date:** [February 20, 2025, 9:37am UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/3 "2025-02-20T09:37:38Z")
> [@daniel-wong](#): > > minus one ICP transfer fee is the fee really this high? 🤔 ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [February 20, 2025, 10:10am UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/4 "2025-02-20T10:10:42Z")
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 🤷 ---
**Author:** ![daniel-wong](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/daniel-wong/32/6248_2.png) [@daniel-wong](https://forum.dfinity.org/u/daniel-wong)\ **Post date:** [February 20, 2025, 10:44am UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/5 "2025-02-20T10:44:18Z")
Sorry, what I meant is “1x ICP transfer fee”. I did NOT mean that the fee is 1 ICP! ---
**Author:** ![cryptoschindler](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/cryptoschindler/32/26_2.png) [@cryptoschindler](https://forum.dfinity.org/u/cryptoschindler)\ **Post date:** [March 5, 2025, 1:13pm UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/6 "2025-03-05T13:13:56Z")
> [@daniel-wong](#): > > Also note that other `notify_*` methods can be used, not just `notify_mint_cycles`. In each case, a different `memo` would be required. 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 ---
**Author:** ![daniel-wong](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/daniel-wong/32/6248_2.png) [@daniel-wong](https://forum.dfinity.org/u/daniel-wong)\ **Post date:** [March 5, 2025, 4:44pm UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/7 "2025-03-05T16:44:00Z")
> 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_. ---
**Author:** ![cryptoschindler](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/cryptoschindler/32/26_2.png) [@cryptoschindler](https://forum.dfinity.org/u/cryptoschindler)\ **Post date:** [March 6, 2025, 8:29am UTC](https://forum.dfinity.org/t/a-couple-of-new-cmc-features-icrc-memo-and-automatic-refunds/41396/8 "2025-03-06T08:29:38Z")
> [@daniel-wong](#): > > 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. Thank you, that makes a lot of sense! > [@daniel-wong](#): > > 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_. 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).