In the docs of IC management canister interface it is mentioned that “There is no restriction on who can invoke this method”.
I wonder if there is a way to restrict other callers that deposit cycles using IC Management Canister’s deposit_cycles method other than controllers and assigned principals.
If anyone has a solution please let me know.
Thanks!
A method needs to be implemented in a canister to actually be able to receive and accept cycles. Within this method implementation, you need to call the accept cycles cdk method to actually accept the cycles. Any form of logic can be implemented e.g. allowlist to conditionally accept the cycles.
Edit: See later posts
I don’t think this keeps others from dumping cycles onto your canister via other cycle accounting methods.
How would you increase the cycle balance of another canister then? Maybe you could sent cycle tokens once we have a ledger for it. But I suppose these tokens wouldn’t be actual cycles on the canister unless consumed? (haven’t followed along in the other cycle ledger thread recently)
Whatever process Dank uses for XTC burn sends the cycles to whatever canister you want:
dfx canister --network=ic --no-wallet call aanaa-xaaaa-aaaah-aaeiq-cai burn “(record { canister_id= principal "some-canister’s-principal-id"; amount= (2000:nat64)})”
I think you can even send these to canisters that don’t have a wasm installed. I don’t think you can gate them.
Ah looks like you’re right, found this post that mentions it Question about deposit_cycles
anyone can call deposit_cycles. wallet_receive does not exist to work around a limitation of deposit_cycles, but rather because when it was created, deposit_cycles did not exist
Correct. And to add: wallet_receive can still be useful because there is no on_cycles_deposited hook available. If you want to be notified of receiving cycles the depositor has to ping you somehow (or you check with timers)
Thank you for your response. Unfortunately, there doesn’t seem to be a straightforward solution. Even if the depositor intentionally deposits without notifying me, setting up a timer to monitor the cycle balance would also incur additional costs. It would be ideal if there were canister settings that allowed us to customize who can deposit cycles, with the default option being that everyone can deposit.
If you have any other solutions related to this forum post, feel free to share them! 
Hi @ahdrahees, I want to make sure you know about the possibility like @Severin is saying, that a canister can accept cycles in a regular canister method using the msg_cycles_accept/msg_cycles_available system apis. Callers can put cycles into the call and the callee (you) can accept them within the call. This way the caller won’t have to notify you separately and you won’t have to set up timers to monitor the cycles balance.
A different option and possibility that you can use now, is leverage the open CYCLES-BANK by the CTS. The CYCLES-BANK - canister-id: wwikr-gqaaa-aaaar-qacva-cai - is an ICRC-1 ledger that holds cycles 1:1 and send cycles in or out of the ledger using the cycles_in, cycles_out, and mint_cycles methods. The CYCLES-TRANSFER-STATION uses the CYCLES-BANK for the mint, transfer, and trade of the cycles at the CTS order-book market trading platform. If this option is a better fit for your use-case, let me know, I can help with the integration/implementation.
I’m curious about your use case for not wanting cycles? Is it potentially messing up your accounting somewhere? If you don’t want them you can send them to me. 
At one point we had someone build a ‘cycle dao’ where you could mint out tokens to users that sent you cycles to support your services. It might have some interesting code for you: Completed: ICDevs.org - Bounty #17 - A DAO for Cycles - $10,000 - ht: cycle_dao