A website asks you to connect a wallet and sign a message. There is no gas fee, so the interaction feels like logging in. Sometimes that is exactly what it does. Other signatures can authorize a contract or another party to act later.
The wallet’s signing operation proves control of a key. What the signed message permits depends on its contents and on the system that accepts it. A button labeled “Sign” does not describe the full consequence.
This is why an offchain request can matter financially. Someone else may submit a valid signed authorization later, paying the transaction fee themselves. The absence of an immediate blockchain transaction does not make the authorization harmless.
Connection and authorization are different steps
Connecting a wallet commonly reveals an address to a site and establishes a session through which the site can request actions. It does not, by itself, mean that every subsequent request is safe or expected.
The next prompt might ask for a login message, a transaction, a token allowance or a marketplace order. These serve different purposes. A login should establish identity for a particular service. An allowance can let a specified spender move tokens under specified conditions. An order can authorize a trade when its conditions are met.
Treat the website’s explanation and the wallet’s displayed request as two things to compare. If the website says “verify your account” while the request describes spending tokens or selling an asset, stop before signing.
A signature can be used later
MetaMask’s guide to signature phishing describes attacks that collect an offchain signature and use it later to take assets. Its examples include permissions and marketplace-related requests disguised as something less consequential.
Offchain signing is also used by legitimate applications. It can reduce the number of transactions a user needs to submit directly or allow an order to be matched later. The risk comes from misunderstanding the authority being granted, not from offchain signing being inherently fraudulent.
Timing matters. A signature may have an expiry or may remain usable until another condition changes. A nonce or other mechanism can prevent reuse, but those protections depend on the protocol and the exact message. Do not assume that closing a browser tab invalidates a signed authorization.
Read the permission in concrete terms
Before confirming, identify the site requesting the signature and the action the request describes. Where the wallet exposes them, inspect the network, contract or spender, asset, amount and expiry. Check whether the scope matches the operation you intended.
An unlimited allowance has a different reach from an allowance limited to the amount required for one task. A marketplace order should identify the asset and commercial terms you expect. If the display is opaque, unreadable or missing the details needed to understand it, that is a reason to pause rather than to guess.
Simulations and wallet warnings can help explain likely effects. They remain tools with coverage limits. A request that produces no warning is not a guarantee of safety, especially if the transaction or signature relies on conditions the wallet cannot fully evaluate.
Hardware wallets can keep private keys isolated, but they still sign the operation the user approves. Key protection and comprehension of the request solve different problems.
Disconnecting does not revoke every permission
Removing a site’s connection can stop that session from making new requests through the wallet interface. It does not necessarily remove allowances already recorded on a blockchain or invalidate signatures the site already received.
Revoking an onchain allowance is a separate operation and usually requires a transaction on the relevant network. Other authorizations may require a protocol-specific cancellation or nonce change. There is no universal “disconnect and undo everything” button.
If you suspect you signed something harmful, use the wallet or protocol’s official guidance reached through a verified address. Avoid unsolicited recovery links or anyone asking for a seed phrase. The appropriate response depends on whether the problem is a permission, a signed order or an exposed key; treating those as identical can leave the real issue unresolved.
Separate routine interactions from long-term holdings
Keeping funds needed for a particular application separate from assets you do not intend to use can limit the consequences of an operational mistake. It does not make every contract safe, and it adds account-management work, but it makes the scope of routine permissions easier to understand.
Keep a record of applications that have ongoing allowances. Revisit permissions when you stop using a service. For yield products, first understand where the yield comes from; a convincing interface is not evidence of a sound financial arrangement.
The general rule is to connect the signature to a specific action. If you cannot explain who receives authority and what they can do with it, the request is not ready to approve.
