On 10 October between 12:30 and 14:00 UTC the network cycle-burn-rate on the dashboard stepped from ~48 B cycles/s to ~20 B/s and has stayed there. Querying ic-api per subnet, all 42 subnets dropped at the same time and by a similar factor (0.3 to 0.5 of their previous level), regardless of size or type. Message execution rate, instruction rate and block rate did not move (4,561 to 4,686 msg/s, 14.1 to 16.1 B instr/s, 188 to 189 blocks/s, daily means 9 to 11 Oct).
No NNS proposal was executed in that window. The 2cdff28 rollout was on 8 Oct and the burn rate did not change then.
Is this a change in how the dashboard computes the metric, or did the protocol’s cycle accounting change network-wide at that time? If the latter, is the cost table in the docs still current?
Also, the 45-minute dip to ~1.4 B/s at 01:00 UTC on 11 Oct looks like a data gap rather than a network event, since execution metrics were normal through it. Am I reading this right?
Also been hearing rumors that Adam’s team and NTN DAO has jointly paused development due to internal issues such as embezzling DAO funds and widespread case of explosive diarrhea (get well soon Adam and team!)
Agreed, and we track both, separately. ICP burned is read from the ledger (burn transactions, daily, reconciled against the supply delta). Cycle burn is read from ic-api. They measure different things: cycles are consumed when canisters run, ICP is burned earlier, when someone buys cycles. They are not expected to move together day to day.
This thread is about the cycle series specifically, because it moved in a way that execution metrics do not explain. If it turns out to be a dashboard change, the ledger series will not have noticed, which is exactly the point.
Not for this series, and I would like to. What I have on-chain so far:
The ledger burn series (ICP burned for cycles) did not move across 10 Oct, which is expected either way, since ICP is burned when cycles are bought, not when they are consumed.
For consumption itself I know of per-canister canister_status (controllers only) and the CMC’s conversion totals, neither of which gives a subnet-level consumed figure. node_metrics_history is on-chain and per subnet but carries block metrics, not cycles.
Is there an on-chain source for cycles consumed per subnet that I am missing? If so I will pull it for 9 to 11 Oct and post the comparison here.
I think you should add to app monthly ICP burned x cycles per icp / 30 / 24/ 60 / 60 and show cycles per sec that is burned. Its not accurate, but you get where it should be, 0.00583 T/s.
Now comes question, from where the rest of it coming from, it sure is not minted. But for better overview need to make longer data map.
Thanks, that works. Read subnet/<id>/metrics via read_state for all 42 subnets; consumed_cycles_total sums to 12,606,966 T.
One thing worth flagging for anyone else doing this: the counter is not monotonic between reads. Twelve consecutive certified reads of pzp6e inside 17 seconds moved between 268,201 T and 268,209 T while update_transactions_total only went up. Looks like in-flight prepaid execution is counted and refunded. So a rate needs hours, not minutes. I have a baseline from 16:23 UTC today and will take a second sample tomorrow, then post the on-chain rate against the dashboard series for the same window. That should settle which of the two moved on 10 Oct.
Finalization rate on the dashboard also shows 1,700 blocks/s at 15:40 UTC today, every subnet at ~10x simultaneously, message rate flat. A subnet cannot finalize 26 blocks per second. Same pipeline, same day.
One more data point for the same day. The dashboard’s finalization rate shows 1,700 blocks/s at 15:40 UTC today and 1,500 at 14:10, against a normal 160 to 200. Per subnet on ic-api, every one of the 42 subnets jumped by the same factor at the same minute (3zsyy 3.0 to 30.3, 6pbhf 2.7 to 26.6, bkfrj 2.6 to 26.2). In the two weeks before 10 Oct no subnet exceeded 6.1 blocks/s in any 15-minute point. Message execution rate stayed flat at 5,300 to 5,700 through both spikes.
The 14:10 spike lines up with the start of today’s rise in the cycle-burn-rate series. Both are counter-over-time rates, so a timing fault in the collector would inflate both by the same factor, which is what the per-subnet data shows. Same pipeline, same day, two metrics.
This will soon (next few weeks) change and the consumed cycles total returned by /subnet/<subnet_id>/metrics will be monotonic. As you said right now it fluctuates cause outstanding prepayments are included so when they are refunded the total decreases, making it harder to build monitoring on top.
Two things, and I will tighten the wording of the first.
“Cannot” was too strong; I have no protocol ceiling to cite. What I have is the data: for each of the 42 subnets, the ic-api block-rate series in 15-minute points over the two weeks before 10 Oct. Medians run 1.6 to 3.0 blocks/s, 99th percentiles 2.3 to 4.1, and the single highest point on any subnet was 6.05 (3zsyy). At 15:40 UTC on 12 Oct that same subnet reads 30.3, 6pbhf reads 26.6, bkfrj 26.2, and every other subnet shows the same roughly 10x jump at the same minute. Message execution rate stayed at 5,300 to 5,700/s through it.
“Same pipeline, same day” means: the dashboard’s cycle-burn-rate began rising at 14:24 UTC that day, the block-rate spikes sit at 14:05 to 14:20 and 15:35 to 15:40, and both metrics are counter deltas divided by elapsed time. A timing fault in the collector inflates both by the same factor across all subnets, which is what the per-subnet numbers show. That is an inference about the collector; the measurement is the uniform factor and the flat execution.