Canister Cycle Limits and Burning Cycles šŸ˜¬?

Developers
1

Hey all! Can anyone shed some more-official light onto how many cycles a canister can hold? Iā€™ve been experimenting it looks like 10^14.

Iā€™m working on a goofy recreation of the ā€œMillion Dollar Homepageā€, and my plan was to let ā€œusersā€ buy pixels by sending Cycles along with their request. It all works, but since the canister the full once you deploy to your local replica, all the cycles I send just get refunded.

Is there a way to burn cycles that isnā€™t just executing a big for loop? Maybe a way to extract cycles from a canister? Or, maybe just a way to configure how many cycles the canister is deployed with?

2 Likes
2

Have you seen this documentation Managing cycles :: Internet Computer?

I suspect your code needs to add a call to ExperimentalCycles.accept(amount : Nat) : Nat to actually accept the funds sent on the call - unless explicitly accepted, the funds will be refunded.

To transfer funds with an intercanister call, call ExperimentalCycles.add(amount : Nat) : () before making the call.

Iā€™m not sure how to arrange for a JS call to transfer funds from the user wallet to your service, but hopefully someone else can answer that one (and your other questions).

Best,
Claudio

2 Likes
3

Hey @claudio !

I have! The issue Iā€™m having is the canister refunds most of the cycles I send, because I believe Iā€™m at the canisterā€™s cycle capacity already.

4

Ah, sorry, I didnā€™t read your question carefully enough.

Iā€™m not aware of any way for dfx to specify the initial cycle allocation for a local install.

As a workaround, which is kinda slow and expensive, you can get your actor to dynamically install a dummy canister using an actor class that you either discard or let hang around. Any cycles you put on the actor class instantiation will be transferred to the fresh canister and die if and when that canister is deleted, freeing up capacity in the main canister.

This repo provides two methods, burn and burnFast, One is slow because it creates and destroys the other canister, requiring more rounds of concensus. The other is fast, because it just leaks the fresh canister after transferring the cycles.

Clearly, this is a hack.

2 Likes
5

@claudio thank you so much - This Perfect!ā€™

Also,

Didnā€™t know about these management canister functions. Woo!

1 Like
6

Iā€™ve cleaned up the examples a bit and added a third method:

  • burn just creates a new actor, passing cycles to it, but doesnā€™t cleanup the new actor;
  • burnBetter uses the systemā€™s management canister to additionally delete the temporary actor.
  • burnBest uses the systemā€™s management canister to just create and delete an empty canister, without even installing a Motoko actor (or requiring a dummy Motoko actor class).
3 Likes
7

Iā€™ve been told that dfx 0.6.24 will let you specify cycles on dfx canister create and dfx deploy, so you can avoid the hack.

4 Likes
8

Is there any documentation for the limits on cycle allocations of canisters on the Mercury network?

1 Like