Labelling counterparties at scale: own wallets, exchanges, routers, vendors
Every on-chain transfer needs a name on the other side. How to label addresses with evidence and confidence, and why unknown must never mean internal.
The label on the other side of a transfer decides the accounting: a move between your own wallets has no gain or loss, while the same transfer to a vendor or a stranger may be a disposal. If your labels are guessed, your gains, expenses and balances are guessed too. A small, evidence-based labelling process fixes most of this.
Why the label matters
For US tax, the IRS says moving crypto between wallets, addresses or accounts that all belong to you is not a taxable event [6]. The same logic drives book accounting: an internal transfer moves an asset between locations and carries its cost basis along. That is exactly why the internal label is the most dangerous one to give out loosely. Label a payment to an outside address as internal and the disposal, the expense and any realized gain all disappear, and the asset stays on your balance sheet when you no longer have it.
- 10 ETH sent to an address labelled own wallet. ETH cost 2,000 each; market price 3,000.
- Booked as internal: no disposal, no expense; 10 ETH (cost 20,000) still shown as held.
- Actual: payment to a contractor. Expense 30,000; ETH derecognized at cost 20,000; realized gain 10,000.
- Effect of the error: expenses understated by 30,000, gains understated by 10,000, assets overstated by 20,000.
Five buckets, five kinds of evidence
| Bucket | Examples | Evidence to keep |
|---|---|---|
| Own wallets | Treasury multisigs, hot wallets, operating wallets | Approved wallet register, signer list, proof of control such as a signed message |
| Exchanges and custodians | Your deposit addresses, exchange withdrawals | Deposit address from your account, matched to exchange statements |
| Protocols and routers | DEX routers, lending pools, bridges | Address matched to the protocol's own published deployment list |
| Vendors, customers, staff | Contractors, payroll recipients, customers | Invoice or contract with the address, confirmed outside the chain |
| Unknown | Everything not yet proven | Nothing; it goes to a review queue |
For protocols, use the protocol's official documentation, not a name copied from a block explorer comment. Uniswap, for example, publishes its contract addresses per network, and the same contract type, such as SwapRouter02, can sit at different addresses on different networks [4]. Record the chain with every protocol label.
Check what kind of address it is
Ethereum has two account types. An externally owned account is controlled by whoever holds its private key and can start transactions; a contract account is run by code and has no private key [1]. A quick check of whether an address holds code helps sort people and wallets from protocols. Since the Pectra upgrade on 7 May 2025, EIP-7702 lets an externally owned account point to contract code through a delegation marker [2][3], so an address with code is no longer always a protocol. Treat the code check as a hint, not proof.
Do not copy labels across chains
An externally owned account's address comes from its public key [1], so the same key controls the same address on every EVM chain. Contract addresses are different: they come from the deployer's address and nonce, or from a salt [1]. A multisig you control on one chain may not exist on another, or the same address there may belong to someone else. Label each chain separately and only after you have evidence for that chain.
Confidence, scope and review
At scale, most new addresses arrive with no label at all. A workable design gives each label a scope (assigned to a known wallet or contact, a verified global protocol address, or unassigned), a source, a confidence level, and a reviewer and date. Automated suggestions, such as an address that keeps receiving from your payroll wallet, can help a reviewer, but they should never post entries on their own. Until someone confirms a label, an unknown address stays unknown and its transfers stay in review.
Labelling is also where sanctions screening fits. OFAC lists some digital currency addresses on the SDN list but says these listings are not likely to be exhaustive [5]. A clean screening result does not prove a counterparty is safe, so it is one input to the label, not a replacement for knowing who you are paying.
What to do
- Keep a controlled register of own wallets per chain, with signers and approval dates; add wallets only through that register.
- Verify protocol addresses against each protocol's official deployment docs, per chain and per version.
- Collect vendor and customer addresses through invoices or contracts, and confirm changes through a second channel.
- Record source, scope, confidence, reviewer and date on every label.
- Route all unknown counterparties to a review queue; never default them to internal.
- Re-screen counterparties against sanctions lists, and note that a clean result is not proof.
- Sample labels at each close and keep the evidence for your auditors.
Sources
- Ethereum accounts (ethereum.org)
- EIP-7702: Set Code for EOAs (Ethereum Improvement Proposals)
- Prague-Electra (Pectra) (ethereum.org)
- Ethereum Deployments (Uniswap v3) (Uniswap Labs)
- OFAC FAQ 562: digital currency addresses on the SDN List (U.S. Department of the Treasury, OFAC)
- Frequently asked questions on virtual currency transactions (IRS)
General information for finance teams, current as of publication. Not legal, tax or accounting advice.