Wallet Connection, Message Signing and Transaction Signing: What Changes?
A practical guide to telling a wallet connection, a signed message and an on-chain transaction apart before approving a DeFi prompt.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
Connecting a wallet, signing a message and sending a transaction look similar in a browser because all three end with a prompt in the same window, but they are three different actions with three different consequences. Connecting proves control of an address. Signing a message proves the same thing without spending anything. Sending a transaction changes state on a network and can move assets. A prompt that asks for one of these is not a prompt for the others, and a request to “connect” that quietly includes a transaction signature is the exact pattern behind a large share of unexpected asset losses.
Connecting a wallet
A connection request asks your wallet to share your public address — and normally nothing more — with a website. The signature involved is used to prove you hold the key for that address, and it is not itself an on-chain transaction. Nothing moves, nothing is spent, and no gas is paid by the connection itself.
What a connection does grant is standing read access to your address and whatever public information the site decides to track from it. This is why a connection can feel harmless while still being worth doing deliberately: after connecting, the site knows which address you hold and when you hold it. That knowledge is what makes a later malicious prompt more convincing.
Connecting to a site you do not trust creates no direct financial exposure. It does create exposure in the sense that the site now knows your address and can target you. Revoking a connection from the wallet’s own interface is inexpensive and immediate for read access, though it does not undo anything the site already recorded.
Signing a message
A message signature produces a cryptographic signature over text you were given. It does not create a transaction, does not cost gas, and cannot move funds by itself. This is why “sign-in with wallet” flows ask for it: the signature lets a site verify you control the address without asking for a password.
The risk is not spending, it is what the text says. A message signature has no guarantee that the content is a login prompt. Signatures over arbitrary text are also used to authorise actions in some protocols — a listing, an order, a signature threshold. So the correct question when a message signature appears is not “is this free” but “what does this text permit”.
Two habits make this decidable. First, read the full text, including the beginning and the end, because a permission is often stated at the end. Second, if the prompt asked for a connection and the next prompt is a message, expect it and check the wording instead of approving reflexively. A wallet that displays the decoded meaning of a message makes this much easier; if the text renders as raw encoded data, treat that as a reason to decline rather than as a technicality.
Signing and sending a transaction
A transaction is the only one of the three that changes network state. It can transfer tokens, call a contract function, or approve an allowance. Transactions cost gas whether they succeed or revert.
The critical property here is that most DeFi contract calls are irreversible. There is no chargeback, no undo button and no customer support line that reverses an incorrect transfer or a swap executed at a poor price. This is why a transaction signature deserves more scrutiny than the two prompts before it, not less.
An approval deserves its own mention, because it is the most common source of lasting exposure. When you approve a token allowance, you grant a contract permission to move that token on your behalf, up to the approved amount, and the permission persists until you revoke it or spend the full amount. Approving an unlimited allowance for a contract you have not reviewed means that if that contract is ever compromised, the entire balance of that token is at risk. Approving the exact amount needed limits the damage to the amount you intended to move.
Telling the three apart at a glance
| Signal | Connection | Message signature | Transaction |
|---|---|---|---|
| Moves funds | No | No | Yes or approves a permission |
| Costs gas | No | No | Yes, even if it reverts |
| Changes network state | No | No | Yes |
| Reversible | Yes, from the wallet | Nothing to reverse | No |
| What to read | Which site receives your address | The full text of the message | What the contract call does and what allowance it grants |
A decision sequence that holds up
- Establish which of the three prompts is on screen before reading anything else.
- If it is a connection, confirm the domain is the official one, reached independently of the link that brought you there.
- If it is a message signature, read the entire text. Decline anything that arrives as raw encoded data when you expected plain login wording.
- If it is a transaction, identify which contract it calls and what it does to your balance or your allowances.
- For any approval, prefer the exact amount over an unlimited allowance, and revoke approvals you no longer need.
- Never sign anything in response to urgency, a countdown timer, or a claim that funds are at risk unless you have independently confirmed it.
The prompts share a window and a brand, which is exactly why the distinction matters. Once you can name which of the three you are looking at, the decision stops being about whether the interface looks trustworthy and becomes about whether the specific request is one you intended to make.