Address Clustering on TRON: Why Co-Spend Fails and What Replaces It

An investigation rarely ends at one 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 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. that received the funds is one node in a set — the operator’s other wallets, the burner that staged the transfer, the deposit address where proceeds cashed out. Address clusteringThe technique of grouping multiple addresses believed to be controlled by the same entity, based on evidence such as shared signing keys, common funding sources, deposit patterns, or coordinated behavior. Clustering turns a scatter of unrelated-looking addresses into a picture of one operator, but every grouping rests on a heuristic — a cluster is a hypothesis whose strength is only as good as the rule that built it. is the discipline of finding that set: grouping the addresses that are likely controlled by a single entity, so the analysis can reason about the controller instead of each address in isolation.

On Bitcoin, one 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. has carried most of this weight for over a decade. On TRON it cannot be used at all — not because it is weak here, but because 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. structure it exploits does not exist. What replaces it is a toolkit of softer signals, each of which earns its place only if its false-positive mode is stated alongside it. This article walks that toolkit; it sits under the broader 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. guide at Who Controls a TRON Wallet?.

Clustering is the bridge from addresses to entities

The point of clustering is entity-level analysis. Victor’s FC 2020 paper — the origin of clustering work on account-model chains — states the goal plainly: to yield “entities that are likely in control of multiple addresses,” because entity identification “forms the basis for entity graph analysis.” Flow tracing, counterparty profiling, and exposure analysis all assume you can collapse an entity’s addresses into one node first.

Without that collapse, an operator splits activity across twenty addresses and each looks unremarkable. With it, the twenty addresses become one actor with a legible history. Everything downstream in an investigation inherits the quality of this step — which is why the false-positive rate of each clustering signal matters as much as the signal itself.

Bitcoin’s workhorse: the co-spend heuristic

The dominant clustering rule on Bitcoin is disarmingly simple. As formalized by Meiklejohn et al. in the 2013 “Fistful of Bitcoins” study: “If two (or more) addresses are inputs to the same transaction, they are controlled by the same user.” A Bitcoin transaction can gather coins from many addresses into one spend, and whoever built it had to sign for every input.

That signing requirement is what makes the heuristic strong. The paper’s own reasoning: “the sender in the transaction must know the private signing key belonging to each public keyA mathematically linked pair — a private key that signs transactions, and a public key (with the address derived from it) that lets anyone verify those signatures. Whoever holds the private key controls the address: on a blockchain, ownership is key control, whatever any off-chain record says. "Keypair", "private key", and "public key" all refer to parts of this same structure. used as an input, so it is unlikely that the collection of public keys are controlled by multiple entities.” The link is not a behavioral guess — it is close to a protocol invariant. (Coordinated multi-party transactions, in which strangers deliberately share one transaction’s inputs, are the well-known exception; the technique post-dates the paper’s “quite safe” assessment.)

The heuristic is also transitive, which is where its power compounds. Meiklejohn et al. again: observe one transaction with inputs A and B, another with inputs B and C, “then we conclude that A, B, and C all belonged to the same user.” Chained across a whole blockchainA 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., one rule collapses large populations of addresses into entities.

Why co-spend has nothing to grab on TRON

TRON is an account-model chain, and the account model removes the multi-input spend entirely. Victor states the consequence for the whole model family: a regular transaction “has one source and one destination account address,” and “existing address clustering heuristics based on multiple inputs or outputs cannot be used for transactions with single inputs and outputs.” His paper is about Ethereum, but the observation is structural — it holds for any account-model chain, TRON included.

The TRON protocol makes this concrete at the protobuf level. A TransferContract carries three fields: owner_address, to_address, amount. One sending account, one receiving account. There is no construct in which several distinct accounts contribute inputs to a single spend, so there is no transaction shape from which a co-spend link between accounts could ever be read.

TRON’s multi-signature support does not smuggle co-spend back in. Under the permission system, up to five keys can share an account’s owner permissionThe highest permission on a TRON account: it can authorize any transaction type and — uniquely — rewrite the account's entire permission structure. By default it is held by the account's own address with a threshold of one, and whoever satisfies the owner permission ultimately controls the account. and a weighted threshold decides when a signatureA cryptographic proof, produced with a private key over a transaction's exact contents, that the key holder authorized that transaction and no other. Nodes verify the signature before accepting the transaction, so a valid signature is definitive evidence the key was used — though not of who was holding it at the time. set is sufficient — but those keys are jointly authorizing one account’s transaction. The owner_address on the wire is still a single account. Multiple keys behind one account is the inverse of co-spend’s shape, which was multiple accounts behind one spend.

The replacements — four signals, each with a false-positive bill

Every clustering signal that works on an account-model chain is behavioral. Victor says this of his own heuristics: they “are based on usage patterns that can be observed on the… ledger. This means they are not inherent to the protocol, so that their effectiveness could change over time.” Set that against Meiklejohn’s inherent-property claim for co-spend and you have the honest frame for everything below: the TRON toolkit is real and productive, and none of it carries co-spend’s near-cryptographic guarantee.

Shared permission keys

TRON’s permission system lets the same signing address hold authority over many accounts, and when one address appears in several accounts’ key lists, those accounts share an operator. This is the one clustering edge with no UTXO analog — a deliberate on-chain grant rather than an inferred pattern. The detector, its evidentiary tiers, and its failure modes are covered in Same-Permission-Key Detection; treat it here as one edge type in the cluster graph.

The false-positive bill: custodiansAn 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. and service operators legitimately hold keys across many customer accounts. A shared key proves a shared operator — it does not by itself prove a shared beneficial owner. That gap between operator and owner is the attribution ceiling this whole article closes on.

Funding and activation lineage

A TRON account does not exist on-chain until something activates it, and the activator leaves a signature. When activation happens by explicit AccountCreateContract, the transaction’s owner_address is the account that paid to bring the new account into existence — a hard on-chain edge from every account back to its creator. Chained, these edges form a lineage tree: one funder activating a fan of addresses is a classic single-operator shape. The activation mechanics live in Account Activation.

Here the false-positive rate is steep. Exchanges, on-ramps, and faucets routinely activate accounts on a user’s behalf, so the activator is often infrastructure — a candidate for ownership, never proof of it. Lineage clusters an account to whoever bankrolled its existence, and against beneficial ownership that read fails constantly. It also mixes two questions worth keeping apart — where an account came from versus who runs it now — a distinction developed in One Wallet, Two Answers.

Behavioral co-movement

Addresses that act in lockstep — transacting in synchronized bursts, holding matching transaction tempo, stakingLocking TRX (historically called freezing) to obtain network resources instead of paying fees per transaction — a stake earns either Energy or Bandwidth, chosen at stake time. Staking also grants TRON Power for Super Representative voting, at one vote per staked TRX, making a wallet's stake both its fee budget and its governance weight. and unstaking resources in coordinated windows — can be grouped as likely co-operated. On TRON, coordinated delegation and undelegation timing is a distinctive version of this, since resource management produces its own visible rhythm; the underlying mechanics are in The Resource-Delegation Trail. Co-movement is genuinely useful for surfacing candidate sets, sybil farms especially, because coordination at scale is hard to fully randomize.

It is also the softest signal in the toolkit, and should be ranked last. It has no protocol anchor at all — no key, no creation edge, only correlation — and shared infrastructure manufactures correlation between strangers: energyA TRON network resource that meters the computational cost of smart-contract execution, consumed whenever a transaction calls contract code — including TRC-20 token transfers such as USDT. An account obtains Energy by staking TRX or receiving a delegation from another account; if it holds too little, the shortfall is paid by burning TRX from its balance. marketplaces serving many customers on one schedule, batch payout tooling, common bot frameworks. Co-movement nominates a cluster; some harder edge has to confirm it.

Deposit-and-sweep structure

Exchange deposit addresses give the account model its nearest thing to a co-spend join. Exchanges issue deposit addresses per customer, so — in Victor’s formulation — “multiple addresses that send funds to the same deposit address are highly likely to be controlled by the same entity.” Comparing his account-model heuristics empirically, he concludes “the deposit address heuristic is currently the most effective approach.” The identifying fingerprint is structural: a deposit address forwards what it receives to the exchange’s main wallet, typically slightly less than it received, since the sweep pays transaction costs. The TRON-specific mechanics of that pattern are covered in Reading Exchange Deposit Addresses on TRON.

The false-positive mode is documented by the heuristic’s own author. Victor’s limitations analysis plays the adversary: receive a transaction from an arbitrary address, promptly forward the same amount to a known exchange wallet, and your ordinary account now looks like a forwarding deposit address — poisoning any cluster built through it. His mitigations are the lesson: require that a candidate deposit address forwards to a single exchange, and bound the match with amount-difference and time-window thresholds. Account-model heuristics need guard conditions that co-spend never did.

The ceiling: a cluster is an entity, not a person

Run all four signals well and the output is still an entity — a controller inferred to stand behind a set of addresses — with an error rate you cannot measure. Victor is direct about this: heuristic clustering means “some addresses could be clustered incorrectly,” and “due to a lack of ground truth, quantifying the error rate is very difficult.” No registry exists against which a cluster can be checked.

Two consequences for practice. State each cluster edge with its signal type and its known false-positive mode, so a reviewer can weigh it — the standard From Finding to Evidence applies to cluster claims exactly as it does to any other finding. And treat “one controller” as the end of the clustering step, not the end of the question: whether that controller is an individual or a service handling thousands of customers is its own analysis, taken up in Person or Service?.

Clustering on TRON, done honestly, is an exercise in weighing edges rather than applying a rule. Co-spend gave Bitcoin analysts one near-invariant they could chain mechanically; the account model gives TRON analysts four behavioral signals of unequal strength, each with its own way to be wrong. The method is to build the cluster from the hard edges — permission keys first, deposit structure second — let lineage and co-movement extend it, and keep every edge’s failure mode attached to the conclusion it supports.

Sources

• Meiklejohn et al., “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names” (ACM IMC 2013) — canonical formal statement of the co-spend (common-input) heuristic, its inherent-protocol-property justification, and its transitivity.
• Victor, “Address Clustering Heuristics for Ethereum” (Financial Cryptography and Data Security 2020, pre-proceedings) — origin paper for account-model clustering: why multi-input heuristics cannot run on single-source transactions, the deposit-address-reuse heuristic and its adversarial false positive, and the usage-pattern (non-invariant) caveat.
• TRON Protocol document (tronprotocol/protocol) — protobuf definition of TransferContract showing the single owner_address / to_address transaction structure.
• TRON Developer Hub — Transactions — TransferContract parameter reference (owner address, to address, amount).
• TRON Developer Hub — Multi-Signature (Account Permission Management) — permission model: keyed addresses, weights, thresholds, and key-count limits per account.
• java-tron documentation — Multi-Signatures — threshold mechanics confirming multi-key signing authorizes a single account’s transaction.
• TRON Developer Hub — Accounts — account activationOn TRON, a newly derived address does not exist on-chain until an existing account activates it — by transferring TRX or TRC-10 tokens to it, by creating it explicitly with an account-creation transaction, or by a smart contract transferring value to it. Until activation the address is just a valid key pair with no state, and the activating account (which pays a small creation cost) is the new wallet's first on-chain relationship. requirement underpinning the funding/activation lineage signal.
• account_contract.proto — tronprotocol/protocol — the protocol definition of AccountCreateContract (owner_address, account_address, type) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.
• balance_contract.proto — tronprotocol/protocol — the protocol definition of TransferContract (owner_address, to_address, amount) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.