whytheblockchain

EXERCISE · WALLET SECURITY

MetaMask: disconnect, revoke, what should you check?

A “Sign” prompt can log you into a service or authorise an asset movement. Practise telling them apart without connecting a wallet. Exercise screens are educational mock-ups, not MetaMask screenshots.

WhyTheBlockchain·Documentation checked: 17 September 2026
Beginner

Useful first: Crypto wallets: keys, custody and recovery

THE SHORT ANSWER

A wallet window can request a sign-in, permission to use your tokens or an operation. These are different actions. Start with documented examples, then use four made-up situations to compare your intention with what a request actually permits.

01 · UNDERSTAND WITH AN EXAMPLE

Understand the requested permission before deciding whether it matches your intention.

  • Distinguish connection, approval and swap.
  • Identify the asset and spending limit.
  • Understand mistakes through four explained situations.

The words you need, in plain language

Wallet
The app used to access your account and confirm actions. MetaMask is one example. Always read what a wallet window requests.
Contract and authorised program
A contract is a program on the blockchain. An approval must identify the program that could use the tokens; its displayed name alone does not verify it.
Approval and spending limit
Permission for a program to use a token up to a limit. Approving 25 USDC is not yet swapping 25 USDC.
Signature
A confirmation produced with your account. What it permits depends on the message: signing in, approving spending or something else. “No fee” does not mean “no consequence”.

Follow the reasoning

  1. State what you intended to do

    Example: “swap 25 USDC”. Use that sentence to compare your intention with the displayed request.

  2. Read what the program requests

    Which site did you open? Which network? Which token? Which program would receive permission? What limit? A 250-unit limit is ten times 25.

  3. Decide without guessing

    Missing information: verify it. A mismatch: stop that request. Everything matches in the exercise: recognise the match without concluding that the program is safe.

Remember: Disconnecting a site does not remove an existing standard token-spending approval. Revocation concerns that specific permission; it does not recover funds already transferred.

Intermediate: a Permit signature can matter

ERC-2612 lets a signed message prepare an approval that another party can submit later. Its deadline limits use of the signature; it does not necessarily mean that the resulting allowance expires on that date. Permit2 and advanced permissions have different rules: do not automatically apply one mechanism’s rules to another.

ERC-2612 — Signed approvals ↗Uniswap — Approval transactions ↗

02 · PRACTISE, THEN UNDERSTAND THE ANSWER

4 situations to work through

Each answer has an explanation. Use a hint if you need one; there is no timer.

Situations answered0 / 4

MADE-UP SITUATION · NO REAL ACTION

Receive a gift… or approve spending?

In this made-up situation, a message directs you to cadeau.example to receive a bonus. You did not request anything. Yet the window asks for permission over your USDC.

Simulated request — no wallet
What you expected to do
Receive a gift
What is requested
Approve USDC spending
Spending limit
Unlimited
Immediate signing fee
€0
I need a hint

Receiving something does not normally require unlimited spending permission over your own tokens. Look at the action, not just the fee.

Which decision matches the information shown?
Read all explanations at my own pace

Receive a gift… or approve spending?

In this made-up situation, a message directs you to cadeau.example to receive a bonus. You did not request anything. Yet the window asks for permission over your USDC.

Reasoning: The promised action and requested permission do not match. Some mechanisms can later use a signed message to grant spending rights. Stop here. The domain and bonus are made up; USDC and the approval mechanism are real.

Zero fees do not prove that a signature has no effect.

Sign in to a forum

You intentionally opened forum.example, a site made up for this exercise. The message uses the real Sign-In with Ethereum format to sign in. You have not yet compared the account and network with your intention.

Reasoning: Sign-In with Ethereum is a documented format for authenticating with an Ethereum account. Domain, account, network and time information need to match the context. This exercise has not yet supplied all those checks, and guessing cannot replace them.

An unchecked detail is a missing detail.

You intended 25 USDC; the program asks for 250

You are preparing a fictional swap of 25 USDC, meaning 25 units of the token. You decided to limit approval to that quantity. Yet the next summary displays a different limit.

Reasoning: A 250 USDC limit authorises ten times the intended 25 USDC. This does not assert that theft has already occurred; it shows that the request exceeds your intention. Return to the permission setting and check the remaining context.

Read the field’s unit and scope, not just its number.

The approval matches: is the swap complete?

For this final fictional situation, the scenario states that the intended site, network and program have been checked. You want to approve exactly 25 USDC. The displayed request is an approval only.

Reasoning: The request matches the stated intention without proving contract safety. Uniswap documents separate approval and swap steps, with details varying by flow. Here you are learning to recognise the stage, not to sign a real operation.

An approval is neither an executed swap nor a safety guarantee.

OPTIONAL · GO FURTHER · INTERMEDIATE

Three actions with different effects

Disconnecting removes the site’s active wallet connection. Locking requires you to unlock the wallet again. Revoking changes a contract approval on the relevant network. The first two actions do not replace the third.

Fictional example: you authorised a contract to spend 500 USDC (token units, not euros). Closing the tab does not change the allowance to zero. A confirmed revocation can remove that approval; it does not recover assets already transferred.

Read the request, not just its appearance

A polished interface, a familiar logo and a zero fee do not establish what a signature authorises. A Permit request can grant spending permission through a signed message; it is not just a login. The exercise simplifies fields to make them easier to recognise.

  • Domain: does it exactly match the service you intentionally opened?
  • Action: login, spending permission or transfer? Does it match your intent?
  • Scope: which tokens, authorised program and spending limit? If a deadline appears, what exactly does it limit: the signature or the permission?
  • Context: which account and network? An alert or unreadable data is a reason to stop.

Review an approval after use

From official documentation or a known address, inspect the account’s approvals on the correct network. Identify the token and spender contract. Revoking is generally an on-chain transaction with a fee: check its result in the explorer after confirmation.

An off-chain signed message may not appear as a conventional approval. Whether it can be invalidated depends on the contract and signature type. An empty approval list does not prove that all risks are gone. If a recovery phrase was exposed, revoking permissions does not make the keys secret again.

The questions that remain

Is a signature without gas risk-free?

No. The absence of an immediate fee says nothing about the rights granted by a message. Read what it authorises, not just what it costs.

Does a correct answer validate my wallet?

No. The exercise uses fictional situations and analyses no real wallet, site or contract. It teaches reading habits, not a security certification.

Sources and further reading

Page updated on
Documentation checked on · WhyTheBlockchain · Editorial approach

Continue exploring