SNS canister cycles management

Developers
1

Question to all SNSs out there: how do you manage your SNS canister cycles?

  • The Internet Computer dashboard gives a nice overview of all the cycles of SNS controlled canisters and, contrary to “normal” canisters, cycle info for SNS controlled canisters is public via the call get_sns_canisters_summary in the SNS’ root canister.
  • Out of the box, there is not automate way for SNSs to manage the cycles of their canisters, afaik. SNSs have to build their own solution or manually topup their canisters. What are the solutions out there?
  • For non-SNS projects, I’ve been using CycleOps quite frequently. It works well and they are continuously adding new features for better management. This solution also works for SNSs when you add the blackhole canister as controller to all the SNS canisters which is an additional proposal. Have other SNS projects been using CycleOps for cycle management?

Curious to hear how other projects are managing cycles of SNS controlled canisters.

5 Likes
4

For OpenChat we built a CyclesDispenser canister (we built this before CycleOps was an option, so we’ve never actually tried CycleOps).

This canister checks its cycles balance every 5 minutes using a canister timer (you can find the code here) and if it is below some threshold it attempts to burn ICP into cycles. So in order to keep it running it must be topped up with ICP.

All of our other ‘top level’ canisters request cycles from the CyclesDispenser whenever their cycles balance drops below a threshold. They check their cycles balances at regular intervals using canister timers.

Whenever we add a new ‘top level’ canister we need to add it to the CyclesDispener’s whitelist via proposal. We actually did that just yesterday for our new Escrow canister (see here).

Then the thousands of User, Group and Community canisters all request cycles from their LocalUserIndex/LocalGroupIndex canister whenever their cycles balance drops too low.

We avoid using heartbeat or regular canister timers in these canisters because there are too many of them, instead we check the cycles balances on receipt of update messages.

This in theory means that a canister could eventually run out of cycles if it remains idle, but this hasn’t been an issue so far because we upgrade them every week or 2 at which point they will be topped up if needed.

For the SNS canisters, we use a canister timer job which calls get_sns_canisters_summary every 24 hours, it then checks if any are below some threshold, and if so, tops them up. You can find the code here.

4 Likes