Clicking a connect wallet button does not hand over your funds. It hands over your public address and opens a session that a site can use to ask you for more, one prompt at a time. The button is a request for identification, not a transfer.
That distinction is the whole security model. A connect wallet prompt grants read access to your addresses and the ability to request signatures; it does not grant the ability to move anything. Every loss attributed to a connection actually happened at a later prompt, and the connection only made that prompt easy to deliver.
- A connection shares addresses and opens a session; it moves nothing on its own.
- Token approvals and permit signatures are separate grants, and some of them have no spending limit.
- Disconnecting ends a session but does not revoke an approval already recorded on-chain.
- Audit approvals on a schedule, and use a separate wallet for sites you have not used before.
What a connect wallet button actually does
It establishes a channel. Your wallet software generates a session and shares the addresses you choose, usually one per chain. The site reads balances and history from public data, which it could have read without asking.
Read access versus write access
Reading is passive. The site learns which addresses are yours, which is a privacy event rather than a fund event: it can now link those addresses together and to anything else you do with them.
Writing is active and always requires a separate prompt. Moving a token, approving a contract, signing an order or proving ownership all need a signature that your wallet displays and you confirm. No connection can pre-approve a future transfer.
Why the prompt looks so harmless
Because the risk is deferred. The dangerous part of a session is what it lets the site ask for later, when you are mid-task and clicking quickly. A prompt that appears ninety seconds into a workflow gets less attention than one that appears on arrival.
Where the real permission lives
Permission lives in the signature, not the connection. Five prompt types cover almost everything you will see, and they differ enormously in what they can do.
Message signatures
A plain sign-in message proves you control the address. It costs no gas and moves nothing. The same format can also authorise an order or agree to terms, so read the text rather than assuming a free signature is inert.
Token approvals
An approval authorises a contract to spend a token on your behalf, up to an amount you set. Many interfaces default to an unlimited amount, which means the approval persists for every unit of that token you hold now and every unit you receive later. That is the single largest source of preventable loss in this category.
Permit-style signatures
Some token standards let an approval be granted by signature instead of a transaction. There is no gas cost and no on-chain record at the moment you sign, which makes the prompt feel cheaper and safer than it is. The grant is just as real once it is submitted.
| Prompt | What you authorise | Worst case | Can you undo it |
|---|---|---|---|
| Connect | Address sharing, session | Privacy loss, targeted phishing | Yes, disconnect |
| Sign-in message | Proof of address control | Account impersonation on that site | No, but low impact |
| Token approval | Spending up to an amount | Loss up to the approved amount | Yes, by revoking |
| Approval for all | Every token in a collection | Loss of the whole collection | Yes, by revoking |
| Permit signature | Spending without a transaction | Loss up to the signed amount | Only before it is submitted |
| Transaction | One specific action | Whatever that action does | No |
A connection is a doorbell. An approval is a key left under the mat, and the site decides when to use it.
What an unlimited approval costs in practice
Suppose a swap interface asks you to approve a stablecoin and you click the default. You hold 4,000 of it that day. Six months later the same wallet holds 10,000 because you kept depositing into it, and the approval still applies to the full balance.
The intended exposure was the 300 you were swapping. The actual exposure became 10,000, and it stays at whatever your balance is until you revoke. Nothing in the interface tells you this at the moment of signing, because at that moment the number was small.
Setting an exact amount caps the exposure at the number you typed. The cost is that you approve again next time, which is a transaction fee and a few seconds. On a network where a simple approval costs a fraction of a cent, the trade is obvious; on an expensive network, the calculation is closer, but it still favours a cap on anything you hold a large balance of.
Revoking has a cost too. Each revocation is a transaction, so cleaning up a wallet with a dozen stale approvals on an expensive network can cost real money. That argues for not creating them in the first place, and for cleaning up in batches when fees are low.
How to revoke what a connect wallet granted
- List the addresses you actually use, including any you have abandoned but still hold funds in.
- Use a block explorer or a reputable approval-checking tool to read current allowances per address.
- Sort by token value rather than by date, so the largest exposures get attention first.
- Revoke approvals for contracts you no longer use, starting with unlimited ones.
- Confirm each revocation on-chain before moving on; a pending revocation is not a revocation.
- Repeat the audit quarterly, and immediately after any site you do not fully trust asks for an approval.
- Keep a separate wallet for unfamiliar sites so a bad approval cannot reach your main balance.
Habits that reduce the exposure
Separate wallets do most of the work. A wallet used only for experimenting can hold a small balance and grant whatever it likes, because the loss is capped by what is in it. Your main holdings sit behind a wallet you never connect to anything unfamiliar.
Read the amount field on every approval. Unlimited is a default, not a requirement, and the interface will accept a smaller number. If a site insists on unlimited for a routine swap, that is information about the site.
Treat a free signature as seriously as a paid transaction. Cost is not a proxy for risk; the cheapest prompt in the flow is often the one that grants the most.
0 comments
No comments yet — ask a question and we will answer it here.