Please don’t delete, hide, or slow mode this thread. Any attempt to do so will be noted in the next document bundle we’ll be submitting to the appropriate Swiss authorities.
Why is the current cycle balance of a canister not publically accessible information?
I’d never really thought about it, but now we’ve got TCYCLES/XTC, people are buying and selling cycles. It’s a primary means of payment for the IC but it’s opaque and obfuscated from APIs and dashboards.
Rishi and Saikat from [Hot or Not / Insert Current Name Here] said that they were given at least $250,000 a month of cycles by Lomesh Dutta in 2023 to help them scale. Further evidence has proven that the backend of the Hot or Not system is not connected to the front end. Not a single action on any of their apps could trigger any cycle burn on the IC. No real person uses those apps, but that’s orthogonal to this discussion.
Where are these cycles? When some anonymous actor puts up a bid to sell wrapped cycles, where is this extraction of wealth from our common ecosystem actually going?
Now people are selling tens of thousands of cycles via various smart contracts on the IC. Canisters (with cycle balances) are transferrable between subnets. This hidden value can proliferate throughout the IC without any checks or balances.
I can guarantee you that this is being abused.
There will be a motion proposition to make all cycle balances, and cycle transfers public, and retroactively so (if possible - cynically I think those historical transactions may reside in /dev/null.)
I strongly agree.
Cycle balances and transfers on the Internet Computer should be fully public!
This isn’t some minor UX issue it’s a core transparency failure in what’s supposed to be an open, decentralized computing platform. Cycles are the lifeblood and the primary economic layer of the IC. People are actively buying, selling, wrapping, and trading them (TCYCLES/XTC, canister sales, etc.). When real money and grants are flowing through this system, hiding the balances and flows is unacceptable. It invites exactly the kind of abuse and opacity that centralized systems get criticized for.
The Hot or Not situation you mentioned is a perfect example. Large grants handed out, yet zero visible usage or burn from actual frontend activity? That should be verifiable on chain.
Hot or Not was a marketing strategy at the time obviously.
They needed something to show that would gain the public’s attention. They needed a high profile type example of the capabilities of the network and were betting on them helping to bring usage here.
There is the Cycle Ledger that tracks transactions but it can be avoided if you transfer cycles between canisters directly. Also the reasoning for hiding transactions was risk of cycle drain attack by exposing how canister balances change publicly. But I still agree with op I’ve always thought that we’re missing something regarding how cycles are tracked and transacted. I remember also reading about the potential problem of cycles created on a malicious subnet could leak to other subnets. It would be much cleaner if we had a global blockchain accross all subnets to track all cycle balances and transactions.
So that cycles transactions At least the wrapped ones were transparent and easy to hold and trade.
Made things easy specially for DEXs and devs to move around cycles without costing a lot of fees.
But it seems recently that the XTC canister was wiped to become just a ledger and not a wrapped version of cycles.
Sonic has it under it’s control and has made it just icrc also a lot of liquidity was provided to sonic for XTC not sure if by Dfinity or someone else approve $150K
Now it’s all locked in their exchange along with cycles/ICP/XTC as there’s no way to unwrap or get XTC anymore which defeats whole thing about creating XTC.
It’s best that we move to traditional CYCLES and make it transparent or fix the XTC.
AFAIK cycles are tracked at the subnet level. What could happen is that a malicious subnet mints cycles by inflating canister balances, then transfers them to another subnet impacting the whole network.
This is something we don’t talk about enough. The security of the network doesn’t increase as the number of subnets increases, it’s actually the opposite: one malicious subnet can potentially impact the whole network.
But why, why its not on system subnet where ICP token is. Every mint call should be approved by that subnet, not independent subnets.
I would keep cycle minting on system subnet (total available), there tracked total minted and burnt. Than add tracker to every subnet to see how much they got (in canisters, app wallets).
What you suggest is half implemented since the CMC (Cycles Minting Canister) is on the NNS subnet Canister: NNS Cycles Minting - ICP Dashboard but I still believe that subnets individually track the cycle balance of the canisters they host. Also, very long term wise I think relying too much on one subnet for the architecture of the whole network is not optimal, which is why I suggested a blockchain that would be the only way to move away from this subnet centric design. I could be wrong though, there might somethings I haven’t considered.
If it is possible to do I would definitely be in favor of making all cycles transfers between canisters public and auditable
In addition, it would be great if canisters were given a system api to completely block direct cycles deposits. For certain applications that is actually an attack vector that is very difficult to stop.
Any controller of a canister can optionally make the cycles balance public, it’s just not the default. The best way of doing this (by far) is to make the canonical blackhole canister a controller of your canister. This is:
Extremely easy
Standardised
Safe for callers (no need to worry about a malicious endpoint, nor multiple builds to verify)
Cycles flow like blood through transactions between canisters between subnets. You “trust” the subnets to behave so you have this fast transfer. If you put a central ledger you delay settlement to a full cycle, probably across subnets which reduces settlement from 2 seconds to 6 seconds minimum.(optimistic settlement with historic settlement and slashing sees to be a potential solution but won’t be as long as we only have one version of replica software)
The fact that a malicious subnet can mint cycles is, I suspect, why we haven’t seen the long promised 4 node storage subnets. It would be too easy for two people to collaborate to mint infinite cycles. If we ever do see storage subnets they will likely have some other mechanism than cycles.(probably rent through the TCycles canister which is public.
Because cycles are deterministic and their burn can be measured you can use public cycles to probe a canister. Imagine you submit a password to be checked by a canister..it burns 10 cycles and is rejected..you change the first letter from “t” to “a” and that call burns 20…you now know the first letter of the password. (This is a simplified example and not realistically how passwords work, but you get the idea…cycle burn can expose secrets in the canister via burn in some cases. In previous discussions it was suggested the replica round up to the closest billion if reporting publicly, but with heavy ops like zk and hashing even chunks that big can reveal info).
Good news…if you rent a subnet or do what ever this cloud fusion (waves hands) is you don’t have to worry about cycles!
Cycles should be private by default to protect against side channel attacks (leaking secrets indirectly). Those canisters for which cycle burn related side channel attacks are not a concern can expose their current cycles balance easily as mentioned.
So basically, things alread work the way they should.
