Delete Unused Canisters and Consolidate Cycles to Avoid Recurring Fees

Developers
1

Hey devs,

With the recent introduction of recurring canister fees on the Internet Computer (IC) protocol, it’s more important than ever to keep your canister portfolio lean. These fees can quietly drain cycles from idle or unused canisters, leading to unnecessary asset losses over time. The good news? You can proactively delete older canisters and redirect their remaining cycles to your active ones. This not only prevents cycle burn from fees but also consolidates your resources—meaning you’ll burn less ICP overall when topping up, as you’re recycling cycles instead of minting new ones from scratch.

In this post, I’ll walk you through the simple process using dfx commands. I’ve also included a YouTube video demo to make it even easier to follow along.

Why Do This?

  • Avoid Cycle Drain: The new recurring fees hit all canisters, even dormant ones. Deleting them stops the bleed.
  • Consolidate and Save ICP: By withdrawing cycles to a useful canister, you’re essentially recycling—reducing the need to convert (burn) more ICP into cycles for top-ups.
  • Streamline Your Projects: Fewer canisters mean less management overhead and a cleaner developer experience on the IC.

Important Note: Always back up any data or code from the canister before deletion, as this process is irreversible. Also, ensure you’re on the mainnet (--network ic) and have the necessary permissions (e.g., as the controller).

Step-by-Step Guide

  1. Identify Canisters to Delete:
    Use dfx canister status or check your deployment history to find unused or older canisters. Note their IDs.

  2. Stop the Canister:
    Before deletion, stop the canister to ensure it’s not processing any operations. Run:

    dfx canister stop <canister_id> --network ic

    Replace <canister_id> with the ID of the canister you want to delete.

  3. Delete and Withdraw Cycles:
    Delete the canister and send its cycles to another one. This is the key step for consolidation:

    dfx canister delete <canister_id_to_delete> --withdraw-cycles-to-canister <canister_id_to_top_up> --network ic
    • <canister_id_to_delete>: The ID of the unused canister.
    • <canister_id_to_top_up>: The ID of your active canister that will receive the cycles.

  4. Verify the Transfer:
    After deletion, check the cycle balance of the target canister using dfx canister status <canister_id_to_top_up> --network ic to confirm the cycles have been added.

Video Demo

For a visual walkthrough, check out this YouTube video where I demonstrate the exact commands in the terminal:
YouTube Video Link Here

Tips and Best Practices

  • Batch Process if Needed: If you have multiple canisters, script this out for efficiency.
  • Monitor Fees: Keep an eye on IC updates via the DFINITY forum or docs to stay ahead of any fee changes.
  • Troubleshooting: If you encounter errors (e.g., insufficient permissions), ensure you’re the controller. Refer to the IC docs on canister management for more details.

By consolidating like this, you’re not just avoiding losses—you’re optimizing your ICP burn rate for long-term sustainability. If you have questions or run into issues, drop a comment below!

Cheers,
Richard

5 Likes
3

Wait, what? This might sound like a stupid question since I should probably know, but what new canister fees have been recently introduced?

5

It is true. Page 8 section 3.4 of the Mission 70 white paper “Introducing a modest recurring base cost per canister”.

6

Did you really vote on the first part of Mission 70 without even reading the white paper? :thinking:

Page 8 section 3.4 says “Introducing a modest recurring base cost per canister”.

I will also always be a Dick Hery since that is literally my name.

7

Introducing a modest recurring base cost per canister, potentially coupled
with a reduction in the one time installation fee, would better align cycle pricing
with actual resource consumption and reduce distortions in application archi-
tecture that arise purely from pricing asymmetries.

Well, even though I’ve have little doubt about its application since the first proposals started being approved, the chapter you are referring to uses “would” as a tense and, to my knowledge, this hasn’t been implemented nor proposed yet. Therefore, I guess we cannot really say - at least at this point - that new recurring fees have been introduced (unless of course I missed it, please correct me if I’m wrong). But I understand what you meant now, thanks for the feedback.

1 Like
8

Great tutorial. You should make more tutorials.

Maybe create a geocaching app where you go on missions and collect nfts.

1 Like
9

NFT app for travelers, travel there get NFT, can be really interesting. Later you find out you missing NFT and need to visit some Mexican druglord. :smiley:

1 Like
10

The proposal that passed yesterday was nothing but a motion proposal so nothing has actually changed on the network yet. Dfinity gets what Dfinity wants though so seeing it “introduced” in the Mission 70 white paper is a clear indicator it is coming.

The last time compute increases were implemented 15 months ago it followed this same path. Motion proposal to create discussions around the subject then throw the implementation into a routine upgrade. (Motion proposal 133388 sparked the discussion and Revise Elected GuestOS Versions proposal 134032 implemented the changes with a 97% yes on the NNS). There is no reason to assume this will be different especially since this portion of mission 70 didn’t get the luxury of a well discussed X space like we are expecting before the rest of Mission 70 is proposed.