In an article published by MarsBit, author Gao Mengyang examined a wallet risk often described as a "malicious multisig" case: the USDT balance is still visible, no outgoing transfer appears in the transaction history, yet the user cannot send funds because the wallet now reports insufficient signing authority.
After checking further, the user may find that the wallet's permissions have been changed. A transaction that once required only the holder's own signature now needs approval from an unfamiliar address. The funds have not left the address, but control may already have shifted.
The article says this pattern differs from a more familiar virtual-asset theft scenario. An attacker may not move the assets right away. Instead, the attacker first uses the wallet's permission mechanism to restrict the original holder's ability to dispose of the assets. That raises a set of legal questions: if the coins are still at the same address, have they already been stolen; and if the user was induced to sign something, should the conduct be treated as theft or fraud?
According to the article, those questions matter not only for how a victim reports the case to police, but also for what evidence should be prepared and whether there is still a realistic chance of recovering the assets.
What changes in a malicious multisig case is control, not necessarily the balance
The article begins with a distinction between two issues: whether assets are still in the wallet, and who has the power to control those assets.
Using the TRON network as an example, it explains that the account permission system allows different addresses to be assigned different signing weights, while a threshold determines how many signatures are needed to complete a transaction. In ordinary use, a user can manage an account with a private key under their control, or deliberately set up multi-party signing for cases such as corporate treasury management.
The situation changes if someone, without authorization, obtains a private key or seed phrase, or induces the user to sign a malicious permission-change transaction that alters the wallet's Owner or Active permissions.
The article gives a simple example. A user who could previously transfer funds alone may, after the change, need a second signature from an unfamiliar address. In a more serious case, the other party may already hold enough signing weight to change permissions or move assets independently, while the original user can do little more than look at the balance.
On-chain, the assets may still be sitting at the original address and no transfer may have occurred. In practical terms, though, the relationship of control has changed.
The article also points to an easily overlooked detail: a malicious multisig setup does not always mean the attacker can already move the assets alone.
- In some cases, the attacker can control the wallet independently.
- In some cases, neither side can complete a transfer alone.
- In others, only certain permissions or operations are restricted.
Which of those situations applies depends on the account's permission addresses, signing weights, threshold and the operations that remain executable.
For that reason, the article says a failed transfer prompt is not enough by itself to conclude that a malicious multisig attack has occurred, and it is not enough to jump straight to the conclusion that all funds have already been stolen. The real questions are who changed the permissions, whether the change was validly authorized, who can control the wallet now, and whether the original holder has in substance been excluded from disposing of the assets. Those facts are the starting point for any later criminal-law analysis.
Theft, fraud, or another offense: the label cannot be decided from the outcome alone
The article says that, in judicial practice, the illegal acquisition of virtual assets may involve theft, fraud, or crimes related to computer information systems. Which charge fits cannot be determined solely from the fact that a wallet was turned into a multisig arrangement.
Unauthorized permission changes followed by an asset transfer
The first scenario is one in which an attacker illegally obtains a private key, seed phrase or similar credentials, changes the wallet permissions without consent, and then transfers the assets to an address under the attacker's control.
In that setting, the article says, if evidence shows an intent of illegal possession and shows that the actor took control of the assets without the right holder's consent and actually moved them, the case may support a theft analysis.
At the same time, the article notes that virtual assets have a data dimension as well as characteristics of property-related economic interests. In different cases, there is still debate over the path of criminal-law protection and over how the amount involved should be determined. Some judicial views emphasize the property nature of virtual assets and treat unlawful taking as theft. Other cases evaluate the conduct from the angle of computer information system data security.
So even where assets have in fact been moved, the article says the charge still cannot be fixed without looking at the method used, the nature of the assets and the available evidence.
False pretenses used to induce a user to sign a permission-change transaction
The second scenario, which the article says deserves closer discussion, involves deceptive statements. A user may be told that an account security upgrade, platform verification or routine transaction step is required, then asked to click a link, connect a wallet and confirm a signature. The user believes the action is ordinary, but what is actually signed is a transaction that changes account permissions.
On the surface, the user did click the confirmation button. Legally, however, the article says that is not the same as agreeing to let another person take control of the assets.
It explains that one important distinction between theft and fraud is whether the victim, because of deception and a mistaken understanding, disposed of property. If the user was merely induced to complete a technical operation and did not understand that the operation would allow someone else to control the assets, then whether the user had the legally relevant intent to dispose of property still requires further analysis.
By contrast, if the actor fabricated facts and caused the user, under a mistaken belief, to hand over the assets or the practical power to control them, the conduct may be evaluated as fraud.
The article's point is that deceptive language does not automatically make a case fraud, and a user signature does not automatically rule out theft. In a malicious multisig case, whether a permission change counts as a disposition of property, and whether the actor has already obtained criminal-law control over the assets, still depends on the specific facts.
Malicious software or technical intrusion used to obtain wallet control
The third scenario involves malicious programs or technical intrusion.
According to the article, if the attacker also illegally obtained authentication information, intruded into, or illegally controlled a computer information system, and if the statutory elements and threshold for criminal liability are met, the conduct may also implicate crimes related to computer information systems under Article 285 of the Criminal Law.
But the article adds an important qualification: an on-chain permission change does not by itself mean the actor necessarily exercised illegal control over a computer information system in the criminal-law sense. Whether there was technical intrusion or unlawful acquisition of system data must be examined separately.
Put differently, a malicious multisig setup is a technical result. Criminal liability still turns on what the actor actually did, how the permissions were obtained, what benefit was gained and what consequences followed.
If the coins have not moved, has there been a property loss?
The article describes this as one of the harder questions in malicious multisig cases.
In a conventional theft case, the change in possession is usually straightforward: property is taken from the victim's control by someone else. Digital assets are less simple.
Suppose a wallet was originally managed solely by the user, then its permissions were maliciously altered so the user can no longer transfer funds. The on-chain balance has not changed, and the assets have not entered a new address controlled by the attacker. What, then, has the user lost?
From a practical standpoint, the article says, the user has already lost part or all of the ability to dispose of the assets. Even if the balance remains visible, normal transfers, payments or other lawful dispositions may no longer be possible.
That does not automatically mean a completed property offense has already occurred. The article says an infringement of control and the completion of a property crime are not necessarily the same thing.
Several factual distinctions still matter: whether the actor has obtained exclusive control; whether the user can still restore operation through some other valid permission; whether neither side can transfer alone; whether the attacker has actually moved the assets; and whether there has been further conduct aimed at illegal possession.
Those facts affect how one evaluates the change in possession, whether an offense is completed or attempted, the existence of actual loss and the amount involved.
The article specifically warns against treating the full virtual-asset balance shown in the wallet as the amount of actual loss without more. The state of control, the fact of any actual transfer and the basis for valuation may all need further verification.
Still, the article says the absence of an outgoing transfer does not remove criminal risk. If someone, through deception or unauthorized acquisition of permissions, systematically seizes control of another person's wallet, the conduct may still need to be assessed under the relevant offense structure and stage of execution even before any asset transfer is completed.
That is why, in the article's view, "the coins have not been moved" cannot be equated with "no crime occurred," and "the wallet cannot be operated" cannot be equated with "all assets have already been stolen." Both conclusions are too simple.
What evidence should be prepared after a malicious multisig incident
The article says many people first try to argue with the other party or search online communities for someone who claims to be able to remove the multisig restriction. From the standpoint of protecting one's rights, it says, the more urgent task is to identify the permission change quickly and preserve evidence.
Show who originally controlled the wallet
A wallet address alone does not directly prove who held the rights to the assets in the real world, the article says. Anyone seeking relief through criminal procedure should gather wallet creation and usage records, historical transfer records, the source of the assets, transaction vouchers and other materials that can show who actually controlled the wallet before the incident.
That becomes especially important where assets were held by another person, jointly managed, or placed in a corporate wallet. In those cases, the article says it is necessary to distinguish between the asset right holder and a mere technical manager, and to clarify the original scope of authorization between them.
Locate the exact on-chain record of the permission change
On networks that support on-chain permission queries, the article recommends checking account permissions through the official block explorer, with attention to the transaction hash (TxID) of the abnormal permission-change transaction, the time it occurred, the block record, the signing addresses before and after the change, the weights and the signature threshold.
Those details can help explain why the wallet can no longer be operated and can help establish when the abnormal state was formed.
If possible, the article says, technically qualified personnel can assist in analyzing the permission-change process, and the original on-chain records should be preserved in a form that can be verified, rather than relying only on a screenshot of the balance.
Reconstruct how the other party obtained the chance to act
If someone asked to inspect the user's phone, sent an operation link, offered to help use the wallet, or requested a signature in the name of security verification before the incident, the article says related chat logs, web links, transaction-scene materials and device records should be preserved as far as possible.
It adds that on-chain records can usually prove that a permission-change transaction occurred, but they do not necessarily prove who operated the wallet in the real world. Linking an on-chain address to a specific person often requires device traces, chat records, transaction relationships and scene evidence that corroborate one another.
Assess whether there is still room for a safe response
After discovering an abnormality, the article warns against sending more funds to a suspicious wallet or paying any so-called unlocking fee. It also says users should not casually provide a private key or seed phrase to unfamiliar technicians.
If the account still retains lawful and effective operating permissions, a trusted professional should verify possible safe handling options as soon as possible, while the user preserves the necessary evidence. If the permissions can no longer be restored, the next step is to assess, based on the facts, possible on-chain tracing, criminal complaints and other avenues of relief.
Where a crime is suspected, the article says users may bring preliminary materials to public security authorities to file a report. Public security authorities should accept and review the relevant reporting or complaint materials according to law, though whether a criminal case is formally opened still depends on whether the legal conditions are met.
Even if no asset transfer has yet been completed, the article says the user can still truthfully describe the unauthorized permission change, the impairment of control and the potential asset risk, rather than describing an uncompleted transfer as if a theft had already been completed.
Control matters more than the visible balance
The article closes by saying that malicious multisig incidents are easy to underestimate precisely because they do not always change the wallet balance right away. On the surface, the coins are still there. In practical terms, the original holder may already be unable to control them.
For criminal-law analysis, the article says, it is not enough to look only at whether a transfer eventually occurred. One must also examine how the permissions were changed, whether the control relationship has already changed in substance, and what means were used to obtain that control.
If the full balance is immediately treated as theft loss after a malicious multisig change, the article says, that may ignore the real control differences created by different permission structures. If one concludes there is no illegal or criminal issue simply because the assets have not moved, that may ignore conduct such as unauthorized acquisition of permissions that has already taken place.
For affected users, the article argues, the priority is not to rush to label the event as theft or fraud. The first task is to clarify the wallet's original control structure, the process of the abnormal permission change, the actual state of the assets and the conduct of the people involved.
Only when the facts and evidence are sufficiently complete, the article says, is it possible to assess criminal liability, choose an appropriate rights-protection path and evaluate the realistic possibility of recovering the assets.
The balance remaining in the wallet does not mean the risk has not already materialized. The real question is whether the power to control the assets is still in the holder's own hands.
