The Whale Finder is honest about what it knows. Each row is a wallet, and the Chain cell on that row carries exactly one value. At capture the top three rows under a total PnL sort read ETH, BASE and BSC, and 957 wallets matched the active filters with 123 of them rendered. Nowhere on any row is there an entity identifier, because the platform is not claiming to have one.
So when a research note says that a single entity is running a book across four chains, that sentence is not a platform output. It is your inference, and in a review you will be asked how it was made and how often it is wrong. This is the method I use, in the order the evidence deserves, with the honest weakness of each step attached to it.
What the Chain column commits to
The source strip above the table offers ALL, POLYMARKET, OPINION TRADE, ETHEREUM, BASE, BSC, SOLANA, MANUAL and PERP DEX. Those are venues and networks, not identities. The module's own ranking-metric list mentions cross-venue aggregate exposure, which is a statement about summing a wallet's positions across places it trades, not a statement that two addresses belong to the same hand.
The first practical obstacle shows up in the live strip rather than the table. The EVM wallets render as truncated hex prefixes while the Solana wallets render as base58 handles. The two address families do not share a namespace, so there is no string join anywhere in this problem. Every cross-chain link is behavioural or transactional, which means every one of them is probabilistic.
Bridge pairing is the only heuristic that touches a shared object
A deposit into a bridge on chain A and a withdrawal from that bridge on chain B are related by a contract that enforced the relationship. That is qualitatively different from every other technique here, because the evidence is a pair of transactions rather than a pair of coincidences. Match on the amount net of the bridge fee, on direction, and on the ordering constraint that the withdrawal falls inside the bridge's finality window after the deposit.
Two failure modes destroy the pairing and both are common. The first is aggregation: canonical bridges and relayers batch payouts, so one withdrawal transaction serves many recipients and the amount you matched on is a sum you cannot decompose. The second is the exchange hop. An operator who deposits to a centralised venue on one chain and withdraws to another has put an omnibus wallet between the two legs, and that omnibus wallet is shared by thousands of unrelated users. A path that routes through an exchange deposit address is not weak evidence. It is no evidence, and a note that treats it as weak evidence is worse than one that ignores it.
Record the bridge, both transaction hashes and the fee assumption you used to make the amounts line up. If the link cannot be reopened by someone else from those three fields, it is not auditable and it should not appear in a memo.
Timing correlation and the collision arithmetic that sets your window
The behavioural argument is that wallets run by one desk act on the same information, so their first trades after a catalyst cluster in time. The argument is sound and the implementation is where people get hurt, because a narrow window still catches accidents and the accident rate is arithmetic you can do before you start.
Work an example with numbers you assume rather than numbers I supply. Suppose the chain-B cohort you are searching contains 300 wallets that traded at all that day, and suppose their activity is spread evenly across 24 hours. A ten-minute window covers 0.69 percent of the day, so the expected count of wallets that land in it by chance is 300 multiplied by 0.0069, which is about two. Widen the window to an hour and the expected accidental count rises to roughly twelve. Neither figure is a measurement from the platform. They are consequences of the two inputs I assumed, and the point of writing them down is that you can substitute your own cohort size and your own window and see immediately whether your candidate set is mostly noise.
The conclusion holds across any plausible inputs. Timing correlation is a filter that shrinks a search space. It is not a link, and a note that rests on timing alone has rested on a coin toss with extra steps.
Size fingerprints on the AVG/MED/MAX column
The Finder publishes three trade-size figures per wallet. At capture the ETH row showed 20.52K average against a 1.99K median and a 155.78K maximum, the BASE row showed 93.21K against 13.35K and 380.43K, and the BSC row showed 10.23K against 6.58K and 31.64K.
The level of those numbers is not portable, because clip size moves with chain fees and with how much depth the wallet can find locally. The shape is more portable. Average divided by median gives 10.3, 7.0 and 1.6 across those three rows, which describes how lumpy each wallet is: one that occasionally does something ten times its habit, and one that essentially always does the same size. Lumpiness is closer to an operator trait than a chain trait.
It is still weak. Three rounded numbers per wallet, spread across 957 candidates, will put many unrelated wallets in the same shape bucket. Use it as a tiebreaker between candidates that bridge pairing or timing already produced, never as the thing that produces candidates.
Scoring the link and the tier that permits an action
Fix three tiers before you look at any data, because a tier invented after you have a candidate is a tier chosen to justify the candidate. Confirmed means a bridge pair with both hashes recorded, plus one corroborating heuristic. Probable means two independent weak heuristics with no transactional evidence. Speculative means one heuristic of any kind.
Attach the action to the tier rather than to the analyst's confidence. Speculative supports no position and no sentence in a client note. Probable supports a capped weight with the tier written into the trade file. Confirmed gets normal treatment. The discipline here is not about being right, it is about the position size being a function of the evidence class rather than of how the morning went.
You will want a false-link rate for each heuristic and you should have one, but it has to be yours. Build a control set from links you can verify independently, run your heuristics against it blind, and count how many accepted links survive. Then you own a precision figure with a denominator you can name. Any rate I quoted here would be invented, and an invented denominator is far more dangerous in a review than an admitted gap, because it survives exactly until someone asks where it came from.
Two housekeeping rules finish the file. Record the negative results, meaning the chains you searched and found nothing on, or the next analyst repeats the whole exercise. And put an expiry on every link, because keys get rotated, sold and handed between desks, and an entity map with no as-of date will quietly go wrong without ever looking wrong.