Signature Requests

A wallet connection is only the start of a session

Distinguish message signatures, transaction signatures, and contract interactions. Connecting a DApp usually exposes the selected public address and current network. It is not the same as sending assets, signing a message, approving tokens, or submitting a contract transaction.

For “Signature Requests”, avoid treating every later popup as trusted because the connection succeeded. Message signatures, transaction signatures, token approvals, and contract calls should each be evaluated as separate decisions.

Identify the request type before signing

A message signature can support login or authorization semantics. A transaction signature submits an on-chain state change. A token approval can grant a contract future access to an allowance. Similar confirmation screens can therefore have very different effects.

Review the domain, account, network, contract, spender, token, and allowance. If a page emphasizes a countdown or reward while hiding permission details, stop and verify the source instead of accelerating the decision.

Persistent permissions need ongoing management

Some token approvals remain active after the browser session ends. Disconnecting a DApp does not revoke an on-chain approval. Review long-lived permissions on the correct network and remove those that are no longer needed.

For “Signature Requests”, treat the approval target and allowance as security-relevant data. A DApp that worked safely in the past can still face contract, governance, or dependency changes later.

• Check the active network
• Verify address, contract, or approval target
• Review amount, fees, and request details
• Keep the transaction hash when relevant
• Reject requests you cannot explain

Recovery secrets do not belong in DApp forms

Normal DApp connections and smart-contract interactions do not require a seed phrase, private key, recovery phrase, or wallet verification code to be entered into a web page. Close any page that asks for those items to “sync” or “validate” a wallet.

The user makes the final signing decision. imtoken can present the request, but third-party applications and smart contracts can still be risky. If the effect cannot be explained, declining the request is the safer default.