# Unexplained multi-billion-cycle drain, zero query traffic, zero logged activity, canister has no real users yet
**URL:** https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896
**Category:** Motoko
**Created:** [August 2, 2026, 10:34pm UTC](https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896 "2026-08-02T22:34:43Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@AETERNAvault](https://forum.dfinity.org/u/AETERNAvault)
#### Post date: [August 2, 2026, 10:34pm UTC](https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896/1 "2026-08-02T22:34:43Z")
Canister ID available privately on request.
Happy to share with anyone from
the DFINITY team who wants to actually investigate.
dfx: 0.32.0 (deprecated, aware — migrating to icp-cli is on our list)
moc: 1.3.0
## The precise measurement
Two `dfx canister status` calls, bracketed with `date` immediately before each:
```auto
Mon Aug 3 00:17:20 CEST 2026 → Balance: 1,672,802,214,952 cycles
Mon Aug 3 00:21:20 CEST 2026 → Balance: 1,663,976,997,344 cycles
```
Exactly 240 seconds apart. Drop: 8,825,217,608 cycles (~8.83B).
That’s ~36.77M cycles/sec sustained — the canister’s own reported
“Idle cycles burned per day” is 7,758,974,478 (~89,803 cycles/sec),
so this is ~409x the canister’s own idle rate. Extrapolated, ~3.18T/day
if sustained.
Across the same window:
- `Number of queries`: unchanged (3,328 → 3,328)
- `Instructions spent in queries`: unchanged (102,018,293 → 102,018,293)
- `Memory Size`: unchanged (269,882,709 bytes → 269,882,709 bytes)
- `Reserved`: 0 in every check, no change to freezing threshold behavior
This isn’t a one-off: the same disproportionate-loss pattern showed up
repeatedly over several hours tonight, at varying magnitudes (from ~150B
cycles across ~30 minutes up to ~2-3T described as “overnight” before we
started precise bracketed measurement).
## What we’ve already ruled out, with evidence (please don’t suggest these)
- **Not query traffic** — `dfx canister status`’s own query counters are
byte-for-byte identical across every measured window where cycles still
dropped.
- **Not memory/storage growth** — `Memory Size` identical across every check.
- **Not any code path gated on a real user profile** — confirmed via an
admin-authenticated `get_network_stats()` call that `total_vaults = 0`;
we have never had a real user complete onboarding. Every function in our
source that could spend meaningful cycles (threshold-key signing calls,
a DEX-swap fallback chain, a fund-transfer relay) is gated behind an
existing profile lookup that fails cheaply with zero profiles present —
verified by reading the source, not inferred.
- **Not threshold signing (vetKD)** — we added explicit `Debug.print` logging
to every `vetkd_public_key`/`vetkd_encrypted_key` call site in our codebase
(3 total). `dfx canister logs` shows zero entries from any of them, before
or after deploying that logging.
- **Not heartbeat misfiring** — added an unconditional tick counter
(incremented on every `heartbeat()` invocation, before any internal gating)
plus a query exposing the last-gated-run timestamp. Confirmed the
intentional once-per-24h gate is holding correctly: tick count climbs at
IC’s normal per-round cadence, but the gated (expensive) body’s timestamp
stays frozen between real invocations, exactly as designed.
- **Not an HTTP outcall** — the one function in our canister that performs an
HTTP outcall (a support-ticket notification) is now both logged and rate
limited; logs confirm it has never fired.
- **Not a WASM install/upgrade tail cost** — measurement windows were taken
well after any deploy completed; no deploy occurred during either measured
interval.
- **Previously-real bugs, now fixed, confirmed NOT the live cause given zero
profiles exist**: (1) a public method with no caller authentication that
let anyone trigger a real threshold-signing call against a caller-supplied
target principal, now capped; (2) an HTTP-outcall-triggering method
reachable by any non-anonymous principal with no rate limit, now capped;
(3) a fund-relay method that moved the canister’s own ledger holdings to a
caller-specified destination with only an “isn’t anonymous” check, now
admin-gated. All three are fixed and deployed; the drain in the
precisely-measured window above happened on the fully-patched build.
## What we’re asking
1. Is there a known subnet-level phenomenon — neighboring canister burn
spikes, replicated-execution surcharges, post-upgrade compute/storage
reservation recalculation — that could produce sustained multi-billion
cycle losses with zero corresponding query/update counters on the
affected canister itself?
2. `dfx canister status` only exposes query-call statistics, not update-call
counts or their individual costs. Is there any tooling or replica-level
diagnostic (subnet dashboard, extended canister\_status fields, anything)
that would show us actual per-message cycle accounting for update calls
and heartbeat executions, beyond what `dfx canister logs` captures?
3. Are there known dfx 0.32.0 / replica-side issues around cycle-balance
reporting that could produce a “phantom” drop not corresponding to real
consumption?
4. Would a DFINITY engineer be able to pull replicated execution history for
this specific canister ID for the timestamps above?
---
### Author:  [@skilesare](https://forum.dfinity.org/u/skilesare)
#### Post date: [August 3, 2026, 12:23am UTC](https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896/2 "2026-08-03T00:23:22Z")
You are using a heartbeat. You pay for the replica loading your canister every round. Using heartbeat basically cost upwards of hundreds to thousands a month. Don’t use heartbeat. Use a timer and fire it far less often. You are basically reserving a fraction of one of 4 cores on a $20k/ month subnet when you use heartbeat,
---
### Author:  [@skilesare](https://forum.dfinity.org/u/skilesare)
#### Post date: [August 3, 2026, 12:28am UTC](https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896/3 "2026-08-03T00:28:26Z")
[https://mops.one/timer-tool](https://mops.one/timer-tool)
This will preserve timers Across upgrades if configured properly. Set it to fire once every 24 hours and you’ll save Ts of cycles.
---
### Author:  [@AETERNAvault](https://forum.dfinity.org/u/AETERNAvault)
#### Post date: [August 3, 2026, 3:09pm UTC](https://forum.dfinity.org/t/unexplained-multi-billion-cycle-drain-zero-query-traffic-zero-logged-activity-canister-has-no-real-users-yet/74896/4 "2026-08-03T15:09:40Z")
It did fix the insane burn. Using timers now . Thanks and appreciate your help