What you are agreeing to when a wallet connects to a site

Every question about which wallet is best for DeFi, for NFTs, for staking or for claiming an airdrop is downstream of one mechanism, and it is a mechanism most people using those things have never had explained. The wallet is not the risk. What you authorise through it is.

Connecting is not approving

These are two different acts and the interfaces blur them.

Connecting tells a site your address. It is a read: the site can now see what that address holds, and it can propose transactions to you. On its own it moves nothing and grants nothing, which is why a connection prompt is not worth much caution.

Approving is a transaction you sign that gives a smart contract permission to move a token out of your wallet on your behalf, later, without asking again. That permission persists after you close the tab, after you forget the site existed, and after the site changes hands.

Almost everything that goes wrong for people who hold their own keys happens at the second step while they are thinking about the first.

Why approvals exist at all

Not a design flaw. A token like a dollar stablecoin is its own contract with its own ledger, and it has no idea that some exchange contract exists. So the sequence is: you tell the token contract that the exchange contract may spend up to some amount of your balance, and then you tell the exchange contract to go ahead. Two transactions, because two contracts, and the first is the approval.

The consequential detail is the amount. Interfaces commonly request an unlimited allowance — the largest number the type can hold — so that you do not have to approve again on your next trade. It is a real convenience with a real cost: an unlimited approval means that contract can move your entire balance of that token, at any point in the future, for as long as the approval stands.

If the contract is sound, nothing happens. If it has a flaw found next year, or an upgradeable component whose keys are later compromised, the approval you gave today is the mechanism.

Signatures that are not transactions

The subtler category, and the one that has taken the largest individual losses.

Some requests are not transactions at all but signed messages. Signing is free, costs no gas, and produces no on-chain record at the time — which makes it feel harmless, and it is how the interface presents it. But a signature over structured data can be the authorisation: a gasless approval, an order transferring an asset for a price, a permission the recipient submits later at a moment of their choosing.

The practical rule is that a request costing no fee is not therefore safe, and “sign to verify you own this wallet” is a sentence worth reading twice. A legitimate login signature says so in plain readable text. An authorisation dressed as one contains a structure with a spender, a token and an amount in it — which is exactly why whether your wallet decodes what it is showing you is the most consequential difference between two of them.

The patterns that use this

• The airdrop claim. A “claim” page whose transaction is an approval, or whose signature is a transfer order. Urgency is the tell: a genuine distribution rarely expires this afternoon.
• The support impersonator. Someone helpful in a reply or a direct message, with a link that fixes your problem by asking you to sign something.
• The dormant contract. A site you used legitimately two years ago, whose approval is still live, whose ownership has since moved.

None of these steal a key. All of them collect an authorisation, which is why a hardware wallet defeats the first class of attack completely and does nothing about this one beyond showing you clearly what you are about to agree to.

What to actually do

Four habits, in order of how much they return:

1. Approve the amount, not the maximum. Most interfaces allow editing the allowance. Taking the default is the single most common avoidable exposure.
2. Review approvals periodically. Allowances are public — any block explorer lists what a given address has granted, and revoking is a transaction setting the allowance to zero. It costs a fee; it also closes every dormant permission at once.
3. Separate the wallet that connects from the wallet that holds. A wallet used for signing into sites should hold what you can afford to lose. This is the same split that makes a hot wallet survivable, applied to authorisation rather than to storage.
4. Read the spender, not the site. The domain in the address bar is not what you are approving. The contract address in the request is.

Which wallet, then

For contract interaction the useful properties are narrow and none of them is brand: does it decode the transaction into readable terms before you confirm, does it show the amount being approved rather than hiding it behind “unlimited”, does it warn when a request is a signature that carries authorisation, and does it let you edit the allowance without leaving for another tool.

Those are checkable in five minutes with a small balance, which is a better test than any recommendation — including this one.

Shared wallets are a different problem

A treasury held by several people is not a wallet question at all but a governance one: how many signatures are required to move funds, who holds them, and — the part that gets skipped — who is able to change that threshold. A multisig is a rule about who must agree, not a security property, and the rule is usually editable by the people it governs.