On this page
Core security principlesCommon risk scenariosHow to recognize suspicious requestsWhat to do when something looks wrongBuild a durable security routineDo not share a seed phrase, private key, or verification code with any person or website. Review the network, address, and request details before transferring, signing, or approving.
Core security principles
To understand Approval Security, separate what a wallet interface displays from what the blockchain actually records. When working with approved spender, permission scope, and allowance, identify the active network, the relevant address or contract, and the exact request you intend to complete. A wallet can organize these details, but it cannot determine whether an unfamiliar source is trustworthy on your behalf. Before confirming an on-chain action, verify the destination, network context, and purpose of the request.
A useful starting question
Before acting, ask: “What result do I expect from approved spender, and where should that result be visible?” This keeps the task anchored to a concrete outcome rather than to interface prompts alone.
Common risk scenarios
In practical use, permission scope often appears together with DApp approvals. Read the network name and any address or contract identifier first, then review the amount, permission, or expected result. Do not approve simply because a site uses urgency, a reward message, or an impersonated support prompt. The authoritative result of an on-chain action is the blockchain record; the wallet interface is useful context, while a reputable block explorer can provide an additional independent check.
What to inspect
Pay particular attention to approved spender, permission scope, allowance. Stop and verify again if the source is unclear, the request differs from your intent, or sensitive credentials are requested.
Do not rely on guarantees
No workflow can promise absolute security or guaranteed recovery. Security decisions depend on the request source, permission scope, device environment, and the resulting blockchain record.
How to recognize suspicious requests
Actions involving allowance also depend on network conditions. Fees and confirmation times can change with congestion, transaction complexity, and protocol rules. A pending transaction is not automatically a failed transaction, and repeatedly submitting the same action without understanding its status can create additional confusion or cost. Check the transaction hash, the selected network, and existing records before deciding what to do next.
Verification sequence
For permission scope, verify the network first, then the address or contract, followed by the amount or permission, and finally the transaction status. If any one element is inconsistent, stop before creating another request.
What to do when something looks wrong
Security should be part of routine use of DApp approvals and revocation. Seed phrases and private keys remain under the user’s control and should never be sent to a website, support agent, or third-party application. Treat every signature and approval as a separate decision. A DApp that was appropriate to connect to previously should not receive automatic trust for every future request or permission change.
Seed phrases and private keys are controlled by the user. imtoken staff will never ask for them or for verification codes. On-chain transfers are generally not reversible by a wallet alone, and third-party DApps or smart contracts may carry independent risks.
Build a durable security routine
A repeatable review process is more useful than rushing through a one-time action. Before a Approval Security task, define the intended outcome and check the network, address or counterparty, amount or permission, expected fee, and final result in that order. After completion, retain the transaction hash or another useful record and periodically review permissions that are no longer needed. These steps do not eliminate technical or market risk, but they make decisions clearer and troubleshooting more systematic.