Seeing Past the Intermediary: What Survives a Custodial Hop

Every long trace eventually hits a service that takes custodyAn arrangement in which one party — the custodian — holds the private keys or reserves controlling assets that belong to others. On a blockchain, whoever holds the keys is the on-chain owner: custodied funds sit under the custodian's addresses, so the entity an analyst sees acting on-chain is the custodian, not the customer. — a centralized exchange, a payment processor, a custodian, an OTC desk. The moment funds cross that boundary, the chain stops describing the thing you were following. The customer’s position becomes a row in the service’s internal ledger, and the addresses still visible on-chain belong to the service’s own plumbing.

This is the general reasoning problem behind several better-known special cases, and it deserves its own treatment. What exactly does the hop destroy, what still leaks on-chain, and how far can honest inference go past one?

Custody moves the ledger off-chain

What defines a custodial intermediary is where the customer’s value actually lives: in the service’s books. FinCEN’s 2019 guidance on convertible virtual currency draws the line precisely: in a hosted walletSoftware or hardware that stores private keys and uses them to sign transactions. A wallet holds keys, not coins — balances live on the ledger itself — so the same funds can be reached from any wallet loaded with the same keys, and losing the wallet loses nothing if the keys are backed up elsewhere., the value “may be stored in a wallet or represented as an entry in the accounts of the host,” the owner “interacts directly with the host, and not with the payment system,” and the host “has total independent control over the value” — contractually obligated to move it only on the owner’s instructions, but in sole possession of the keys.

That definition is technology-neutral, and that is what makes it useful. It describes a centralized exchange, but it describes a payment processor, a qualified custodian, and an OTC desk that takes possession just as well. Whenever those four features hold — the customer owns the value, the position is an entry in the host’s accounts, the customer talks to the host and never touches the chain, and the host controls the keys — you are looking at the same structure, whatever the business calls itself.

For someone reading the chain, the consequence is direct. The transactionA signed instruction ("tx" for short) that changes on-chain state — transferring value, calling a contract, or updating an account's settings. Once it is included in a block and that block reaches finality the record is permanent: later transactions can supersede its effects, but the entry itself can never be edited or deleted. Before finality, a freshly included transaction can still be reversed if its block is reorganized out. that delivered funds to the service is real and permanent. The record of whose funds they became is a database row inside the host, and no amount of chain analysis reads a database you cannot see.

What the hop severs

Past the deposit, the on-chain movements you can observe are the service’s operations — sweeps, rebalancing, batched withdrawals — and following them no longer follows the depositor. Forensic-industry methodology writing describes the mechanism plainly: a deposit “doesn’t just sit at that addressA public identifier, derived from a key pair, at which an account receives funds and is looked up on-chain. Anyone can view an address's history, but only the matching private key can spend from it. TRON addresses are 34-character Base58Check strings beginning with "T".”; the service “moves it around internally as needed, pooling and co-mingling it with the funds of other users.” That account comes from a vendor with a commercial stake in its own tooling, but on this point it is corroborated by the FinCEN definition above — the customer’s position was never the on-chain address to begin with.

The chain itself offers no help distinguishing these internal movements. As the same methodology writing notes, a service’s internal fund movements “get recorded in the ledger just like any other transaction.” A sweep from a deposit address into an omnibus wallet looks like a payment. A hot-wallet rebalance looks like a transfer between strangers. Nothing in the transaction format marks them as bookkeeping.

The foundational academic work on this problem stated its own scope with unusual honesty. Meiklejohn and colleagues, in the paper that established service-tagging and clustering as a discipline, wrote that they “do not seek to de-anonymize individual users, but rather to de-anonymize flows of bitcoins throughout the network.” Their method for attaching identity to a service’s addresses was to interact with the service — deposit at Mt. Gox to tag one address as the exchange’s, withdraw to tag another — because the chain alone would not yield even that. The study was done on Bitcoin’s UTXO model; the mechanics carry to an account-model chain like TRON by architectural analogy, and the scope limitation carries with them. Chain analysis de-anonymizes flows. The people behind the flows were out of reach in 2013, at the very origin of the field, and past a custodial hopThe point in a fund flow where value passes into or out of a service that holds keys on customers' behalf — an exchange, payment processor, or other custodian (sometimes just called an intermediary). Crossing the boundary (a custodial hop) breaks direct on-chain traceability: inside the service, funds move on internal books, so what later emerges on-chain cannot be tied to a specific depositor from ledger data alone. The intermediary's own records — often reachable by legal process — are what carry a trace across the boundary. they still are.

What still leaks

A custodial hop severs the trail without blacking it out. Three structural signals survive it on-chain, and knowing their exact strength — and their shared limit — is most of the skill.

Leak	Side	What it supports	Mechanics owned by
Deposit-address structure	Inbound	This address is part of a specific service’s deposit machinery	Reading Exchange Deposit Addresses on TRON
Activation fingerprint	Outbound	Funds arriving here crossed a custodial boundary on the way out	Account Activation
Amount + timing correlation	Across the hop	Weak candidate pairing at best — co-mingling breaks it	Across the Bridge (where it actually works)

The deposit-address structure is the strongest of the three. Exchanges issue per-customer deposit addresses that forward received funds into a collector, and peer-reviewed clustering research shows that addresses feeding the same deposit address are highly likely to share a controller. The fan-in shape identifies the service and clusters its depositors’ sending addresses. The full mechanics — the sweep, the fan-in, the TRON-specific Energy-delegation fuelingAny arrangement in which an outside party keeps a wallet transacting without its holder paying the network costs — by delegating staked resources, topping up small amounts of the native coin for fees, or sponsoring transactions through a fee-payment service; also called fee sponsorship. Not to be confused with funding lineage: fueling explains who pays a wallet's running costs, not where its balance came from. — belong to the deposit-address article linked above; what matters here is what the pattern proves. It attributes an address to the institution, never to the customer behind it.

The outbound mirror is the activation fingerprint. On TRON, a fresh withdrawal address is typically activated and first funded by the service’s hot walletAn online, always-connected wallet a service uses for day-to-day operations — paying withdrawals, sweeping deposits, funding fresh addresses. Because its keys live on internet-connected systems, a service keeps only working balances in it; in tracing work, a service's hot wallet often shows up as the first funder of the addresses it operates. — the first inbound transfer to a new account is frequently a gas top-up from exchange infrastructure. Seeing a known hot wallet as an address’s first activator tells you funds exited a custodial system to reach it. It says nothing about who requested the withdrawal; the activation article linked above covers what the mechanic does and does not prove.

Amount-and-timing correlation is the leak analysts most want and mostly cannot have. Matching a deposit to a withdrawal by value and clock only works where the intermediary conserves the amount, and a custodian does not. Fees come out, withdrawals get batched, the pool rebalances on its own schedule, and the co-mingled reserve fills every withdrawal from whatever happens to be on hand. The one place the technique carries real weight is the bridgeA protocol that moves value between blockchains, most commonly by locking the asset in a contract on the source chain and minting a wrapped equivalent on the destination chain (lock-mint), redeemed later by burning the wrapped token to release the original (burn-release). For tracing, a bridge's contract addresses are shared plumbing: a flow into a bridge marks a chain boundary to carry the investigation across, and the bridge itself is never the origin of the funds. A bridged, wrapped stand-in is also not the same asset as a native issuance on the destination chain — see native vs bridged. case, where a lock-mint or burn-release design conserves the amount by construction — and that treatment belongs to the cross-chain article linked above. Transplanting the bridge technique to an exchange hop is exactly the error this distinction exists to prevent: treat a same-amount withdrawal shortly after a deposit as a lead worth writing down, and stop short of asserting it as a match.

The inference ceiling

Everything that survives the hop supports the same class of claim: entity attributionThe process of identifying the entity most likely to control a blockchain address by combining on-chain signals — who created and funded it, how it transacts, which keys can act for it — with known service patterns and labels. Attribution conclusions are evidence-weighted judgments, not certainties, and are strongest when several independent signals converge.. From chain data past a custodial boundary you can establish that an address belongs to a service, that funds entered its custody, and that funds later left its custody. The step from any of that to a person requires the service’s own records. The vendor methodology writing puts it directly: “Only the exchange itself knows which deposits and withdrawals are associated with specific customers,” and that information lives in order books “which aren’t visible on blockchainsA shared ledger maintained by many independent computers, in which transactions are grouped into blocks and each block cryptographically references the one before it. Because rewriting any past entry would break every link after it, the record is effectively append-only — new entries can be added, but history cannot be quietly altered. or in analysis tools.”

The courts have looked at the same boundary. In United States v. Sterlingov, the ruling examined the step from an on-chain cluster to a named entity and observed that it rests on an “intelligence-based heuristicA behavior-based rule used to infer facts a blockchain does not state directly — for example, that addresses spending together, or all draining into one collector, share a controller. Heuristics can be highly reliable when the pattern is strong, but they produce inferences with known failure modes, never proof, so their conclusions should carry confidence levels and survive cross-checking.” which “is not actually a heuristic at all” — it is information from outside the blockchain. The full argument about that entity-versus-person ceiling, and the legal-process escalation for crossing it, is the territory of From Finding to Evidence; this article’s job is only to apply it. A trail that reaches a custodial intermediary has not ended. It has changed problem type.

That reframing is worth stating in operational terms. Reaching a compliant, subpoena-able exchange is often the best thing that can happen to a trace: the mapping you cannot read on-chain exists, is regulated into existence, and is reachable by legal process. The chain work is finished when it has established which institution to ask and which deposit to ask about.

One ceiling, three causes

The custodial hop is the general case, and the two special cases every analyst learns are engineered variants of the same severance. A custodian severs the trail as an operational byproduct of holding funds — co-mingling and off-chain accounting are just how custody works. A mixerA service (also called a tumbler) that pools deposits from many users and pays recipients out of the common pool, deliberately breaking the on-chain link between sender and recipient. The severed trail can sometimes be re-joined by matching amounts and timing around the mixer, and U.S. guidance has treated custodial mixing itself as money transmission since 2019. produces the same severance deliberately, as the product itself; that case, and the layered-funding patterns built on it, belong to When the Trail Goes Cold. A bridge severs the trail by splitting one flow across two chains — with the compensating gift of amount conservation, covered in the cross-chain article. Same ceiling, three causes, and the general reasoning in this article is the part all three share. Reading what kind of counterparty the trail has hit — a nested service, a desk, a marketplace — is its own discipline, covered in Following the Money.

The discipline to carry away is calibration. Past any custodial boundary, claim the institution, claim the crossing, keep the surviving structural leaks in their evidentiary lane, and route the question of the person to the entity that holds the answer. Analysts who respect the ceiling get subpoena-ready findings; analysts who ignore it get attributions that collapse on first contact with the service’s actual books.

Sources

• FinCEN Guidance FIN-2019-G001: Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies — Primary U.S. regulatory guidance (May 9, 2019); the hosted-wallet definition: value “represented as an entry in the accounts of the host,” the owner interacting with the host and not the payment system, and the host’s total independent control.
• Sarah Meiklejohn et al., “A Fistful of Bitcoins: Characterizing Payments Among Men With No Names” (USENIX ;login:, Dec. 2013) — Peer-reviewed research (the ;login: edition of the IMC 2013 paper); chain analysis de-anonymizes flows rather than individuals, and service addresses are tagged by depositing and withdrawing. Studied on Bitcoin; applied to TRON by architectural analogy.
• Friedhelm Victor, “Address Clustering Heuristics for Ethereum” (Financial Cryptography and Data Security 2020) — Peer-reviewed source for the per-customer deposit-address forwarding structure cited here as the strongest surviving leak; full mechanics treated in the deposit-address article.
• Chainalysis, “Why You Can’t Trace Funds Through Services Using Blockchain Analysis” — The co-mingling mechanism and the limit that only the exchange’s order books map deposits and withdrawals to customers. Blockchain-forensics industry source (vendor methodology, not protocol-authoritative); used here where corroborated by the FinCEN primary.
• United States v. Sterlingov, No. 21-cr-399 (RDM) (D.D.C., Feb. 29, 2024) — Primary court record; the step from an on-chain cluster to a named entity rests on intelligence from outside the blockchain.