How to recycle cycles in a canister that are about to be deleted

Since we have deployed the contract to a relatively congested subnet, we plan to redeploy the contract to a relatively idle subnet before the business is fully started.

Question:

  1. How should we reclaim the cycles in canister before calling IC.delete_canister(xxx) to delete the sub-canister?
  2. When deleting the main canister and want to return its cycles balance, is it correct to use the command and argument dfx canister delete --withdraw-cycles-to-dank main_canister ?
1 Like

You need to make the to-be-deleted-canister send as many cycles out as possible on its own. You can’t withdraw from outside of the canister.

Do you have a reason to use the --withdraw-cycles-to-dank flag and know what it does? Otherwise I would drop that

I don’t quite understand what you mean. Do you mean to use the ic.deposit_cycles(xxx) function to reverse the transfer?

Maybe a scenario makes it easier to discuss. Assume canister A wants to delete canister B but also wants to recover as many cycles as possible. You want to do it roughly this way:

  1. A installs new code to B that knows how to send cycles
    • Of course you can skip this step if B already has that capability
  2. A instructs B where to send cycles
  3. B uses either ic.deposit_cycles or some other call with attached cycles to transfer as many cycles out as possible
    • You need to keep a few cycles back to pay for actually making that transfer. If you get an error with the message Call failed to send you most likely added too many cycles.
  4. A can now ic.delete_canister(<B>) with minimal cycles loss
2 Likes