Signing a message: what "sign in with your wallet" actually proves

Sooner or later a site asks you to "sign a message" instead of sending a transaction. No gas, no confirmation on-chain, nothing visible in your history. It feels harmless — and very often it is. But a signature is your key vouching for something, and the question worth asking every time is simple: vouching for what?

What a signature proves

A digital signature proves one thing: whoever controls a particular private key agreed to a particular piece of data. Anyone can check it against your public address without learning anything about your key.

That makes signatures useful far beyond sending coins. A site can confirm you own an address without you paying a fee. A developer can prove they published a release. A node operator can prove a server belongs to them. None of it touches the chain, and all of it rests on the same guarantee: the key signed exactly these bytes.

The catch is in "exactly these bytes". A signature doesn't carry intent. It doesn't know whether you thought you were logging in or approving a payment. It only binds your key to the data — and whoever holds that signature can use it for whatever the data allows.

"Sign in with your wallet"

The most common message you'll see is a login. Instead of a password, the site sends you a piece of text, you sign it, and the site checks the signature against your address. If it matches, you're in.

A well-built login message reads like a small contract, and the standard format for Ethereum (known as Sign-In with Ethereum, EIP-4361) spells it out:

• The domain asking — which should match the site in your address bar.
• The address being signed in.
• A statement in plain words, such as "Sign in to Example".
• A nonce — a one-time random value so the signature can't be replayed later.
• Issued and expiry times, so an old signature goes stale.

When all of that is present and matches, a login signature is low-risk: it grants a session on one site and nothing more. When the domain in the message doesn't match the site you're on, stop. That mismatch is exactly what a phishing page trying to reuse your signature elsewhere would produce.

Signatures that move money

Here's where "no gas, so it's harmless" breaks down. Several kinds of off-chain signature can later be submitted by someone else to move your funds:

• Token permits. Many tokens let you grant spending permission with a signature instead of an on-chain approval. The spender then submits it and can transfer up to the permitted amount. From your side, it looked like signing a message. It's an approval in everything but name.
• Marketplace orders. Signed listings and offers can be filled by anyone who holds them, at the terms you signed — including terms a malicious site filled in for you.
• Raw hash signing. Some legacy methods sign an arbitrary 32-byte hash with no readable content and no prefix marking it as "just a message". A hash can be the fingerprint of a real transaction. Signing one you can't read is blind signing in its purest form.

The rule that follows is short: if you can't read what you're signing, you can't know what it authorises.

How to read a signing request

Before approving any message, go through the same four questions:

1. Who is asking? Check the requesting site against the one you meant to use.
2. Which address and network? A request for a different address or chain than you expect is a warning sign.
3. Can you read it? Plain text you understand is one thing. Hex, hashes or long unexplained JSON is another.
4. What would it let someone do? Login, prove ownership — fine. Spend, list, transfer, approve — treat it like a transaction, because that's what it is.

What SSP shows you

When a dApp connected over WalletConnect asks SSP to sign a message, the request shows the requesting site, the address and the network, and the message itself. Hex-encoded messages are decoded into readable text first, with the raw bytes behind an expander if you want to check them.

Ordinary text messages get the standard Ethereum "signed message" prefix, which marks them as messages rather than transactions so they can't be replayed as one. Structured typed-data requests show their full raw content before you approve.

Like everything in SSP, a message signature from your wallet needs both keys: you approve in SSP Wallet, then confirm on SSP Key. That second step is a genuine second look on a separate device, and it's worth using as one.

What SSP can't do is tell you what a site intends to do with a signature. It shows you the data faithfully — reading it is still your job.

The honest summary

Signing a message is how you prove things with your key without spending anything, and most of the time it's exactly as harmless as it looks. The exceptions are signatures that authorise spending, listing or transferring — and they often look identical until you read them.

So read them. Check the domain, the address, the chain and the content. Sign what you understand, and treat anything you can't read as a no.