Question On `deposit_cycles` spec

Developers
1

ref : https://sdk.dfinity.org/docs/interface-spec/index.html#ic-deposit_cycles

This method deposits the cycles included in this call into the > specified canister.
There is no restriction on who can invoke this method.

Does this mean anyone can deposit cycles into any canister? If so, can a canister reject the cycles somehow?

2

A canister cannot reject the cycles, and yes anyone can deposit cycles in other canisters. Do you see a downside to being able to send cycles?

3

:sweat_smile: well kinda, at least for the following idea:

  1. I develop FooService, which is very very good at creating new foos.
  2. Foos are in demand, and my service is the best at what it does, so I spin up a FooFactory canister, which can provision new FooService canisters for people with an unset controller. This way users can be assured I can’t do anything bad with their data!
  3. However, I want to be rewarded for my work, so I create an accept_cycles method the provisioned FooService canisters. This method just accepts the sent cycles, but remits some % back to my “HomeCanister”.

I thought of a bunch of neat ideas around building “open” services using this pattern. Solves: “How can I build services where users own their data, but I get rewarded?”

Alternatively, the cycles balance could just be tracked on the canister, and once an update method is fired, checks for changes and handles the remittance. But, having the ability to control exactly how your canisters accepts cycles would be nice. Another solution might be something like the current “update” trigger thats fired on deposit.

2 Likes
4

Interesting ideas!

Yeah, that use case (charge based on cycles deposited) isn’t supported. But that might not be the best remittance model, tying it to the cycles deposited and consumed.

You control the FooServce code, and can reward yourself in whatever way you want. Maybe you should simply make your FooService remit you by transferring some cycles whenver “a foo is created”? This way, you are charging something that the user care about and understands (probably more so than charging the user when they let “their” FooService just sit around and have to occasionally pay for storage), and it it’s detangled from the mechanism of fueling the canister.

4 Likes
5

That is also a good solution! However, I still might want to advocate for at least triggers on deposit_cycle. I think in the long run it makes sense even if not in this application.

2 Likes
6

Also for the general canister ac counting, to be on top of the cycles your canister has and to know where each cycle came from.
Maybe a way to check a log of each cycle deposit and who sent it or maybe a simple cycle deposit trigger function with the depositor-wallet and the mount of the cycles as the parameters.

1 Like