# Dashboard cycle-burn-rate dropped ~58% in one step on 10 Oct, every subnet, computation unchanged. Metric change or protocol change? **URL:** \ **Category:** Developers\ **Created:** [October 11, 2026, 3:05pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046 "2026-10-11T15:05:30Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 11, 2026, 3:05pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/1 "2026-10-11T15:05:30Z")
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? ---
**Author:** ![Henn91](https://avatars.discourse-cdn.com/v4/letter/h/edb3f5/32.png) [@Henn91](https://forum.dfinity.org/u/Henn91)\ **Post date:** [October 11, 2026, 3:34pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/2 "2026-10-11T15:34:27Z")
I think its better to make app that tracks 30 days ICP burn (ICP that is actually burned), NOT cycle burn. ---
**Author:** ![Lorimer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lorimer/32/17601_2.png) [@Lorimer](https://forum.dfinity.org/u/Lorimer)\ **Post date:** [October 11, 2026, 3:49pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/3 "2026-10-11T15:49:43Z")
Interesting, @stefan.schneider do you know what happened here? ---
**Author:** ![MechanisusAF](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mechanisusaf/32/40225_2.png) [@MechanisusAF](https://forum.dfinity.org/u/MechanisusAF)\ **Post date:** [October 11, 2026, 3:50pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/4 "2026-10-11T15:50:35Z")
I’m no expert but I think the cycle-burn-rate dropped ~58% ---
**Author:** ![MechanisusAF](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/mechanisusaf/32/40225_2.png) [@MechanisusAF](https://forum.dfinity.org/u/MechanisusAF)\ **Post date:** [October 11, 2026, 3:54pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/5 "2026-10-11T15:54:18Z")
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!) No Canisters = No burn ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 11, 2026, 3:57pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/6 "2026-10-11T15:57:50Z")
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. ---
**Author:** ![Lorimer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lorimer/32/17601_2.png) [@Lorimer](https://forum.dfinity.org/u/Lorimer)\ **Post date:** [October 11, 2026, 3:58pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/7 "2026-10-11T15:58:47Z")
Have you tried checking onchain metrics directly rather than via the off-chain API? ---
**Author:** ![Henn91](https://avatars.discourse-cdn.com/v4/letter/h/edb3f5/32.png) [@Henn91](https://forum.dfinity.org/u/Henn91)\ **Post date:** [October 11, 2026, 3:58pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/8 "2026-10-11T15:58:53Z")
I think real burn rate is like 0.00583 T a sec, at least that is based on icp we burned 30 days ago to today. ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 11, 2026, 4:02pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/9 "2026-10-11T16:02:42Z")
> [@Lorimer](#): > > Have you tried checking onchain metrics directly rather than via the off-chain API? 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. ---
**Author:** ![Lorimer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lorimer/32/17601_2.png) [@Lorimer](https://forum.dfinity.org/u/Lorimer)\ **Post date:** [October 11, 2026, 4:10pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/10 "2026-10-11T16:10:55Z")
You can query **`consumed_cycles_total`** per subnet via the management canister’s **`subnet_metrics`** method, then aggregate across all subnets. ---
**Author:** ![Henn91](https://avatars.discourse-cdn.com/v4/letter/h/edb3f5/32.png) [@Henn91](https://forum.dfinity.org/u/Henn91)\ **Post date:** [October 11, 2026, 4:13pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/11 "2026-10-11T16:13:55Z")
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. ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 11, 2026, 4:26pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/12 "2026-10-11T16:26:45Z")
Thanks, that works. Read `subnet//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. ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 12, 2026, 4:16am UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/13 "2026-10-12T04:16:13Z")
The dip repeats: 00:50 UTC today, same V shape over about two hours, execution metrics flat through it. Looks like a nightly job on the pipeline. ---
**Author:** ![quinto](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/quinto/32/26369_2.png) [@quinto](https://forum.dfinity.org/u/quinto)\ **Post date:** [October 12, 2026, 10:34am UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/14 "2026-10-12T10:34:43Z")
Some data still doesn’t add up. For example, [https://dashboard.internetcomputer.org/network/subnets/x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae](https://dashboard.internetcomputer.org/network/subnets/x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae) shows that the cycles burn rate was 0 for extensive periods of time, but transactions per second held stable. This would point to an error in data collection, no? ---
**Author:** ![WebTreeSoftwareSolut](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/webtreesoftwaresolut/32/40772_2.png) [@WebTreeSoftwareSolut](https://forum.dfinity.org/u/WebTreeSoftwareSolut)\ **Post date:** [October 12, 2026, 4:06pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/15 "2026-10-12T16:06:31Z")
This is… interesting. Whether or not you choose to trust the dashboard api, I think most people want to see the burn rate measured in **dollars**. you can see it measured in **dollars** : # [Here](https://ckpayment.app) ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 12, 2026, 7:45pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/16 "2026-10-12T19:45:53Z")
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. ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 12, 2026, 7:47pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/18 "2026-10-12T19:47:59Z")
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. ---
**Author:** ![WebTreeSoftwareSolut](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/webtreesoftwaresolut/32/40772_2.png) [@WebTreeSoftwareSolut](https://forum.dfinity.org/u/WebTreeSoftwareSolut)\ **Post date:** [October 12, 2026, 8:12pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/19 "2026-10-12T20:12:53Z")
> [@ICPulse](#): > > every subnet at ~10x simultaneously, message rate flat. A subnet cannot finalize 26 blocks per second. Same pipeline, same day. That’s… interesting. What **exactly** do you mean when you say this? ---
**Author:** ![Zane](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/zane/32/6541_2.png) [@Zane](https://forum.dfinity.org/u/Zane)\ **Post date:** [October 12, 2026, 8:32pm UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/20 "2026-10-12T20:32:52Z")
> [@ICPulse](#): > > One thing worth flagging for anyone else doing this: the counter is not monotonic between reads. This will soon (next few weeks) change and the consumed cycles total returned by `/subnet//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. ---
**Author:** ![ICPulse](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/icpulse/32/39993_2.png) [@ICPulse](https://forum.dfinity.org/u/ICPulse)\ **Post date:** [October 13, 2026, 5:11am UTC](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046/21 "2026-10-13T05:11:21Z")
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. [Next page](https://forum.dfinity.org/t/dashboard-cycle-burn-rate-dropped-58-in-one-step-on-10-oct-every-subnet-computation-unchanged-metric-change-or-protocol-change/76046.md?page=2)