Signing a Message vs Signing a Transaction

When you sign a message, you prove control of an address without changing anything on-chain. There is no fee, no nonce, no state transition. What you produce is a cryptographic statement that a specific string of characters was approved by the holder of a specific key.

The two requests — sign message, send transaction — can look almost identical on a phone screen, and that resemblance is the basis of several families of scam. A sign message prompt costs nothing and often changes nothing. A transaction prompt authorises a change to the ledger, costs a fee, and cannot be recalled once included in a block.

• A message signature costs nothing but can still be dangerous. If the “message” is structured data that grants an allowance, the signature is spending authority in disguise.
• A transaction signature is irreversible. Once broadcast, the only remedy is another transaction, and only if you still control the funds.
• Read the payload, not the button. The wallet label says “sign”; only the decoded content tells you what is being approved.
• Blind signing is the failure mode. If you cannot decode what you are about to authorise, decline and check on a device or tool that can.

What a message signature actually does

It produces a signature over an arbitrary byte string. No gas is consumed, no balance moves, and nothing is recorded on-chain unless someone chooses to submit the signature to a contract.

Off-chain by default, but not inert

The classic use is authentication: a service gives you a random nonce, you sign it, and the service verifies that the signature recovers to your address. That proves you hold the key at that moment, without a password and without a transaction. Because the nonce is unique, the signature is useless to anyone who intercepts it.

The trouble starts when the signed string is not a nonce. Signatures are just mathematics; a contract is free to interpret one however its code defines. If the contract treats a signature as permission to move tokens, then a harmless-looking “login” is a transfer waiting to be executed by anyone who reads it.

Where a message becomes spending power

Several widely used standards exist specifically so that a signature can authorise a token movement without a separate approval transaction. Permit-style token standards let the holder sign an approval off-chain, and a relayer submits it later. Typed-data signing standards let a marketplace or router express an order, including price and expiry, as structured fields you approve in one click.

None of that is a flaw. It removes a transaction and a fee from a common flow. It also means the phrase “this is only a signature, it cannot move funds” is false in general, and anyone who tells you otherwise is either misinformed or lying.

What a transaction signature actually does

It authorises a specific state change: sending value, calling a contract, deploying code, or approving an allowance. The wallet assembles the fields, you approve, and the signed object is broadcast to the network.

The fields that matter

Recipient, amount, calldata, gas limit, fee settings and nonce. Calldata is where most surprises live: a transfer to a contract address can execute arbitrary logic that the wallet summarises as “interact with contract”. If the summary is vague, the calldata is the truth.

A signed transaction is a bearer instrument

Signing offline does not broadcast, but it does create a complete, valid transaction. Anyone who obtains those bytes can broadcast them, and the network has no way to know who pressed the button. This is why a hardware wallet prompt that says “sign transaction” while showing no fee is not a safe signal on its own; the fee appears when someone submits it.

The question is never “is this a message or a transaction”. It is “what does this signature let someone do, and to whom”.

How to sign a message without approving a transfer

Decode first, decide second. The procedure below works for both prompt types and takes under a minute once you have done it a few times.

1. Check the origin. Is this the site you intended to visit, reached by typing or bookmarking rather than a link in a message?
2. Identify the request type. A plain text message, structured typed data, an approval, or a full transaction are four different risk profiles.
3. For structured data, read every field: spender, amount, deadline, nonce, chain. An unlimited amount or a far-future deadline deserves a second look.
4. For a transaction, read the calldata, not the summary. If the wallet cannot decode it, treat it as unknown rather than harmless.
5. Check the chain. A signature for one network may be replayable on another if the domain does not bind the chain identifier.
6. Compare the requested action with what you set out to do. If you came to claim a reward and the prompt asks for an approval, stop.
7. When in doubt, reject. A declined prompt costs nothing; a wrong signature costs whatever the contract decides it is worth.

Two failure modes worth naming

Most losses in this area come from one of two patterns, and both are avoidable with the same habit.

Signing a hash you cannot read

Some legacy signing methods sign a raw hash with no structure and no readable text. A wallet that displays a hex blob in a sign message prompt is asking you to authorise something you cannot evaluate, and a hash can be a transaction digest just as easily as a login string. If the interface cannot render the content in words, the honest answer is no.

Approving an order instead of a login

Marketplace and router flows sign orders that include price, expiry and a counterparty. A signed order at a price of zero, or with no expiry, is an open invitation for anyone to fill it at your expense. The prompt may still say “sign message”. Read the fields and check that the numbers match the trade you believe you are making.