FEATURE REQUEST: Provide a mechanism to transfer cycles from wallet canisters in the NNS "Canisters" interface

[saikatdas0790]

An updated interface could even let us filter by canister type or have separate tabs for application vs wallet canisters.

And then wallet canisters could have an additional "Transfer" button

[peterpeterparker]

I'm not sure I understand you feature request, do you mean being able to transfer cycles from a canister from the wallet screen (nns.ic0.app/wallet/accoun_id). Like having a button there that open a modal where you can select canister and transfer cycles without the need to switch different screens?

If no, can you try to rephrase or give more context/explanation?

Thanks in advance for the feedback.

[saikatdas0790]

I'm not sure I understand you feature request, do you mean being able to transfer cycles from a canister from the wallet screen (nns.ic0.app/wallet/accoun_id). Like having a button there that open a modal where you can select canister and transfer cycles without the need to switch different screens?

If no, can you try to rephrase or give more context/explanation?

Thanks in advance for the feedback.

@peterpeterparker
No, I mean the "Canisters" tab.
Right now, if I want to transfer/top up cycles to a canister in the list of canisters in that tab, the only way to do it is by burning ICP to convert to cycles and then that gets credited to that canister. This is done by pressing the "Add cycles" button inside the cansiter details page.
What I'm asking is for those canister screens to have additional button like "Transfer" that lets us transfer cycles out of that canister to a destination canister.

The primary use case for this is, when topping up from the NNS, I will right now always have to convert ICP to cycles in real time when I want to top up. But I might also want to do the conversion at a different time when the ICP -> cycles rate is more favourable and do the topup when I need to.

Doing the above currently requires us to use dfx and deploy a cycles wallet to custody cycles but it would be easier to just do this via the NNS

[peterpeterparker]

Thanks for the detailed explanation @saikatdas0790, this is now crystal clear.

However and unfortunately, I don't think this is possible without changes in the IC specification.

Indeed, to transfer directly with a single unique update call from canister A to B there is currently no other way than calling deposit_cycles within canister A.

As such a thing leads to custom implementation, it's difficult or not possible to implement a generic feature in NNS-dapp.

Because of above reason, I gonna close this feature request. For sure we keep in mind if the spec would ever evolve.

Thanks again for sharing the idea!

[saikatdas0790]

Thanks for the detailed explanation @saikatdas0790, this is now crystal clear.

However and unfortunately, I don't think this is possible without changes in the IC specification.

Indeed, to transfer directly with a single unique update call from canister A to B there is currently no other way than calling deposit_cycles within canister A.

As such a thing leads to custom implementation, it's difficult or not possible to implement a generic feature in NNS-dapp.

Because of above reason, I gonna close this feature request. For sure we keep in mind if the spec would ever evolve.

Thanks again for sharing the idea!

@peterpeterparker
Just a quick follow up question. I understand that this might not be possible for all generic questions, but what about canisters that contain the wallet canister?

I believe the NNS could call the send method on the wallet canister like how the dfx calls it to transfer cycles to a destination canister. That is what my original request was around. Thoughts?

[peterpeterparker]

With "wallet canister" I guess you mean a cycles wallet?

So basically if I understand you correctly, your idea is to implement a function that transfer cycles between canisters if these are linked to cycles wallets or implement the wallet_receive and wallet_send functions.

I'll reopen the feature request in that case since it does not sounds like technically not feasable.

However, worth to note that, as far as I can tell, there is no way to detect if such functions are supported. Therefore implementing such a feature would be a bit a feature that "might or might not work not guarantee". So, not sure it is the kind of feature the dapp should offer but not my call.

I'll share with the team. Let's see if this gets some up vote by the community.

[saikatdas0790]

With "wallet canister" I guess you mean a cycles wallet?

So basically if I understand you correctly, your idea is to implement a function that transfer cycles between canisters if these are linked to cycles wallets or implement the wallet_receive and wallet_send functions.

I'll reopen the feature request in that case since it does not sounds like technically not feasable.

However, worth to note that, as far as I can tell, there is no way to detect if such functions are supported. Therefore implementing such a feature would be a bit a feature that "might or might not work not guarantee". So, not sure it is the kind of feature the dapp should offer but not my call.

I'll share with the team. Let's see if this gets some up vote by the community.

@peterpeterparker

Yes, I meant the cycles wallet. I'm not completely sure what you mean when you say

between canisters if these are linked to cycles wallets

What I'm simply imagining happening is there are specific Candid endpoints on the cycles wallet that pertain to transferring cycles from itself to a destination canister. If these exist on a particular canister, the NNS can assume that this canister is a cycles wallet. And then check if the NNS principal ID is added as a controller.

If yes, it should simply be able to call the transfer function on the cycles wallet canister to transfer cycles from itself to a destination canister. Hence, the NNS can provide a simple transfer interface when we navigate into the cycles wallet canister in the NNS interface.

At least, that is how I was imagining it would work in my head :)