TRON multisig scams: the USDT is real, and you still cannot move it

A malicious approval lets a contract move one of your tokens up to a set amount. The account is still yours; you revoke the allowance and it is over. A rewritten TRON permission is a different animal: the account itself has changed hands. Deposits keep arriving, because receiving needs no signature. Nothing leaves, because sending does — and the network no longer recognises yours.

Nothing was stolen. The account stopped answering to you

A TRON account is not simply "one private key, one address". Every account carries a permission table that records who may sign on its behalf, how much each signer's signature counts for, and how much is needed before the network accepts it.

TRON's own documentation defines three permission types. Owner is the highest authority: it controls ownership and the permission table itself. Witness exists only for Super Representative accounts signing blocks. Active is a customisable bundle of operations, and an account may hold up to eight of them. Each permission holds a list of keys — every key an address plus a weight — and a threshold. A transaction is accepted only when the combined weight of its valid signatures reaches or exceeds that threshold. A single permission holds at most five keys.

A fresh account starts with an owner permission whose threshold is 1 and whose key list contains one entry: its own address, weight 1. You sign alone, one meets one, done. That default is where the feeling of "my key is the account" comes from. It is a default, not a law of the chain.

Rewriting that table is the whole attack. Remove your address from the owner key list, or raise the threshold to 2 while your weight stays at 1, and the outcome is identical: you can no longer sign anything by yourself.

Two routes in, one destination

Route one: somebody hands you a loaded wallet.

A seed phrase or private key "accidentally" appears in a YouTube comment, a Telegram group, or a message from a stranger who has taken an interest in you. It comes with a story — they cannot work out how to use it, help them withdraw and split it. You import the wallet and the balance is genuinely there, a few thousand USDT sitting on screen. Then the obstacle appears: a TRC-20 transfer is a contract call and consumes Energy, and this account holds no TRX, so you need to send in a little gas first. You do, and the TRX is swept straight back out.

Owner permission over that account never left the scammer's hands. The key you imported carries too little weight to sign a transfer: it can view, it can receive, it cannot send. Most people read the failure as their own inexperience and top up again, larger this time. That second top-up is the entire business model.

Route two: your own wallet gets rewritten.

You follow a link from a phishing page, a fake airdrop claim or someone posing as support, a confirmation window appears, and you approve it. That transaction is an AccountPermissionUpdateContract — an edit to the account's permissions. From that moment the contents are untouched and completely stuck.

One detail is worth knowing. TRON's documentation states that this operation is submitted in full: even when changing a single permission, the entire permission set must be resubmitted, so that access is not lost by accident. Read the other way round, that means a single transaction is enough to erase your address from the owner list. Not a gentle addition of a co-signer — a lock change.

For how to read that confirmation window field by field before you tap it, see signature phishing. For the scan-and-link delivery routes that put the window in front of you, see fake QR code approval scams.

Why the revoke dashboard shows you nothing

This is the section worth remembering. Most people reach for the wrong tool here, then read a clean screen as an all-clear.

So "I checked with a revoke tool and it was clean" proves nothing here. Revoke tools read allowance figures held inside token contracts; account permissions are account data on the chain itself. Old allowances on that other layer are still worth auditing and clearing on a schedule — the method is in the wallet approval review and revoke guide — but that guide cannot reach this problem.

By the same logic, none of these help either: importing into a different wallet app, switching RPC nodes, restoring the seed phrase one more time. A seed phrase restores the private key, and the key is not broken. The key simply no longer carries enough weight.

Three questions decide whether the account is still yours

The self-check is narrow. Pull up the account's permission table and answer three things.

• Is your address in the owner permission's key list? If it is not, you no longer hold the highest authority over that account and cannot change anything back.
• Does your weight reach the owner threshold? Being on the list is not enough. Weight 1 against a threshold of 2 means you cannot sign alone — which is where the word "multisig" in this scam comes from.
• What about the active permissions? A transaction can name the permission it is signed under (Permission_id: 0 is owner, 1 is witness, 2 upwards are active), and when none is named, owner is used — which makes owner the decisive layer. Active permissions are separate slots a flow can be pointed at, so damage there breaks anything that names them. Attackers usually rewrite both, so check both.

How to look: most TRON block explorers surface a permissions block on the account page, though the field labels differ between them. If you would rather not depend on an interface, read the chain directly — a TRON node's wallet/getaccount endpoint returns owner_permission and active_permission, each carrying its threshold and its keys list, and each key an address and a weight. Compare that list against your own address and the answer is unambiguous.

Already caught: first work out whether it is recoverable

Two situations, and they call for opposite actions.

Situation one: you are still in the owner key list and your weight reaches the threshold. You can send an AccountPermissionUpdateContract yourself and set the permissions back to you alone. Two cautions. The operation is priced at 100 TRX, so the account needs that balance first. And as noted above it is submitted in full — whatever permission set you send becomes the entire new table, so one omitted entry locks you out by your own hand. Write down the current permissions in full before you touch anything, and read them back afterwards.

One thing matters more than either of those. If the attacker's address is also still in the owner key list with enough weight of its own, they can sign whatever you can — including changing the table straight back after you fix it, or simply moving the assets while you work. In that situation the order to follow is move the funds to a clean new wallet first, then deal with the permissions. Do not leave the balance sitting there while you try to change the lock back.

Situation two: you are off the owner list, or your weight cannot reach the threshold. Then you cannot sign alone, the USDT is visible and unreachable, and the attacker can take it whenever they choose. The only action left with any value is containment: stop sending anything to that address, and replace every place it is still recorded as a destination — exchange withdrawal address books, the address you gave to people who pay you, any printed or saved receiving code. Then open a clean new wallet.

Three things not to do:

• Do not top up more TRX to see if it works this time. Route one is written around that exact moment.
• Do not hire anyone who promises recovery. Whoever messages you, comments under your post or offers to unlock the account is the same crew or the next one. This is the second harvest.
• Do not keep using the address to receive funds. It is a one-way pocket now; everything that lands in it lands for someone else.

Evidence worth keeping: when it happened, the site or account that contacted you, your address, the transaction hash of the permission change, and screenshots of the wallet errors. That is the material a report needs — the sequence is in scammed? the first 4 things to do. One more practical note: a bait wallet on TRON always uses an address beginning with T. If you are unsure which chain you are dealing with, the USDT network checker will tell you before you send anything.

Why the bait is always "just cover a small fee"

On the face of it the hook looks clumsy. Somebody hands you a wallet holding thousands of dollars and then quibbles over a few dollars of gas? But the request has a real technical basis, and once you see it the script stops working on you.

Transactions on TRON consume resources. Plain transfers spend Bandwidth; contract calls — and a TRC-20 USDT transfer is a contract call — spend Energy. Both can be obtained by staking TRX, and every account additionally receives a daily free bandwidth allowance, currently 600 and adjustable by committee proposal. Anything beyond that is paid by burning TRX: bandwidth shortfalls at 1,000 sun per byte of transaction size, energy shortfalls at 0.0001 TRX per unit of Energy.

An account that has never staked TRX has only that free bandwidth and zero Energy. So moving USDT out of it genuinely does require TRX first. The scammer never has to invent anything — a real constraint of the chain makes the request for him. It sounds reasonable because it is reasonable. What is not reasonable is that the account was never yours.

Frequently asked questions

If I re-import the seed phrase, does that fix it?

No. A seed phrase restores the private key and its address, but nothing is wrong with the key. What changed is how much weight that address carries in the account's permission table. The same key signs with the same weight in any wallet app and through any node. To judge whether the account can be recovered, check whether your address is still in the owner permission's keys list and whether your weight reaches the threshold.

Can I just send the USDT to an exchange instead?

Not being able to send is the symptom, not a workaround. A TRC-20 transfer is a contract call that must be signed by an address with sufficient permission. Once the permission table is rewritten, your signature no longer reaches the threshold and the network rejects the transaction. Wallets usually respond with a message about not being able to send from this address, or the broadcast simply fails. Read the permission table instead of retrying, and do not top up more gas to make it go through.

Why does my approval-revoking dashboard show nothing?

Because it reads a different layer. Revoke tools read token allowances — how much of a token a given spender may move. Account permissions are account data on the chain itself, recording who may sign on behalf of the account. The two are unrelated, so an account with a rewritten permission table can look completely clean in an approval dashboard. To inspect permissions, read the account's owner_permission and active_permission fields.

Can the attacker also drain my other wallets?

Permissions are set per account, so what the attacker holds is control of that one address; it does not extend to your other addresses on its own. The question is which addresses that private key controls. If the key or seed phrase was handed to you by someone else, or your own seed phrase has leaked, every address derived from it is equally exposed. The dividing line is whether the private key is in someone else's hands, not how many accounts had their permissions changed.