Wallet Security: Review the Permission Before Signing

A wallet prompt is a decision point, even when a website presents it as an administrative step. The relevant question is not whether the page looks.

Overview

A wallet prompt is a decision point, even when a website presents it as an administrative step. The relevant question is not whether the page looks familiar. It is what the requested action authorises, who requested it and whether it matches the task you intended to perform. Familiarity and permission are different kinds of information.

Protect the recovery secret separately

Ethereum’s security guidance explains common scams and the importance of protecting recovery information. It specifically warns that ethereum.org does not contact users as a support service. An unsolicited person claiming to repair a wallet should not receive its recovery phrase or private key. A convincing identity claim does not make disclosure safe. Verify support routes independently rather than following a link supplied by the supposed helper.

Explain the request in your own words

Before a hypothetical signature, try to describe what should change after approval. Which application or contract is involved? Which asset and network are relevant? Is the request a transaction, an approval or a message signature? If the interface does not let you determine that reliably, pausing is a reasonable operational response. This is not proof that the request is malicious; it is recognition that informed authorisation is missing.

Treat urgency as a change in the decision environment

A countdown, a support emergency or a disappearing reward can push the review toward speed. Build a routine that does not depend on the other party granting you time. Open known resources independently, compare the request with the intended activity and avoid experimenting with your main holdings. A separate test setup can limit some operational exposure, but it cannot turn an unknown permission into a verified safe one.

Record the action, not the secret

A useful log can contain the application, network, public transaction reference, time and reason for acting. It should not contain recovery phrases, passwords or private keys. When something looks wrong, preserve non-secret evidence and use the provider’s documented recovery or incident process. The companion bridge guide explains why moving between networks introduces additional questions. Security becomes more consistent when each approval is treated as an explicit grant of authority.