Methodology & Ethics
Every label, bloc and finding on ICPulse comes out of a documented process with a human decision at the end. This page describes that process, including what we refuse to publish and the mistakes our method is built to catch.
Part 1
312 labels are live on ICPulse. Every single one went through the same pipeline. Nothing ships on an algorithm's word alone.
An indexer samples the ICP ledger and NNS governance every 60 seconds, around the clock. A discovery engine surfaces high-volume addresses, and an automated crawler produces a behavioral report for each: volume in and out, distinct counterparties, contact with already-verified anchors, and activity rhythm. The machine proposes. It never decides.
Each candidate runs through a published decision tree. A clean consolidation pattern (many depositors, one verified destination, near-zero balance) becomes a label candidate. An address touching multiple exchanges is never labeled. That shape belongs to users, services and third parties, not to the exchange. Dust-level "patterns" are discarded as spray artifacts.
A human reviews the full report and decides. Labels carry one of two confidence tiers. If ownership cannot be attributed with confidence, the address stays an internal lead no matter how perfect the pattern looks. We have rejected million-ICP addresses on exactly this rule.
Labels are published to a machine-readable registry that feeds every ICPulse feature, and are re-checked against each new deterministic source we open. When a re-check contradicts an old inference, the label is corrected publicly. That has already happened, and catching it is the point.
Proven by a controlled on-chain transfer executed through the address, or derived deterministically from protocol data. Not an opinion, a checkable fact.
A clean behavioral pattern cross-checked against independent external anchors. High confidence, honestly marked as inference, never dressed up as proof.
Part 2
Wherever the protocol itself can tell us an address, we take it from the protocol. Certainty instead of trust.
Large parts of the label map are derived, not discovered: SNS DAO treasury accounts, DEX liquidity-pool accounts (derived from each pool's canister and re-verified against live ledger balances), node-provider reward accounts straight from the NNS registry, and named neurons that identified themselves publicly in governance. Anyone can reproduce these derivations independently, and that is what makes them verified.
Third-party attributions (external explorers, clustering lists) are treated as leads only. They enter the pipeline at step 2 like any other candidate and earn a label only by passing steps 3 and 4. Promoting someone else's inference straight to a label is precisely the failure mode this method exists to prevent.
Part 3
ICPulse detects coordination in NNS governance from observable behavior only.
Voting blocs are measured from the ballot-arrival timing of known NNS neurons, sampled every 60 seconds. A bloc is a set of neurons that repeatedly cast matching votes within the same mid-stream sampling window across many proposals. Opening-burst co-arrival is excluded. Many neurons voting seconds after a proposal opens reflects shared scheduling, not coordination.
| Parameter | Value |
|---|---|
| Sampling interval | 60 seconds, 24/7 |
| Co-arrival window | 300 seconds, mid-stream only |
| Minimum shared proposals per pair | 50 |
| Minimum co-arrival rate | 60% |
| Minimum repeated mid-stream co-arrivals per pair | 10 |
| Minimum vote agreement within those co-arrivals | 90% |
| Bloc density rule | each member needs direct edges to at least half the others |
| Proposals analyzed to date | 1,081 |
The underlying mechanism, whether following configuration, shared hotkey control, or external automation, is not observable on-chain for private neurons, and we report it as unknown. Neurons that have made themselves public do publish their following configuration, and where a bloc's members are public we read it and say so rather than leaving the mechanism open. Most neurons are private, so for most of the network the answer stays unknown. Every bloc is reviewed and approved by a human before publication.
Timing clusters are reported separately from blocs. A bloc requires agreement as well as timing: neurons that arrive together must also be voting the same way. Some neurons arrive in the same sampling window as a bloc, just as reliably, and vote the opposite way. That is a real observation about shared timing and it is not a voting bloc, so we publish it as its own layer, next to the bloc it tracks and never counted in the bloc's membership or its voting power. The distinction matters: merging an adopt side and a reject side into one group because they share a clock would describe a power bloc that does not exist.
Part 4
The Influence League asked how much voting power moves after a named neuron votes. We built that measurement, gated it, and then tested it against its own control. It did not survive the test, so we withdrew it. This part is the record of that, because a method is only worth trusting if it is allowed to fail in public.
The idea was simple to describe. Governance tallies are sampled every 60 seconds. When a publicly named neuron's ballot appeared, we read how much voting power arrived in the tally in the short window after it, and the median of those arrivals, less the neuron's own voting power, was reported as the follower power that moves with its vote. We called it pull, and we said from the start that it was an upper bound rather than proof of command.
It ran behind these gates, each one added after an earlier version produced something we could not defend:
| Parameter | Value |
|---|---|
| Tally sampling | 60 seconds, 24/7 |
| Measurement window | 180 seconds after the ballot appears |
| Clean measurement | proposal already decided, no other named neuron in the window |
| Minimum sample | 5 measurements per neuron and topic, and the median is what we report |
| Burst rejection | a window carrying over 20% of the proposal's entire final tally is discarded |
| Consistency bound | summed follower power per topic can never exceed the network's deciding voting power |
Every gate judged one window at a time, and the defect was only visible between windows. Where several named neurons voted in the same window, the arrival was divided equally between them, which is defensible as an upper bound and produced, on one topic, eighteen neurons credited with the same figure to the cent. Inside such a group the ranking was that shared arrival minus each neuron's own stake, so the smallest neuron ranked highest. That is an artefact of the arithmetic, not a measurement of anybody.
Then the control. We measured, on the same proposals and in the same phase, what arrives in windows where no named neuron voted at all. On the proposals where a neuron's own window carried nothing, a block of almost exactly that neuron's usual figure arrived elsewhere on the same proposal, with no named ballot anywhere near it. The block arrives whether or not the ballot is there. What the measurement detected was whether a neuron happened to vote in the same four minutes as an arrival that was coming anyway.
And then the record disagreed. The governance canister publishes the following configuration of public neurons. Read directly, it says the neuron our own table ranked first follows six other neurons and is followed by none of the fifty named neurons we map. Three independent checks, one of them the network's own record, all pointing the same way.
So the figure is gone. Every named neuron is shown with its own staked voting power instead, and the page says why. We are not keeping a number we cannot defend, and we are not replacing it with a smaller version of the same inference.
What replaced it: following, read from the protocol instead of inferred from the tally.
The NNS governance canister lets anyone read the full record of a public neuron, including the neurons it follows, per topic. Following on the NNS is configured per topic, which is how influence actually works there, and a followee list is a fact rather than an estimate. We read that graph once a day for every publicly named neuron and publish both directions: whom each one follows, and which named neurons follow it.
| Parameter | Value |
|---|---|
| Source | NNS governance, the neuron records of public neurons |
| Coverage | every publicly named neuron, requested by id |
| Granularity | per governance topic, both directions |
| Refresh | daily, with the day to day changes recorded |
| Inference involved | none |
Only public neurons publish their following. Roughly 400,000 neurons vote on the NNS and most of them are private, so a follower count on this page is a floor over the named neurons we map, not a measure of anyone's following. A neuron shown with no followers here may be followed by thousands of private ones. We write "followed by N of the named neurons" for that reason, and never "followed by N neurons".
It also means the question the Influence League set out to answer, how much voting power follows a given neuron, cannot be answered from public data at all. The followers that carry the power are invisible by design. We would rather say that than publish an estimate of it.
Part 5
Parts 3 and 4 ask who votes together and who follows whom. This part asks a simpler question that turns out to be harder to state correctly: how is the power to decide proposals actually distributed, and how much of it is currently not being used at all.
Two quantities are easy to confuse, and the whole of this page depends on keeping them apart.
| Quantity | What it is |
|---|---|
| Stake | the ICP locked in a neuron |
| Voting power | stake adjusted by the neuron's dissolve delay and its age, so two neurons holding the same ICP can carry very different weight |
| Potential voting power | the weight a neuron would carry if it were fully eligible |
| Deciding voting power | the weight it actually carries when a proposal is counted |
The gap between the last two is the subject of half this page. NNS neurons must periodically confirm their following configuration. A neuron that does not is not penalised at once: its deciding voting power decays toward zero over months, while its stake sits untouched. So a neuron can hold a very large amount of ICP and carry no vote whatsoever, and nothing about its balance says so.
Of roughly 440,000 neurons on the network, more than nine in ten carry no deciding voting power at all. Many are small or empty records, and many others have decayed. That is worth publishing on its own, and it is also a warning about arithmetic: a statement of the form "X percent of neurons hold half the vote" divides by a population that is mostly incapable of voting, and the smaller that share looks, the more of the work is being done by inert records rather than by concentration. Where we give such a share we give the other one beside it, against the neurons that carry any voting power at all.
What we measure, and from where.
| Parameter | Value |
|---|---|
| Per-neuron source | the public neuron index, which publishes stake, deciding and potential voting power, the last following confirmation, the creation time and the genesis-claim flag for every neuron |
| Network totals | the governance metrics document, read daily and stored as a series |
| Set measured | the 1,000 largest neurons by stake, ranked within that set by deciding voting power |
| Refresh | the per-neuron set monthly, the network totals daily |
| Inference involved | none, every figure is published by the network |
Network shares are always taken against the governance metrics totals, never against the sum of whatever set we happened to read. Those are two measurements taken at two moments, and dividing one by the other is the kind of arithmetic that has produced wrong numbers on this project before. Where the two are more than a day apart we publish no share rather than a share computed across the gap.
The index is paginated in creation order, so a set has to be selected somehow, and ours is selected by stake. Voting power is not proportional to stake, which means a neuron just below the stake cut can carry more voting power than one just above it, and the set is therefore close to, but not exactly, the largest holders of voting power. The coverage figure on the page is a true statement about the voting power held by that particular set, and a floor on what the largest thousand by voting power would hold.
Concentration is not coordination. That neurons of similar size exist, or were created within seconds of each other, is a fact about size and timing and nothing more. We measure how voting power is distributed, not who controls it, and not whether anyone acts together. Neuron identities are not published by the NNS and we do not guess them. Where a neuron carries a public name we use it, and where it does not, it stays unnamed.
Dormancy is not abandonment. A neuron whose voting power has decayed can be brought back by a single confirmation, and we have watched the network's dormant pool shrink as well as grow.
Part 6
ICPulse has documented an ongoing address-poisoning campaign on the ICP ledger: attacker-generated look-alike addresses that mimic heavily used wallets, planted via zero-amount and dust transfers so they appear in transaction histories next to the real address.
The mimics we've caught match the real address's first 4 to 5 characters, and sometimes the suffix too. Eyeballing the start and end of an address is not a defense. Copy addresses only from a source you control or a verified registry, and verify the entire string before funds move.
The campaign is systematic: new mimics appear within a day for addresses under active public scrutiny, including labeled infrastructure and DEX settlement accounts. ICPulse's crawler detects mimic candidates automatically by prefix-matching against the verified label map, flags zero-amount spray patterns, and logs the funding addresses behind the campaign. Mimic addresses are never eligible for labels and are excluded from all flow statistics.
Part 7
Newly minted ICP is new supply. Where it goes matters more than how much of it there is. This is the part of our method with the largest known gap, so we state the gap first.
Every mint of 100 ICP or more is registered for tracking. For seven days after the mint we read the recipient's ledger history and record every transfer out of that address, to any destination. The result is a measured figure we call left recipient: the share of newly minted ICP that does not stay where it landed.
| Parameter | Value |
|---|---|
| Minimum tracked mint | 100 ICP |
| Measurement window | 7 days from the mint |
| Scan cadence | Hourly batch, continuous |
| History depth per address | Up to 1,200 transactions |
Departures split into two measured quantities, and the page shows both. The part that lands, in one hop, on an address we have already labeled as an exchange is reported as to exchange. Everything else is reported as not attributed: it measurably left, and the destination carries no label of ours. The three figures reconcile exactly on every window, because the second is the first subtracted from the departure total.
The to-exchange figure is a floor, and a very low one. Over the thirty days ending 29 August 2026 it accounted for about 5.7% of minted ICP against a measured departure of roughly 58%, and every unit of it fell on a single day, the one carrying the monthly node-provider reward batch. On the other twenty-nine days it read zero. The page states that day count on screen, next to the figure, because the figure alone invites a conclusion the data does not support.
The reason sits in our own labeling rule. Exchange deposit addresses belong to the users behind them, so we never label them. A deposit address is exactly where a transfer to an exchange actually goes. Counting only hops to labeled exchange addresses therefore measures a route that barely exists, and it would read near zero whether or not anyone is selling. The metric cannot distinguish "nobody sent to an exchange" from "we could not see it", so we do not present it as a finding.
Anyone publishing a low percentage of newly minted supply reaching exchanges, ours included, should be asked how deposit addresses were handled. We publish the departure figure and the unattributed remainder instead, because those are measured.
We are closing the gap by recording destinations rather than only matching them. Each scan stores the addresses that received newly minted ICP, and that produces a ranked list of destinations, which we now publish. Entries carry a label where one exists, a reviewed marker where a person has already examined the address and closed it, and nothing at all where neither is true. A reviewed marker is not a label: it says a human has looked, and says nothing about who controls the address. An entry that is neither labeled nor reviewed is a review candidate, not a finding. As destinations are verified and labeled through the four-step pipeline in Part 1, the historical figures are recomputed automatically.
Separately from mint tracking, we count the ICP arriving each calendar day at every labeled exchange, staking-pool and institutional address, from any sender. That series answers a different question than the one above: mint tracking follows a specific mint forward from the day it was created, while gross flows count arrivals on the day they happen, whatever funded them. The two are never a fraction of one another and are never added together.
The arrivals figure includes movement inside our own labeled set. A transfer from one labeled exchange address to another labeled exchange address is an arrival at a labeled exchange address, and until now it was counted as one. Gross arrivals have been running roughly a hundred times the daily mint, while the net change in exchange balances over the same days is a small fraction of that and changes sign, which is the shape of internal reshuffling rather than money entering from outside. From 30 August 2026 we record, for each arrival, whether its sender carries the same label type as its destination, so the two can be reported apart. Earlier days cannot be corrected without re-walking the ledger and are marked as unmeasured rather than restated. Until a full day has been measured we publish no split.
Facts, not accusations, applies here too. A departure is a movement. It is not a sale, and we do not describe it as one.
Part 8
Two numbers that sound identical are not, and the difference is roughly 47 million ICP.
Under the NNS definition, staked means locked. A neuron that is not dissolving, or is currently dissolving, holds stake. A neuron whose dissolve delay has fully elapsed is open and withdrawable, and is not stake. We report locked ICP as the sum of the not-dissolving and dissolving components, and we report dissolved ICP separately rather than folding it into a staking headline.
All of our supply figures are derived from those three components rather than from any aggregate total, so that every number on the page reconciles with every other number. Locked plus dissolved plus liquid equals total supply exactly, on every view.
A disclosed discrepancy. The governance API publishes a total staked aggregate alongside the three components. The components sum to approximately 127.44 ICP more than that aggregate. We have observed this offset on every daily snapshot we hold, constant to within a rounding artifact, across samples taken up to ten hours apart. We have not been able to attribute it, so we do not hide it: we use the component sum, we state the difference, and it cancels out of every change and trend we publish because it does not vary.
Part 9
A number this easy to state is easy to state wrongly. So we compute it twice, from two independent places, and publish it only when the two agree exactly.
Net emission is the change in the total ICP supply over a closed UTC day. New ICP enters the ledger when it is minted. ICP leaves when it is burned, which happens in two unrelated ways: ICP converted into cycles to pay for computation, and the fee charged on every transaction. We treat those as separate quantities, because they behave nothing alike.
| Component | Definition |
|---|---|
| Minted | Every mint transaction on the ledger, counted by us, not taken as a total |
| Burned, cycles | ICP destroyed converting to cycles |
| Burned, fees | The per transaction fee, destroyed on every transfer |
| Net emission | Minted, less both burns, for one closed UTC day |
The check that makes it publishable. The same day can be measured a second way, as the difference between two points on the network's own total supply series. That figure is produced without any of our inputs. Every day, we compare the two. They must be equal to the smallest unit the ledger records, which is one hundred millionth of an ICP. A day where they are equal is marked reconciled and is never recomputed. A day where they are not is stored, flagged, and left out of everything we publish until it closes.
Over that same window the network minted an average of 11,899 ICP per day and burned 1,352, for a net of roughly 10,546 ICP added per day. Two of the seven days were deflationary. Fees accounted for almost exactly 1 ICP per day across the entire network, which is small enough that the fee series is more useful as an exact count of daily transactions than as a supply figure.
What net emission does not include, stated plainly. Voting rewards are not minted. They accrue to neurons as maturity, which is a claim on future ICP rather than ICP itself, and they reach the ledger only when a neuron holder converts them. Node provider rewards, by contrast, are minted, and they arrive in a single monthly batch that dominates whichever day it lands on. So net emission is a complete account of what happened on the ledger, and it is not a complete account of what the protocol has committed to issue. Those are different questions, and a figure that answers the first should not be read as answering the second.
Part 10
The Exchange Netflow page answers one narrow question: did the ICP held on verified exchange addresses grow or shrink today? It is a balance measurement, and everything it can and cannot say follows from that.
Once a day, shortly after 00:00 UTC, we record the balance of every address in the verified label registry. The net flow for an exchange on a given day is the sum, over that exchange's verified addresses, of today's balance minus yesterday's. The page's headline, the weekly and monthly figures, the daily history and the per-exchange table are all built from that one series. The live figure for the current day compares present balances with the morning snapshot and refreshes every few minutes.
| Parameter | Value |
|---|---|
| Daily snapshot | Once per UTC day, shortly after midnight |
| Live refresh | Every 10 minutes, current day only |
| Address set | Verified exchange labels from Part 1, never deposit addresses |
| Coverage rule | An address counts only on days it appears in both snapshots |
| Per-exchange table | Last settled UTC day, or today so far, as selected |
It is not a count of deposits and withdrawals. We do not classify transactions. We read balances. A day showing a large inflow may be one deposit, a thousand deposits, or an exchange moving its own funds from a wallet we have not verified into one we have. The bar is the same in all three cases, and the page does not pretend to know which one happened.
Our coverage is the boundary. A transfer from a verified exchange address to an unverified address of the same exchange appears as an outflow. A transfer between two exchanges nets to zero across the system only when both sides are verified; when one side is not, it shows as a one-sided move. When we verify a new address it enters the measurement from its second snapshot onward, so growing coverage never manufactures a flow, but it does mean that a 30-day total for an exchange whose coverage grew during the window is measured over a changing set.
Direction is not intent. Coins arriving on an exchange can be sold, lent, held, or moved again an hour later. Coins leaving can go to cold storage, staking, another exchange, or a buyer. We report the direction and the amount. We do not describe either as buying or selling, and the page carries no such language.
The checks behind the page: every per-exchange row sums to the day's total to the unit; the weekly and monthly figures are recomputed from the same daily series rather than stored; and when a single day dominates the window, as happened on 10 and 11 August 2026, we trace the moving addresses through the full ledger before leaving the bars as they are. In that case one external deposit and one exchange-to-exchange route explained both days, and the measurement stood.
Part 11
"ICP transactions" is quoted in the hundreds of millions per day and also in the tens of thousands per day, and both are right, because they count different things. We publish both, label each, and never add them together.
Messages executed is the figure usually quoted as ICP transactions or TPS. It is the network's message-execution rate, published by the IC dashboard API for all subnets, which we sample every hour, average over each UTC day and multiply by 86,400. It counts canister messages: every call a smart contract executes, most of which never touch the token ledger.
Ledger transactions is every block on the ICP token ledger: transfers, mints, burns and approvals. We count them ourselves, with the same continuous walk of the ledger that feeds the rest of this site, and we classify each block once, at the moment we read it, using the label registry from Part 1. A day, once closed, is never recounted under later labels.
| Figure | Definition |
|---|---|
| Messages executed | Message-execution rate, hourly samples averaged per UTC day, times 86,400 |
| Ledger transactions | Every ICP ledger block, counted by us, categorised at collection time |
| Blocks | Block rate averaged per UTC day, times 86,400 |
| Cycles burned | Cycle-burn rate averaged per UTC day, times 86,400, in trillions of cycles |
| ICP burned | Burn transactions on the ledger for the same UTC day, read from the ledger, never converted from cycles |
| Window | Complete UTC days ending yesterday 00:00 UTC; a day with fewer than 24 samples is marked partial |
| Ledger history | From 27 August 2026; earlier days show no ledger count rather than zero |
The dashboard gauge compares yesterday's average message rate with the trailing 30 complete days. Within one standard deviation of the 30-day mean it reads normal; outside it, above or below. It says whether the network was busier than usual. It does not say what the activity was worth.
What the activity was made of. For ledger transfers we publish three breakdowns, and each one sums to the whole, because a transfer lands in exactly one category on each axis. By type: transfer, mint to a node-provider reward account, other mint, burn, approval. By size: 10,000 ICP or more, regular, dust of 0.001 ICP or less. By counterparty: at least one side a labeled exchange; a labeled relay or router with no exchange side; some other labeled infrastructure; or unlabeled on both sides. A second view removes intermediary legs, meaning moves between two addresses of the same exchange and hops through a relay, so the count reads economic movement rather than plumbing.
No cross-chain ranking. We publish ICP's figures and the method behind them. We do not referee comparisons with other networks, whose transaction definitions differ from both of ours.
No TPS headline. A per-second rate is shown only as the source's live value, labeled as such. Daily totals are what we stand behind, because they can be reproduced from the stated window.
No cause, no identity. Messages, cycles burned and ICP burned are shown side by side for the same day because the chain from computation to burn is worth seeing. We do not assert that one caused the other, and no category names an owner. Labels describe infrastructure roles.
Part 12
Three commitments shape everything ICPulse publishes.
1. The data is public by birth. Everything on ICPulse comes from the public ICP ledger and NNS governance. We organize what is already visible to anyone; we expose nothing that wasn't. This is the same standard the wider industry applies to public blockchains.
2. We label infrastructure, not people. The deposit-address rule is structural protection for individuals: exchange-owned plumbing gets labeled, the wallets of the users behind it never do. An individual's address can't end up labeled on ICPulse by pattern-matching, because patterns alone are never enough.
3. Facts, not accusations. Labels are behavioral categories, not identity claims. Findings record direction and magnitude, never intent. Where a mechanism isn't observable on-chain, it is reported as unknown, and the SCAM ledger exists to protect users, not to name suspects.
Every claim on ICPulse is verifiable against the public ledger. If you find one that is not, we want to know.
Open ICPulse