Wallet Security: Why the Shift from Custody to Pre-Signature Protection
Even if your private key is perfectly safeguarded, your assets can still be moved right under your nose if you have no idea what you are approving when you sign. This is not a case of a leaked private key — it is a case of signing a "contract" you cannot read.
The Private Key Was Not Leaked, but the Money Is Gone: The Problem Lies in the Signing Step
For the past five years, the central narrative of wallet security has been "safeguard your seed phrase." That logic still holds today — the private key remains the ultimate control over your assets. But when your assets do not just sit idle in a wallet and instead constantly interact with DeFi protocols, dApps, and cross-chain bridges, every single "confirm" action puts that private key to use.
The issue is that most confirmation dialogs displayed by wallets are completely unreadable for the user.
What you see might be a string of hexadecimal data, a function name, or a generic "Approve" or "Sign Message." Technically this information is correct, but for an ordinary user it is not enough to support any meaningful judgment. This is "blind signing" — you did sign, but you have no idea what you signed.
When the Ethereum Foundation pushed forward the Clear Signing standard, it made an explicit point: the final step in many major attacks is not a code vulnerability, but a user approving a transaction they cannot truly understand.
How Blind Signing Turns into Actual Loss: The Two Most Common Techniques
Scenario A: Permit signature phishing
You visit a website advertising "allowlist registration." The site asks you to sign a message to "verify your identity." You assume it is a routine operation, but what you actually sign is a Permit authorization (EIP-2612 standard). Once the attacker obtains this authorization, they do not need your private key; they can call transferFrom at any time and drain the specific tokens from your wallet.
The stealthiness of this type of signature lies in the fact that it generates no on-chain transaction. There is no "transfer record" in your wallet. By the time you notice, the assets have already been moved. The security team at OneKey has explicitly highlighted in their analysis that the Permit signature has become the most favored phishing method for hackers in recent years.
Scenario B: The blind signing trap in Safe multi-sig wallets
Teams and managers who use Safe (formerly Gnosis Safe) multi-signature wallets face another type of risk. A multi-sig transaction requires confirmation from multiple owners. If you are the last signer and you see that everyone else has already signed, you might hastily click "confirm." But if the transaction content is displayed as an unintelligible hash, what you are actually approving could be a contract upgrade transaction — through which the attacker can transfer the entire wallet's control away.
The attack that Bybit suffered in 2025 falls into this category: hackers compromised the Safe developer environment, tampered with the information displayed to the signers, and ultimately tricked the signers into approving a malicious upgrade transaction, resulting in a loss of nearly $1.5 billion.
What Pre-Signature Protection Can Do: From "Blind Signing" to "What You See Is What You Sign"
The core objective of pre-signature protection is simple: enable you to truly understand what consequences this transaction will cause before you click "confirm." Currently, the industry is advancing in three main directions. You can check whether your wallet already supports them.
Step 1: Enable transaction simulation to see a "pre-execution" before signing
What it does: Before signing, the wallet pre-executes the transaction in a local virtual environment and displays balance changes, contract call paths, and authorization changes.
How to do it:
Check whether the wallet you are using has a built-in transaction simulation feature. Wallets like OneKey have already made this a standard security feature, automatically triggering a simulation for every signing request without any manual activation.
If your wallet does not support it, you can use third-party tools like Tenderly for transaction simulation, but this requires a higher level of technical skill.
What counts as completed: Before signing, you can see a clear summary of balance changes, such as "ETH -5.2, USDC -25,000," rather than a pile of hexadecimal data.
Prerequisites: The wallet version must support this feature. Some older wallet versions only display raw data and do not support transaction simulation.
Common reasons for failure: Some cleverly designed attack contracts can detect simulated calls and return normal results, only executing malicious logic when the transaction is actually broadcast (time‑dependent attacks). Transaction simulation is a supplementary tool and cannot replace human judgment.
Risk warning: Simulation consumes no gas and generates no on-chain transaction, but the simulation result is based on the current on-chain state. The state may have changed by the time of actual execution (for example, due to price movement), causing the results to not be fully identical.
Step 2: Parse signature content and reject "unreadable" signature requests
What it does: Translates raw transaction data into human‑readable fields — who the recipient is, what asset is being transferred out, which address is being granted authorization, and what the authorization limit is.
How to do it:
Use a wallet that supports Clear Signing. OneKey's SignGuard and imToken's Sigil both offer signature parsing that displays structured content before signing.
For EIP-712 structured signatures and EIP-2612 Permit signatures, confirm that the wallet can parse them and explicitly prompt "You are authorizing X amount of tokens to address Y."
What counts as completed: The signature request no longer shows garbled text or just a function name, but a complete description of the operation: who initiated it, which contract is being called, which function is being executed, what tokens and amounts are involved, and to whom the authorization is granted.
Prerequisites: The wallet must integrate a signature parsing engine. Ordinary wallets only display raw calldata and cannot provide readable information.
Common reasons for failure: Some wallets support parsing only on specific chains or for specific contracts. For less common contracts or complex calls, the display may be incomplete.
Risk warning: If the signature request presented by the wallet cannot be parsed into readable content, do not click confirm. This is the most straightforward criterion — do not sign anything you cannot read.
Step 3: Build a "three‑question" habit before signing
What it does: Before every signature, proactively confirm three key questions.
How to do it, broken down by scenario:
Scenario A — Transfer-type operations:
Compare the full recipient address character by character; do not just check the first and last few characters. Scammers often use "address poisoning" techniques to forge similar‑looking addresses.
Confirm that the token type and the chain align with your intention (e.g., USDT on Ethereum vs. USDT on Tron).
Scenario B — Approval-type operations (Approve / Permit):
Confirm that the authorization target (the spender address) is the official contract address of the current dApp.
Confirm that the authorization limit is reasonable — if you only intend to trade once, you should not grant an "unlimited" allowance.
If the wallet shows a message like "You are approving the token without any additional benefit," reject it immediately.
What counts as completed: You can clearly state, "For the operation I am about to approve, this is where the funds will go, this is whom I am authorizing, and this is the allowance amount."
Prerequisites: None. This is a habit anyone can develop.
Common reasons for failure: Trusting the information displayed by the dApp's frontend rather than the information parsed by the wallet. The dApp frontend can be attacked or impersonated; the page may display "Claim rewards" while actually calling a transfer function.
Risk warning: Even if the wallet's parsed output looks normal, you should still cross‑check the source of the operation. For requests from unfamiliar websites or new dApps, even if the parsed result appears normal, it is advisable to pause the operation and verify through official channels.
Extended Risks in the Age of AI Agents
As you start using AI agents to execute on‑chain operations automatically, the importance of pre‑signature protection grows even further. Because what truly decides the flow of funds is no longer just you; it also includes the agent's understanding, external data sources, and several other links. If even one of these links is poisoned, the "execute for me" you see can turn into a "transfer for me" that the attacker wants.
There have already been recent cases where attackers used prompt injection on X to trick AI‑agent‑related systems into executing abnormal transfers. The core of such incidents is not a private key leak, but rather how the AI system interprets input, how it obtains permissions, and how it passes instructions to the on‑chain execution layer.
Therefore, if you plan to use an AI agent to operate your wallet, you must choose a wallet that supports a verifiable UI — one that ensures a trustworthy correspondence between what the wallet displays and what is actually executed on‑chain, rather than simply trusting an operation summary generated by the agent itself.
Confirm that you have established pre‑signature protection: The next time any wallet displays a signature request, you should be able to state within three seconds "what assets of mine this operation will move, where they are going, and to whom." If you cannot, do not click confirm. This habit matters more than any security tool.
Next step: Check whether the wallet you are currently using has built‑in transaction simulation and signature parsing features. If not, consider migrating to a wallet that supports Clear Signing (such as OneKey or the latest version of imToken). This is not about a "better experience"; it is a basic configuration for asset security.
