- 01
Verify the full address
Verify the full address — checks and common mistakes
A useful way to approach this topic is to separate what the interface displays from what the blockchain actually records. Transaction Checks is best understood through the specific decisions a user makes, not just through interface labels. Use a repeatable check for address, network, amount, gas, token contract and transaction hash.
For practical review, split the request into five layers: network, address or contract, asset or permission, network fee, and resulting transaction state. The network tells you where execution occurs; the address or contract identifies the target; the asset or permission defines the scope; gas reflects network execution cost; and the transaction hash provides a durable reference for verification. If an application shows only vague language such as “continue”, “verify” or “claim”, use the wallet confirmation screen to inspect what is actually being requested.
Keep seed phrases and private keys under your own control. imtoken personnel will not request a seed phrase, private key or verification code. Before transferring, signing or approving, check the network, destination or contract and the exact action. Confirmed blockchain transactions are generally not reversible by a wallet provider, and third-party DApps and smart contracts can introduce independent risks.
If a critical field cannot be verified, stopping and checking independently is safer than completing the action under time pressure.
- 02
Match the network with the recipient
Match the network with the recipient — checks and common mistakes
Most mistakes in this area come from missing context rather than from a single button press. A practical check for this topic is: verify the full address; then consider match the network with the recipient before moving to the next action.
For practical review, split the request into five layers: network, address or contract, asset or permission, network fee, and resulting transaction state. The network tells you where execution occurs; the address or contract identifies the target; the asset or permission defines the scope; gas reflects network execution cost; and the transaction hash provides a durable reference for verification. If an application shows only vague language such as “continue”, “verify” or “claim”, use the wallet confirmation screen to inspect what is actually being requested.
Keep seed phrases and private keys under your own control. imtoken personnel will not request a seed phrase, private key or verification code. Before transferring, signing or approving, check the network, destination or contract and the exact action. Confirmed blockchain transactions are generally not reversible by a wallet provider, and third-party DApps and smart contracts can introduce independent risks.
There is no benefit in rushing an unfamiliar signing request; understanding the request should come before confirmation.
- 03
Separate amount from network fee
Separate amount from network fee — checks and common mistakes
Start with the user decision: identify the network, counterparty or contract, requested permission and expected result before confirming. On-chain activity is contextual. Network, address, contract, amount, permissions and transaction status can each change the meaning of what the wallet is showing.
For practical review, split the request into five layers: network, address or contract, asset or permission, network fee, and resulting transaction state. The network tells you where execution occurs; the address or contract identifies the target; the asset or permission defines the scope; gas reflects network execution cost; and the transaction hash provides a durable reference for verification. If an application shows only vague language such as “continue”, “verify” or “claim”, use the wallet confirmation screen to inspect what is actually being requested.
Keep seed phrases and private keys under your own control. imtoken personnel will not request a seed phrase, private key or verification code. Before transferring, signing or approving, check the network, destination or contract and the exact action. Confirmed blockchain transactions are generally not reversible by a wallet provider, and third-party DApps and smart contracts can introduce independent risks.
The goal is to be able to explain which network is involved, who or what the request targets, what permission is being granted and what on-chain outcome may follow.
- 04
Track the transaction by hash
Track the transaction by hash — checks and common mistakes
A repeatable verification habit is more durable than memorizing one interface because networks and applications can change over time. imtoken staff will not ask for a seed phrase, private key or verification code. Do not share those credentials with anyone, and do not rely on remote-control support for sensitive wallet operations.
For practical review, split the request into five layers: network, address or contract, asset or permission, network fee, and resulting transaction state. The network tells you where execution occurs; the address or contract identifies the target; the asset or permission defines the scope; gas reflects network execution cost; and the transaction hash provides a durable reference for verification. If an application shows only vague language such as “continue”, “verify” or “claim”, use the wallet confirmation screen to inspect what is actually being requested.
Keep seed phrases and private keys under your own control. imtoken personnel will not request a seed phrase, private key or verification code. Before transferring, signing or approving, check the network, destination or contract and the exact action. Confirmed blockchain transactions are generally not reversible by a wallet provider, and third-party DApps and smart contracts can introduce independent risks.
That habit makes it easier to reason from verifiable on-chain evidence even when an interface changes.
Completion checklist
- Network matches the intended asset or DApp.
- Address, contract or spender has been independently checked.
- Amount, permission scope and gas are understood before signing.
- Transaction hash is retained when an on-chain transaction is submitted.
Safety reminder
If any critical field is unclear, stop and verify it independently. Confirmed blockchain transactions are generally not reversible by a wallet provider.