Every on-chain research process eventually produces a sentence of the form "large wallets moved X". The sentence is worthless until somebody says which kind of wallet, because the same transfer carries four incompatible meanings depending on what the address is for. Custody moving client assets between vaults is an operations event. A bridge rebalancing is an accounting identity. An exchange sweeping deposits is a function of its own customers. Only one of the four is anyone taking a position.
A taxonomy is the artifact that makes the distinction reproducible rather than a matter of whoever is reading the screen that morning. It is also, in practice, the piece of infrastructure most often skipped, because it produces no signal by itself and is only visible when it is missing.
Why one ranked list contains four different objects
The scope of the problem follows from the coverage. Whale Alpha indexes DEX perpetuals across Hyperliquid, GMX, Drift, dYdX and further chains, prediction-market wallets on Polymarket and Opinion Trade, and early participants in Solana and EVM token launches. The tracked census on the statistics tab stood at 26,687 wallets at capture, and the finder's stream header read DISPLAYED 123 / 957, so what is on screen at any moment is a slice of a slice.
Nothing in that pipeline is wrong. It is an indexing layer, and indexing layers correctly record what happened on chain without asserting who the counterparty is. The classification is the consumer's job, and the consumer is you.
It is worth separating this from the risk axis, because the two get conflated in conversation. The module's ranking metrics include a risk classification flagging concentration, leverage and drawdown profile. That is a description of how a wallet takes risk. The taxonomy below is a description of what the wallet is for. They are orthogonal, you need both, and a wallet can score cleanly on one while being disqualified by the other.
Four classes, defined by what a transfer means
The classes worth maintaining are exchange hot, qualified custody, bridge escrow and principal trading. Define each by the meaning of its flow rather than by the entity behind it, because meaning is what your downstream statistics consume.
An exchange hot wallet's flow is its customers' flow, aggregated and net. An inflow is deposits, and it says something about the intentions of many small parties rather than one large one. Outflows are withdrawals plus internal moves to cold storage, and the two are indistinguishable without further evidence. Nothing this wallet does is a view held by its operator.
Qualified custody flow is an instruction, not a trade. Assets move between vaults, from a vault to a client's venue account, or to a new custodian, and the movement is often days or weeks separated from the decision that caused it. Treating a custody transfer as a timing signal is the single most common error in this space, and it is the one that produces confident notes about accumulation that were actually about a migration.
Bridge escrow flow is mechanical. The balance held in a bridge contract is the net of what has been locked on one side against what has been minted on the other, so it tracks aggregate cross-chain demand and nothing else. A large increase in a bridge's holdings is not accumulation, and a decrease is not distribution, and both will be reported as such by anyone reading balances without labels.
Principal trading flow is the only class where a transfer is an opinion. The wallet takes signed positions, changes their sign, realises profit and loss, and has a holding period distribution that means something. This is the class every cohort statistic is supposed to be about, and it is usually a minority of the addresses that clear a size threshold.

Evidence that is deterministic and evidence that is only behavioural
Rank your evidence before you write a single rule, because the ranking is what you will defend when a label turns out to be wrong.
The strongest evidence is a property of the chain itself. Whether an address is a contract or an externally owned account is not an inference. Nor is the signer set of a multisig, the implementation address behind a proxy, an owner function, or a withdrawal allowlist. Bridge escrow is the class most cleanly settled this way: the address is contract owned, its counterparties are the bridge's own relayers, and its inflows on one chain pair with outflows on another at matched amounts within a bounded lag. Qualified custody usually announces itself structurally too, through a threshold signer arrangement and the complete absence of router approvals. A custody address that has never granted an approval to a trading contract has never traded.
Below that sits venue-published identification, which is reliable but partial, and then behavioural fingerprints, which are probabilistic and should always be written as such. Exchange hot wallets are usually identified here: a very large and growing counterparty set, a median transfer size orders of magnitude below the maximum, sweeps into a single destination on a repeating cadence, gas funded from a common funder address, and activity with no diurnal pattern because the customers are global. Principal trading is identified by approvals to perpetual and DEX router contracts, position sign changes, and a holding period distribution with actual dispersion in it.
Third-party labels sit at the bottom and are usable only with a source and a date attached. They are frequently correct and occasionally years stale, and a stale label is more dangerous than no label because it stops anyone asking.
Reclassification is triggered, not scheduled
Classes are not durable. Exchanges rotate hot wallets. Custodians migrate to new vault architectures. Bridges upgrade their implementation contracts. A treasury spins up a wallet that trades. A scheduled quarterly refresh will find all of this eventually, which is to say it will find it after you have already published something wrong.
Run both. Schedule a full re-derivation of the census on a fixed cadence and record the date it ran, monthly for the wallets you actively consume and quarterly for the long tail. Then define the triggers that jump the queue, because those are where the failures actually happen. The first venue interaction or router approval ever seen from a custody-classed address is a trigger. A step change in counterparty entropy is a trigger. A proxy implementation change or a signer set change is a trigger. So is a dormancy break after a long silence, and so is a venue changing its own published identification. Each of these should raise a review item rather than silently rewriting the label, because an automatic reclassification that nobody saw is indistinguishable from a bug.
Storing labels so last quarter's numbers do not move
The storage decision determines whether the taxonomy is research infrastructure or a slowly accumulating liability, and it is a single choice: labels are versioned, never overwritten.
Give every assignment a valid-from and a valid-to date, and join labels to trade history as of the date of the trade rather than as of today. Without this, reclassifying one large wallet next month restates every cohort statistic you have ever published that touched it, quietly, with no record that the number moved. Anyone who has tried to reconcile a research figure against its own prior version knows exactly how that meeting goes.
Store the evidence alongside the label, not in a separate document: which rule fired, on what date, with which parameter values, and the confidence tier that resulted. Store disagreements too, because a behavioural test that contradicts a contract property is usually the earliest sign that a wallet has changed function.
And be explicit in the note about what the taxonomy does not deliver. It does not give you intent, it gives you function. It does not tell you whose assets are moving, since an exchange hot wallet moves other people's. And a single entity can operate addresses in three of the four classes at once, which means the unit of analysis is always the address, never the institution you believe is behind it.