imtoken will never ask for your seed phrase, private key or verification code. Always review the address, network and request details before transferring, signing or approving.
imtoken
中文Download
Home / Signature Requests
imtoken · Knowledge and practical checks

Signature Requests

Wallet signatures prove account control or authorize actions, but signature types have different effects. Understanding messages, transactions and structured data helps prevent blind signing.

Use the page as a decision guide: identify the network, account and request before signing or moving assets.
01Message signatures are not risk-free
02Transaction signatures change state
03Read domain and expiry in structured data
04Reject requests you cannot explain

Message signatures are not risk-free

A message signature may not create an on-chain transaction, yet it can authenticate, authorize or attest to a statement. Make sure the message matches the task you intend to perform.

A common mistake is to treat a normal-looking interface as proof that the underlying blockchain action is correct. Public addresses, transaction hashes, contract addresses and network parameters provide independent ways to verify what is happening.

Transaction signatures change state

A transaction signature usually includes recipient, value, gas and contract call data. Verify the network and understand which on-chain state will change before signing.

A repeatable order of checks is more reliable than memory. Review source, network, account, target and expected outcome each time so the same safety logic carries across wallets and DApps.

Read domain and expiry in structured data

Structured signatures can include domain, chain ID, nonce, expiry and permission fields. Readable fields do not make a request safe by themselves; context and source still matter.

When a task involves a third-party contract, bridge, validator or web service, separate that external risk from the wallet itself. A wallet can display and sign a request, but it cannot guarantee the safety of outside code or services.

Reject requests you cannot explain

If a page says “sign to continue” but cannot explain the request and outcome, stop and verify the source. Do not sign under pressure from supposed support, airdrops or time-limited rewards.

Put this concept back into the current network, account and request type before acting. Identify what the interface is asking for, then decide whether a signature, gas payment or ongoing permission is actually required.

Practical checklist

  • Confirm that “Message signatures are not risk-free” matches the task you intend to perform
  • Confirm that “Transaction signatures change state” matches the task you intend to perform
  • Confirm that “Read domain and expiry in structured data” matches the task you intend to perform
  • Confirm that “Reject requests you cannot explain” matches the task you intend to perform

Risk reminder

Seed phrases and private keys remain under the user’s control. Legitimate support should not ask for a seed phrase, private key or verification code. Review address, network and amount before transferring; blockchain transactions generally cannot be unilaterally reversed by a wallet. Third-party DApps and smart contracts carry risk, so review spender and permission scope and consider revoking unused approvals.

Blockchain Glossary →Network Guides →Security →