Account Takeover on TRON: Five Outcomes and How to Read Them Apart

An account that “changed hands” is, forensically, a divergence: the party that created and funded the account and the party that operates it now are no longer the same. The two 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. axes — origin and control — disagree, and One Wallet, Two Answers covers why reading both is mandatory. This article picks up where that split leaves off. Once you suspect a divergence, the next question is which kind, and the answer sits in the account’s 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. history.

Five end-states cover what an analyst actually encounters after a TRON account is compromised or transferred: a silent drain, a permission hijack, a delegation grant, a 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. sale or handoff, and a dormant revival. Each leaves a distinct on-chain 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. — a specific transaction type present in the history, or a specific transaction type conspicuously absent. This piece is the differential: given the suspect account, which of the five you are looking at, and what evidence settles it. These five are organized by signature — the transaction pattern you observe. A companion article, The Wallet That Woke Up, sorts an already-detected takeover the other way, by what the new operator ends up holding (an owner key, an active key, a delegation basis); its labels answer what did control become where these answer what does the history show. The two are complementary lenses on one event and reconcile cleanly — a wallet sale here is the owner-key case there.

Control moves in a handful of transaction types

The reason a five-way differential works at all is that TRON’s protocol enumerates every transaction as one of a fixed set of contract types, each with a numeric ID, and only a few of them can touch who controls an account. Account creation is type 0, a plain TRXThe native coin of the TRON network. TRX settles value directly (no contract call needed), is staked to obtain Energy, Bandwidth, and voting power, and is burned to pay fees when staked resources fall short. Its smallest unit is the sun: 1 TRX = 1,000,000 sun. transfer is type 1, a smart-contract call (including every TRC-20TRON's smart-contract standard for fungible tokens, derived from Ethereum's ERC-20: a compliant contract exposes transfer, approve, allowance, and transferFrom, and emits Transfer and Approval events. USDT on TRON is issued as a TRC-20 token. Because every TRC-20 transfer is a contract call, it consumes Energy (plus Bandwidth) and — unlike a TRX or TRC-10 transfer — cannot activate a not-yet-created account. move) is type 31, a permission rewrite is type 46, and resource delegationA TRON mechanism by which one account lends the Energy or Bandwidth derived from its own staked TRX to another account, without any TRX changing hands. Because it supplies a wallet's operating capacity rather than its funds, delegation marks an ongoing operational relationship — a fee-sponsorship link, not a funding-lineage link — and routine services such as exchanges do not delegate resources to customer wallets. is types 57 and 58. The full catalogue is covered in Transaction Types and What They Carry; the differential below needs only these six.

One more protocol fact carries most of the weight. A newly created account holds its own 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". as the sole Owner-permission key at threshold 1, and the 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. is the highest privilege on the account — it can sign anything and rewrite the permission structure itself. By default, control is the private 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.. That default is why one of the five outcomes leaves no on-chain trace whatsoever: handing the key to someone else off-chain transfers everything the chain protects, and the chain records nothing, because no transaction took place.

The five end-states

Each outcome below is stated signature-first: the transaction pattern that identifies it, then what corroborates it. The signatures are the spine — they are what you query for.

1. Silent drain

The signature is outbound value transfers — type-1 TRX sends and/or type-31 contract calls sweeping TRC-20 balances — signed by the account’s existing key, with no type-46 permission update anywhere in the history. The attacker holds the private key and spends. There is nothing to rotate and no reason to announce the compromise, so the permission structure sits untouched while the balance empties.

The absence of a type-46 record is the diagnostic tell here, and it is worth stating as a rule: on a drained wallet, the missing permission update is as informative as a present one would be. Security-firm casework on the November 2023 Poloniex hot-wallet compromise illustrates the shape — a stolen key, funds sent directly to attacker-controlled addresses, no permission rotationAny change to an account's permission state — keys replaced, added, or removed, or thresholds and weights altered. Rotation is a mechanism, not a motive: the same recorded act can be routine security hardening (retiring an old key), a sale (handing control to a buyer's keys), or a takeover (an attacker inserting theirs). What the ledger fixes is the fact and the date; which story it belongs to must be read from surrounding behavior — what the old and new keys each did before and after the change. in the affected wallets’ histories (Halborn’s investigation, corroborated independently by CertiK).

The drain has one sub-variant that changes the signer. In an approval drain, the outbound move is a transferFrom executed by a third-party spender who holds a standing TRC-20 allowance the victim granted earlier with an approve call. The drain transaction is signed by the spender, and the enabling grant sits earlier in the history as an approval. The allowance mechanics live in TRC-20 Approvals and Allowances, and the social-engineering pipelines that harvest those approvals are the subject of Fake USDT, Counterfeit Tokens, and Wallet Drainers on TRON. For this taxonomy, it is one signature within the drain outcome: same emptied wallet, different signer on the outbound leg.

2. Permission hijack

The signature is an explicit AccountPermissionUpdateContract — type 46 — in the account’s history. It is the single transaction type that rewrites who can sign for an account, it overwrites the entire permission set in one operation, and it carries a 100 TRX fee. Those properties make it a rare, deliberate, high-signal event: nobody sends one by accident. The opcode’s full mechanics, including the all-or-nothing rewrite and its lock-out failure mode, are owned by AccountPermissionUpdate.

In the hostile version, the update removes the original key or inserts an attacker key and threshold, after which the legitimate holder can no longer move funds. A dated example shows the end-state at its most deliberate: in a case documented by TokenA unit of value recorded inside a smart contract rather than in the chain's native ledger — the contract keeps the balance table, and moving tokens means asking the contract to update it. Not to be confused with a coin, which is the chain's built-in asset (TRX on TRON) used to pay for the network itself. Trace in November 2023, a wallet’s Owner permission had been pre-assigned to a scammer-controlled address before the victim ever imported the handed-over seed phrase — the victim held the seed and still could not send funds without the scammer address’s approval. The diagnostics for reading a rotation — including the tell that separates a routine self-rotation or security hardening from a hostile takeover — are the territory of Same-Permission-Key Detection; treat the type-46 record as this outcome’s flag and take the playbook from there.

3. Delegation grant

A DelegateResourceContract — type 57 — is the entire signature: no key change, no movement of the staked TRX itself. One account shares the BandwidthA TRON network resource that covers the byte-size cost of putting a transaction on chain — one byte consumes one Bandwidth point. Every account receives a small free daily allowance (also called free bandwidth); heavier usage requires staking TRX, receiving a delegation, or burning TRX to cover the bytes. or 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. derived from its stake with another; under Stake 2.0 the staked TRX stays put, so value-tracing sees nothing move. The only artifact is the delegation record.

This one reads differently from the other four: it is an operational-sibling relationship rather than a transfer of control. An operator 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. a secondary wallet with delegated Energy is one of the most common benign patterns on the chain. It still matters for attribution — the party that fuels a wallet has a working relationship with it — but the reasons delegation is a strong owner-operator lead, and the marketplace false-positive that undermines the naive reading, are covered in Who Pays the Fees? and The Resource-Delegation Trail.

4. Wallet sale or handoff

A sale takes one of two on-chain shapes, and only one of them is visible. The visible handoff rewrites the Owner permission to the buyer with a type-46 update — the same signature as Outcome 2, distinguished by what follows: normal use rather than a drain. The invisible handoff is the retained-key sale, and it leaves no on-chain state change at all. The seller hands over the private key off-chain; the same address keeps signing; the permission structure never changes. This is the direct consequence of the default-self-key rule above — when control is a key, a key handover is a complete transfer that the chain cannot see.

What the invisible sale does leave is a funding-trail divergence. A new party begins to dominate funding into a wallet whose keys never moved, and that divergence between the historical funder and the current one is the only residue the analyst gets. The deep treatment — the sale shapes, the retained-key flag, and the evidence bar for calling one — lives in The Wallet That Woke Up.

5. Dormant revival

The signature here is temporal rather than a contract type: the single largest gap between consecutive transactions in the account’s history crosses a dormancy threshold, and then a new entity reactivates the wallet. One caveat belongs up front — the chain has no concept of a dormant account. Dormancy is an investigator’s yardstick, and the day-count markers commonly used to grade a silence are methodology conventions — the protocol defines no such constants. The markers themselves, and the weight a reactivating entity carries, are owned by the dormancy article linked above.

Revival is also the odd member of the five: it is a timing overlay rather than a mechanism. A revival tells you when the new hand arrived — after a long, documented silence — while the mechanism still comes from one of the other four signatures. A dormant wallet can wake into a drain, a hijack, a delegation relationship, or a sale, and the long quiet stretch beforehand raises the stakes of whichever one it wakes into.

The differential, in order

The five outcomes resolve on a short ordered set of questions, keyed to the signatures above — and absence is as diagnostic as presence at every step.

Check first for a type-46 permission update. If one appears, you are in hijack-or-visible-sale territory, and the post-rotation activity decides between them: a rapid drain to fresh addresses reads hostile, sustained ordinary use reads like a handoff. If no type-46 appears but the account emptied through type-1 or type-31 outbound moves — signed by the existing key, or by a spender exercising a prior approval — it is a silent drain. If nothing about the keys changed and the only tie to the new party is a type-57 delegation with no TRX moved, it is a delegation grant. If there is no on-chain state change at all and the funding trail shows a new dominant payer, the retained-key sale is on the table. And if a long documented silence precedes whichever pattern you found, layer revival on top of it.

Outcome	Signature present	Signature absent	Reads as
Silent drain	Type-1 / type-31 outbound emptying the account	No type-46	Key compromise (or approval drain if a spender signed)
Permission hijack	Type-46, then hostile activity	—	Deliberate seizure of signing rights
Delegation grant	Type-57, no TRX moved	No key change	Operational sibling / secondary wallet
Wallet sale	Type-46 then benign use, or nothing at all	Retained-key shape: no state change	Handoff; invisible variant shows only a funding divergence
Dormant revival	Long gap, then new activity	—	Timing overlay on any of the above

One honest complication keeps the table from being a clean map: the signatures are not mutually exclusive. A sale can wear the hijack’s type-46 signature or leave no signature at all, and revival is a modifier rather than a branch of its own. The five are end-states an analyst reads, not five disjoint transaction types — hold the outcome and the signature as separate columns in your notes, because two outcomes can share a signature and one outcome can have two.

Not the Steem kind of takeover

One disambiguation is worth a sentence because the word “takeover” carries both meanings. Everything in this article is account-level: one wallet’s keys, permissions, and funding. The 2020 Steem incident — exchanges voting customers’ deposited tokens to seize a chain’s validator set — is a chain-level governance capture, a different phenomenon with different mechanics, covered in The Steem Takeover. An analyst reading a single TRON address is never looking at that.

A signature is a lead

Close the diagnosis the way you opened it: with restraint. Each of the five signatures identifies an end-state; none of them, alone, proves wrongdoing. Delegation grants are everyday operational plumbing. Sales — visible and invisible — are routine. Even a type-46 rotation is often the legitimate holder hardening their own account. What escalates a signature toward a hostile reading is the accompanying evidence: a rapid post-rotation drain, a removed original key, an unexplained new payer into a long-quiet wallet. The umbrella discipline — treating every attribution finding as a lead to corroborate, not a verdict to announce — is laid out in Who Controls a TRON Wallet?, and it applies with full force here. The taxonomy tells you which of the five you are looking at; the case still has to be built.

Sources

• TRON Developer Hub — Multi-Signature — official protocol documentation: the Owner permission as the account’s highest privilege, the default self-key at threshold 1, the all-at-once permission override, and the 100 TRX update fee.
• tronprotocol/protocol — Tron.proto — canonical protocol definition of the contract-type IDs the differential keys on: AccountCreateContract (0), TransferContract (1), TriggerSmartContractTRON's contract-call transaction type (ContractType 31): every invocation of a deployed smart contract, including every TRC-20 token transfer, travels as a TriggerSmartContract naming the caller, the contract, and an encoded call-data payload. Two forensic consequences follow. The transaction's visible destination is the contract, not the payee — a token transfer's real recipient and amount sit inside the call data and the resulting Transfer event. And whether it activates a new account depends on what the call carries, not on the transaction type: a TRC-20 transfer moves no native value and activates nothing, so an address that has only ever received TRC-20 tokens holds balances in contract storage while remaining unactivated at the protocol level — but a contract that moves TRX or a TRC-10 token to an uninitialized address during the same kind of call does activate it, for an extra 25,000 Energy. (31), AccountPermissionUpdateContract (46), DelegateResourceContract (57), UnDelegateResourceContract (58).
• TRON Developer Hub — TRC-20 Contract Interaction — official documentation of approve and transferFrom, the mechanism behind the approval-drain sub-variant of Outcome 1.
• TIP-467 — Stake 2.0 — protocol improvement proposal defining Stake 2.0 resource delegation, including that delegated resources move while the staked TRX does not.
• Halborn — Explained: The Poloniex Hack (November 2023) — security-firm casework rather than protocol documentation; dated illustration of the direct key-compromise drain pattern with no permission rotation.
• CertiK — Poloniex Incident Analysis — independent security-firm corroboration of the same November 2023 incident.
• Token Trace — TRX Wallet Account Permission Change Scam — forensics-firm case writeup dated November 27, 2023; dated illustration of the permission-hijack end-state, with both addresses verifiable on-chain.
• account_contract.proto — tronprotocol/protocol — the protocol definition of AccountPermissionUpdateContract (owner_address, owner, witness, actives) — 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 DelegateResourceContract (owner_address, resource, balance, receiver_address, lock, lock_period) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.
• smart_contract.proto — tronprotocol/protocol — the protocol definition of TriggerSmartContract (owner_address, contract_address, call_value, data, call_token_value, token_id) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.