While the IC canisters use the “reverse gas” model, canister method calls can have cycles attached to them. Developers can use this to implement (a form of) the direct gas model for their canisters, where a method requires the caller to provide sufficient cycles to pay for the method’s execution. But is this actually used in the wild? Does anyone know of canisters that require such direct gas, apart from a few methods on the IC management canister?
If yes, I’d also be interested to learn how they implement authorization, given that external users can’t directly own cycles (so the external users would have to proxy the calls through a canister).
I think I misunderstood your question the first time. Using XTC would require the user to send the tokens in a separate transaction and I think what you’re saying is you want them to send cycles when they call the canister’s interface. Is that right?
It is really only useful for inter-canister transactions…but that is one of the reasons that on-chain wallets are so fascinating. I could see applications in the future that require an on-chain wallet for compute-heavy requests so they can pay for their own cycles.
Thanks for the answers! Let me provide some more context. The reason I’m asking is because we (in particular, DFINITY’s SDK team) would like to eliminate the cycles wallet from the dfx workflows for newcomers. The idea is to replace it with a global cycles ledger, that would hold cycles of many principals. We’re aware that the community has already built such ledgers (dank/XTC and Toniq/WTC, for example), and we’d want to come up with a community standard that would allow a dfx user to choose such a ledger freely.
One cycles wallet functionality that is difficult to replace is proxying calls with cycles. The reason it’s difficult is the known problem with outstanding calls and canister upgrades on the IC; basically, a malicious user could block a cycles ledger from upgrading. For the cycles wallet this is less of an issue, because it holds the cycles of only one user, and would perform way fewer calls, so it’s in practice much easier to ensure that force upgrades are safe. Our current thinking is to not include this functionality in the standard until the issue with the IC is resolved. But this only makes sense if the “call with cycles” functionality isn’t really relevant for users for the majority of use cases, i.e., if there aren’t any major use cases that rely on direct gas.
Which is why I was asking whether there are any usages of the direct gas model in the wild.
We’re planning on providing micropayments but we haven’t exactly fleshed what its going to look like yet. We aren’t using direct gas out in the wild. But, I’d hate to see this feature taken away I have a bunch of other smaller ideas which rely on this being a feature.
Ahh…in that case there may be. See this thread…if what you are think will break the assumptions made in this discussion, please let us know because we are building a system around the fact that sending cycles is both atomic and “free”: Cycle cost to pass cycles
Just to be clear, nobody is proposing removing the ability to send cycles with a call. The question was whether this ability is currently regularly used by canisters to ask end-users to pay for services with a direct gas model.
If it was, then there wouldn’t be much point in building a cycles ledger to replace per-user cycles wallets, as users would need to deploy separate cycles wallets anyway in order to interact with canisters that require direct gas. But it doesn’t seem to be the case.
Thanks for the pointers to the cycles DAO, I’ll have a look!