Awarded once after a correct answer.
Inspect the request before trusting the appearance
Useful first : Hot, warm and cold wallets
Find your bearings · Step 6 / 6
Attackers can imitate a support agent, a familiar website or a message from a friend.
The essentials
Attackers can imitate a support agent, a familiar website or a message from a friend. Their objective may be a recovery phrase, a signature, a token allowance or a direct transfer. Identify the requested action before judging the visual appearance of the message.
How it works
A recovery phrase can give control over derived keys. A signature can authorise an action even if no immediate payment appears. An allowance can let a contract transfer tokens later. Read the wallet’s operation details and reject requests you cannot explain. A small initial payment or an apparently successful test does not establish that subsequent requests are safe.
What to watch
Urgency and threats are reasons to pause. Reach a service through a previously verified route rather than through the message. If exposure is suspected, preserve evidence and assess what was disclosed. Revoking an allowance does not repair a disclosed recovery phrase, and disconnecting a website does not automatically revoke on-chain permissions.
Understand the details
Separate three checks: where did the request originate, what action would approval enable, and can that action be independently justified? A correct-looking domain shown inside a message is not proof of the actual destination. A padlock protects a connection, not the honesty of its operator. For institutional workflows, unexpected instructions should return through the established independent approval channel.
Boundaries and common mistakes
No checklist detects every attack. Do not paste real phrases, keys or client details into exercises, forms or chats. The examples here require no wallet.
The mechanism at a glance
- 01Pause
- 02Identify the permission
- 03Verify independently
- 04Reject and preserve evidence
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
Separate three checks: where did the request originate, what action would approval enable, and can that action be independently justified? A correct-looking domain shown inside a message is not proof of the actual destination. A padlock protects a connection, not the honesty of its operator. For institutional workflows, unexpected instructions should return through the established independent approval channel.
Put the mechanism into context
A fictional support message says: “Your wallet expires in ten minutes. Enter your recovery words to preserve access.” The page has the expected logo.
Apply it in the workshop →What this mechanism does not guarantee
No checklist detects every attack. Do not paste real phrases, keys or client details into exercises, forms or chats. The examples here require no wallet.
The distinction that changes the analysis
A familiar logo and a “sign in” label can accompany a request to approve token spending. Read the requested action rather than inferring it from the page design. An independent route to the service is more informative than a copied visual identity.
Explain it yourself
Revisit the case above. Name what is established, what remains to be checked and the evidence needed to conclude. A strong answer addresses both sides of the diagram.
Apply the lesson to a case
A fictional support message says: “Your wallet expires in ten minutes. Enter your recovery words to preserve access.” The page has the expected logo.
The recovery-word request and forced urgency are warning signs. Do not interact with that form. Verify the service independently; partial disclosure is not a safe test.
Prepare a correction note
Describe the passage and the proposed correction. This creates a local note for you to share; it sends nothing. Do not include personal or confidential information.