Applications frequently ask a wallet to sign a message rather than send a transaction. The request proves control of an address without touching the chain, and the distinction matters for both safety and function.
A signature is a proof about data
Signing produces a value that anyone can verify against a message and a public key, confirming the holder of the corresponding private key approved that exact content.
The same operation underlies transactions, where the signed data happens to describe a transfer that the network then executes.
When the signed data is arbitrary text instead, nothing is broadcast, no fee is paid and no state changes anywhere.
Authentication is the common use
Logging into a decentralized application usually means signing a message containing a site identifier, a random value and a timestamp.
The server verifies the signature and concludes that whoever is connecting controls the address, replacing a password without storing any secret.
The random value prevents replay, ensuring a captured signature cannot be reused to authenticate a later session.
Structured signing exists to be readable
Signing an opaque string means approving something the user cannot interpret, which is the condition attackers rely on.
Structured data standards define a typed format so wallets can display the fields and their values in a form a person can actually read.
They also bind the signature to a specific contract and chain, so a signature intended for one application cannot be presented to another.
Some signatures do authorize movement
Permit-style approvals let a token holder sign a message granting a contract permission to move tokens, with the contract submitting it later.
Nothing is spent when signing, but the signature is a bearer authorization: whoever holds it can present it within its validity window.
This is why signature requests deserve the same attention as transactions, since the harmless appearance is exactly what makes the technique effective.
What to check before approving
The domain requesting the signature should match the site being used, since structured signing binds the request to a named domain for this purpose.
Requests granting spending permission name a spender address, an amount and a deadline, and an unlimited amount with a distant deadline is the pattern that warrants caution.
Hardware wallets that display structured fields on their own screen provide the strongest check, because the display cannot be altered by a compromised browser presenting one thing while transmitting another.
Support for that display varies by device and by message type, and a device that cannot decode a request falls back to showing raw data, which returns the user to approving something unreadable.