不分享秘密
Never share secrets
逐次确认
Review each request
先核对再提交
Verify before submission
Connection is not blanket permission
Connecting to a DApp usually establishes a session and may expose a public account address. Asset changes generally require a separate signature, approval, or transaction. Treat every prompt as a new decision even when you already trust the site and have connected before. For Signature Requests, convert this principle into a repeatable check: identify the action, verify the network and counterparty, and review the important fields again before signing or submitting. This is more reliable than trusting colors, icons, or familiarity alone. If the result does not match your expectation, stop, keep the transaction hash, contract address, or network details, and verify them through a trusted source. Do not skip checks because a page creates urgency or promises a reward.
Verify the domain before the prompt
Phishing sites can copy design, wording, and logos. Check the domain and how you reached it before connecting. A wallet request should match an action you deliberately initiated. If a signature or approval appears unexpectedly, reject it and investigate rather than trying to make the prompt fit your expectations. Message signatures may require no gas yet still carry authorization or login meaning. “Free to sign” should never be interpreted as “safe to sign.” If the result does not match your expectation, stop, keep the transaction hash, contract address, or network details, and verify them through a trusted source. Do not skip checks because a page creates urgency or promises a reward.
Approval scope matters
Token approvals can allow a contract to move assets under defined conditions. Review the spender address, network, and allowance. Very broad or long-lived permissions increase exposure. Revoking an approval can reduce stale access, but the revocation itself may require an on-chain transaction and gas. For Signature Requests, convert this principle into a repeatable check: identify the action, verify the network and counterparty, and review the important fields again before signing or submitting. This is more reliable than trusting colors, icons, or familiarity alone. If the result does not match your expectation, stop, keep the transaction hash, contract address, or network details, and verify them through a trusted source. Do not skip checks because a page creates urgency or promises a reward.
Operational checklist
- Verify the domain or entry point
- Confirm the active network
- Review addresses or contract targets
- Check amount, fee, or permission scope
- Keep the transaction hash after broadcast
Disconnecting is not revoking
Ending a DApp session closes the connection but may not remove permissions already recorded on-chain. Periodically review approvals you no longer need, compare contract addresses with trusted sources, and keep the difference between session access and token allowance clear. For Signature Requests, convert this principle into a repeatable check: identify the action, verify the network and counterparty, and review the important fields again before signing or submitting. This is more reliable than trusting colors, icons, or familiarity alone. If the result does not match your expectation, stop, keep the transaction hash, contract address, or network details, and verify them through a trusted source. Do not skip checks because a page creates urgency or promises a reward.
Turn knowledge into a repeatable checklist
The goal of learning Signature Requests is not to collect terminology but to make actions verifiable. Keep a personal checklist for trusted entry points, the active network, addresses or contracts, amounts or permission scope, and post-transaction verification. Reject requests you cannot explain. imtoken will never ask you to enter a seed phrase, private key, recovery phrase, or verification code on a webpage, and on-chain transactions generally cannot be unilaterally reversed by a wallet.