A wallet signature request asks your wallet to use an account's private key to authorize data. Before approving, verify the site independently, classify the request as a transaction, plain message, sign-in, or typed data, and confirm the action, account, chain, counterparty, assets, limits, nonce, deadline, and verifying contract.

Key Takeaways

A signature can authorize meaningful action even when it costs no gas at signing time.

Read the wallet prompt, not only the website button that triggered it.

A familiar domain does not make an unexpected request safe.

Reject opaque, truncated, mismatched, or unlimited authority you cannot explain.

Never sign a second “cancellation” supplied by a suspicious site.

What can a wallet signature request authorize?

The phrase “sign this message” is too broad to decide whether a prompt is safe. A wallet can sign several kinds of data, and each carries a different effect.

Request type	Typical purpose	Fields to inspect	Main risk
On-chain transaction	Send assets or call a contract	chain, recipient, value, contract method, token movement, gas	Immediate execution after broadcast
Plain message	Prove control of an address or accept text	exact readable text, domain context, nonce, purpose	Opaque bytes or reusable authorization
Sign-in message	Authenticate without a password	domain, URI, account, chain, nonce, issued time, expiry	Logging into an impersonating service or replay
Typed structured data	Permit, order, delegation, claim, vote, or protocol action	domain separator, verifying contract, spender, asset, cap, nonce, deadline	Broad off-chain authority later submitted by another party

EIP-712 defines a standard for hashing and signing typed structured data, including domain separation and structured fields that a wallet can display. It explicitly does not provide replay protection by itself.［1］ The application still needs correct nonce, deadline, chain, contract, and verification logic.

Do not reduce the decision to “transaction equals dangerous, message equals harmless.” A transaction may be a small transfer you intended, while a gasless typed signature may grant a third party permission to spend tokens later.

How should you inspect a wallet signature request before approving?

Use a fixed sequence so urgency cannot skip a field.

Verify the origin. Open the service from a bookmark, official documentation, or independently typed address. Check the outer browser address bar, not a logo inside the page.
Confirm the active account and chain. A legitimate request for the wrong account or network can still produce an unintended authorization.
Classify the prompt. Determine whether it is a transaction, plain message, sign-in statement, or typed data.
Name the action in one sentence. For example: “This allows contract X to spend up to Y units of token Z before time T.” If you cannot do that, reject it.
Inspect the counterparty. Check recipient, spender, operator, delegate, or verifying contract through a trusted source.
Bound the scope. Review asset, amount, approval cap, order terms, collection scope, and whether authority is unlimited.
Check freshness. Review nonce, issued time, deadline, expiration, and chain identifier.
Compare intent with effect. A “verify wallet” button should not produce a transfer, unlimited approval, sale order, or delegate action.
Reject and restart independently when uncertain. Closing a prompt is safer than signing to see what happens.

MetaMask describes signature phishing as a path where a user is induced to sign data that an attacker can use, often while the website presents a different story.［2］ Treat the wallet's rendered fields as evidence, but remember that incomplete rendering can hide meaning.

Which fields matter in a typed data signature?

Typed data is designed to be more understandable than a raw byte string, but field names alone do not guarantee safety. Read both the domain and the message.

Domain fields

name and version: identify the signing domain claimed by the application;
chainId: binds the request to a network when implemented correctly;
verifyingContract: identifies the contract expected to validate the signature;
salt or other domain data: may further separate environments or deployments.

Message fields

owner or signer: should match the account you intend to use;
spender, operator, delegate, recipient, or taker: identifies who receives authority;
token, collection, order, or asset: defines what is affected;
value, amount, cap, price, or quantity: bounds the economic scope;
nonce: should prevent reuse when the verifying system consumes it correctly;
deadline or expiry: limits when the authorization can be submitted;
action-specific fields: may encode an order, vote, claim, withdrawal, bridge action, or delegation.

Verify the contract address through official protocol documentation or a trusted explorer reached independently. A recognizable token symbol or domain name in the prompt can be supplied by untrusted code and is not an identity proof.

Why is a gasless signature not automatically harmless?

Signing itself may happen off-chain, so the wallet does not need to broadcast a transaction or charge gas. The signature can still be valuable because another party may later submit it to a contract, use it to authenticate, fill an order, exercise a permit, or prove consent.

The Ethereum Foundation's clear-signing work focuses on making transaction and approval meaning more understandable to users rather than presenting opaque hashes.［3］ Clearer display reduces ambiguity, but it cannot decide whether you trust the site, counterparty, contract, asset scope, or business purpose.

Reject language such as “no gas means no risk,” “this is only verification,” or “sign now and cancel later.” Ask what exact verifier accepts the signature and what state change it can cause.

What mismatches should make you reject a signature request?

Stop when any of these comparisons fail:

the browser domain differs from the service you intended to use;
the wallet account or network is not the one you selected;
the page promises login but the prompt grants token, NFT, order, or delegation authority;
the spender or verifying contract is unknown or differs from official documentation;
the amount is unlimited or materially higher than the task requires;
the deadline is absent, unexpectedly long, already expired, or unreadable;
the prompt contains raw bytes, truncated fields, or a wallet warning you cannot resolve;
a support agent, direct message, or caller is coaching you through the signature;
a fake airdrop page asks for a seed phrase, private key, recovery file, or remote control.

Do not approve because a transaction simulation says “no balance change.” Simulation may not cover later use of a permit, future deposits, external state changes, every internal call, or a different transaction submitted with the signature.

If the page came from an email or message, compare it with the phishing protection checklist. If software initiated the prompt unexpectedly, verify that it is not a fake application.

What if the wallet cannot explain the request clearly?

Reject it and use an independent channel to determine what the application should request. Check official documentation, support reached from the real site, contract records, and another reputable wallet's interpretation where appropriate. Do not paste private keys, seed phrases, or sensitive signed payloads into a public decoder.

Some advanced operations genuinely contain complex data. Complexity changes the review method, not the safety threshold. Ask the application to identify the request type, contract, method, spender, affected assets, limits, and expiry. If those facts cannot be reconciled with the prompt, do not sign.

A hardware wallet can protect the private key from the connected computer, but it cannot make an opaque authorization understandable. If the device shows only an unknown hash or blind-signing warning, you lack the information needed for an informed approval.

What should you do after rejecting a suspicious prompt?

Close the site and wallet prompt. Remove the site's connection to reduce further requests, then verify whether any earlier transaction, approval, or signature succeeded. Disconnecting is housekeeping; it is not revocation.

Preserve the URL, prompt type, visible fields, account, chain, time, and any transaction or signature identifier without exposing recovery material. Report the domain or account through the appropriate wallet, browser, platform, and abuse channels.

If you already signed, identify what authority was granted. A token approval may need safe on-chain revocation; a permit may have a nonce or deadline; a compromised seed phrase requires a new wallet; device compromise requires isolation. The wallet drainer explainer maps these mechanisms to different response paths.

How can you make signing safer over time?

Separate long-term holdings from a wallet used with new applications. Use bounded approvals, short deadlines, and task-specific accounts where the protocol supports them. Periodically review allowances and remove permissions no longer needed.

Bookmark frequently used services, keep wallet software and extensions updated, and remove duplicate or unused wallet extensions. Practice reading prompts during low-stakes actions and cancel any request whose purpose you cannot state precisely.

For teams, document approved contracts and expected signature types rather than sharing screenshots of a “normal” prompt. Contract upgrades, chain deployments, and new permit formats can make an old screenshot misleading.

The broader crypto security incident guide helps place signing risk beside key theft, exchange compromise, protocol bugs, and social engineering.

Summary

Classify a wallet prompt before deciding whether to approve it.
Verify origin, account, chain, action, counterparty, assets, limits, nonce, deadline, and contract.
Treat gasless signatures as potentially actionable authority.
Reject mismatches, opaque data, blind-signing warnings, and coached approvals.
After a suspicious prompt, determine whether any earlier authority remains active.
Build safer habits with separated wallets, bounded scope, independent domain checks, and clear signing.

Frequently Asked Questions

Is every wallet signature a transaction?

No. Wallets can sign transactions, plain messages, sign-in statements, and typed data. Some off-chain signatures can later authorize an on-chain action.

Can signing a message move my tokens?

It can when the signed message is a permit, order, delegation, or other authorization accepted by a contract or service. Read the exact type and fields rather than relying on the word “message.”

Does a signature cost gas?

Creating an off-chain signature usually does not. A party that later submits it on-chain may pay gas, while the authority can still affect your assets.

What is the verifying contract?

It is the contract expected to interpret or validate typed data. Confirm its address through an independent official source and check that it matches the intended network.

Is a short deadline enough to make a request safe?

No. Expiry reduces the time window but does not fix a malicious spender, excessive amount, wrong contract, or unintended action.

Should I enable blind signing to continue?

Only when you independently understand the exact request and trust the full workflow. A site pressuring you to bypass unreadable details is a reason to stop.

Can I cancel a signature by signing another message?

Do not trust a cancellation supplied by a suspicious site. Some protocols support nonce invalidation or revocation, but the correct method is specific to the original authorization.

What if I signed but no transaction appears?

The signature may be unused, off-chain, expired, or waiting for submission. Preserve its fields and seek protocol-specific guidance; no visible transaction does not prove that no authority exists.

Disclaimer: This article provides general security information, not financial, investment, trading, tax, legal, or professional incident-response advice. Signature formats, wallet displays, contract behavior, and remedies vary by protocol and jurisdiction.

Sources:

EIP-712 — Typed structured data hashing and signing — https://eips.ethereum.org/EIPS/eip-712
MetaMask — Signature phishing — https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/signature-phishing/
Ethereum Foundation — Clear Signing — https://blog.ethereum.org/2026/05/12/clear-signing-announcement

Sources checked 8 September 2026.

Related reading:

Wallet Signature Request: What Are You Approving?