Account-model heuristics

Account-based chains such as Ethereum give the analyst neither of the two Bitcoin workhorses: every transaction has exactly one sender, and balances stay in the same account, so there are no co-spent inputs and no change outputs. Users can still create as many addresses as they like, and many do. Clustering on these chains relies on behavior around services, tokens and contracts, and the evidence is weaker and less validated than in UTXO chains.

What changes in the account model

On an account chain a single address often carries a user's whole history, which makes each address richer but gives no built-in rule for linking it to another. Victor (2020, "Address Clustering Heuristics for Ethereum") proposed three heuristics: deposit-address reuse, airdrop multi-participation (several addresses that each claim a token airdrop and then forward the tokens to one common address) and self-authorization through token approvals. He found that, over Ethereum's first four years, they clustered 17.9% of all active externally owned accounts (EOAs). The paper is candid that there was no ground truth with which to measure their accuracy. A later open-source study of Ethereum and Tornado Cash privacy (Wu et al., 2022) applied the strongest of the three, deposit-address reuse, and found 26 million EOAs grouped into 2.5 million clusters; checked against 1,028 clusters derived from naming-service records, its recall was 39.4%. Those are the best-documented numbers available, and they show that most links are missed and that precision is largely unmeasured.

The heuristics below are listed roughly from strongest to weakest.

Deposit-address reuse

Many custodial exchanges assign each customer a unique deposit address and periodically sweep its balance into a hot wallet (see the lesson Following value through exchanges and services). If two EOAs both send funds to the same deposit address, they are probably credited to the same customer account, and therefore probably controlled by the same person or organization. This is Victor's deposit-address heuristic, and it is the most productive of the account-model rules.

Deposit addresses are not labeled on-chain, so they must be inferred: an address that receives funds and forwards almost the same amount to a known exchange wallet shortly afterwards.

-- Candidate deposit addresses and the senders they link
WITH forwards AS (
  SELECT t_in.to_address   AS deposit_addr,
         t_in.from_address AS sender
  FROM transfers t_in
  JOIN transfers t_out
    ON t_out.from_address = t_in.to_address
   AND t_out.block_number BETWEEN t_in.block_number
                              AND t_in.block_number + 2000
  JOIN labels hw
    ON hw.address = t_out.to_address AND hw.category = 'exchange_hot_wallet'
  LEFT JOIN labels svc
    ON svc.address = t_in.from_address
  WHERE svc.address IS NULL          -- senders must not be known services
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

The query pairs each incoming transfer with an outgoing transfer from the same address to a labeled exchange hot wallet within 2,000 blocks, drops senders that are themselves known services, and keeps deposit addresses used by at least two senders. A production version also checks that the forwarded amount is close to the received amount and that the address forwards consistently over time. The 2,000-block window is an assumption to document, not a standard.

Failure modes: a person paying into a friend's or employer's exchange account; payment processors and over-the-counter desks that deposit on behalf of clients; exchanges that reassign or share deposit addresses; and the error of mislabeling an ordinary forwarding address as a deposit address.

Gas funding patterns

A fresh EOA needs native currency to pay gas before it can do anything. Its first incoming transfer often comes from the same operator, so many fresh EOAs funded by one address within a short window, with similar amounts and similar subsequent activity, suggest common control. Airdrop teams use this pattern to detect fake participants, and it is a useful lead in exploit investigations (see the lesson Analyzing exploits and hacks).

The weakness is that the funder is often a service. Exchange withdrawal wallets, bridges and faucets fund enormous numbers of unrelated users, so funders must be checked against service labels before any link is drawn. Gas sponsorship breaks the link entirely: under ERC-4337 a paymaster can pay for a user's operations, and since EIP-7702 (activated in May 2025) an EOA can delegate to code and have a sponsor submit and pay for its transactions. The lesson The account model for analysts explains why the gas payer and the signer are different questions.

Token approvals

An ERC-20 approve call lets a spender move tokens from the owner's balance and emits an Approval event:

{
  "address": "0x7d1a…c3E0",
  "topics": [
    "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
    "0x000000000000000000000000a1b2…009f",
    "0x000000000000000000000000c4d5…77e2"
  ],
  "data": "0x…ffffffff"
}

The first topic is the event signature hash of Approval(address,address,uint256), the second the owner, the third the spender, and the data field the allowance. Most approvals name a contract, such as a DEX router. Victor's self-authorization heuristic links an owner to a spender when the spender is another EOA, on the reasoning that people rarely let a stranger's personal address spend their tokens.

The serious failure mode is fraud. Approval phishing tricks victims into approving an attacker-controlled address, and these approvals look exactly like self-authorization. Before linking, check whether the spender drained the owner soon afterwards; if so, the link is victim-to-thief, not one owner.

Contract deployer links

Every contract has a creator. With CREATE, the new contract's address is derived from the deployer's address and nonce; with CREATE2 (EIP-1014), from the deploying contract, a salt and the hash of the initialization code. Contracts deployed by the same EOA often belong to the same team, and an exploit contract's deployer is usually a key node in the attacker's cluster.

Failure modes: public factory contracts that anyone can use (the factory, not the user, appears as creator), deployment services, compromised deployer keys, and copied open-source code. Identical bytecode shows shared code, not shared control.

Timing, nonce and naming signals

Timing. Addresses operated by the same person or bot often share a daily activity pattern, act within the same blocks, or alternate in a fixed rhythm. Béres et al. (2020, "Blockchain is Watching You: Profiling and Deanonymizing Ethereum Users") used time-of-day profiles and fee settings as quasi-identifiers. Fee settings became much less distinctive after EIP-1559 (August 2021), when most wallets began calculating fees automatically.

Nonce. An EOA's nonce counts the transactions it has sent. Nonce sequences reveal how active an address is and in what order its actions happened; several addresses whose nonces advance in lockstep, each sending one transaction per round in a fixed order, suggest a single script driving them.

Naming services. ENS links names to addresses through forward records (name to address) and optional reverse records (address to primary name). A reverse record is set by the address owner, so it is a self-claim; confirm that the name's forward record points back to the same address. Names expire and can be re-registered by someone else, so record the block at which you observed the link. Many names are personal; treat them as described in the lesson Attribution and labeling.

Traps specific to account chains

Never cluster by the from field of transactions sent by shared infrastructure. An ERC-4337 bundler submits one transaction containing the operations of many unrelated users; relayers and meta-transaction services do the same. Linking everything a bundler or relayer sent would merge thousands of users. The same applies to contracts that hold many users' funds, such as DEX pools and bridges.

Smart-contract wallets add a further twist. A multisig contract wallet is one address controlled by several signer EOAs, whose list can be read from the contract's state. The signers co-operate, but they may be different people; treat the wallet as the entity and the signers as related parties, not as one cluster.

Because each account-model signal is weak on its own, a sound practice is to require two independent signals before drawing a link, for example gas funding from a non-service address plus lockstep timing, and to record both in the evidence table with their own confidence.

Exam focus: why account chains lack common-input and change heuristics; Victor's three heuristics (deposit-address reuse, airdrop multi-participation, self-authorization) and why their accuracy is largely unmeasured (17.9% coverage with no ground truth, 39.4% recall for deposit-address reuse); inferring deposit addresses from forwarding to hot wallets; gas funding and why service funders, paymasters and EIP-7702 sponsors break it; reading an Approval log and the approval-phishing false positive; CREATE and CREATE2 deployer links and factory pitfalls; timing, nonce and ENS evidence and their limits; never clustering by a bundler's or relayer's sender address.