A pool prompt can grant more than a swap

A pool prompt can ask you to authorize a token transfer before a swap, and that permission may outlast the trade. The pool is where traders exchange assets; a router is the contract that carries out the swap across one or more pools. Before the trade runs, the token contract may need permission to let the router move your tokens. A malicious page can use a familiar pool screen to ask for permission to a different address or for a much larger amount. The prompt’s label does not tell you what the contract will do.

Routes, pool costs and failed trades each affect what a swap does, but approval is a separate step. The base swap explainer covers those trade mechanics in more detail. Here, the key question is what the wallet is authorizing before the trade.

What does a token approval let a contract do?

A token approval sets an allowance: the maximum amount a named spender can move from your wallet using that token. In a typical ERC-20 flow, your wallet sends an approval transaction to the token contract, naming a spender and an amount. The router can then call the token’s transfer function to collect tokens for a swap, up to that allowance.

Think of it as giving a named service a spending limit. The spender is the address that matters: it may be a router, but it could also be an unrelated contract. An allowance does not prove that the spender is safe, and a large or unlimited allowance can remain available after the trade. If the spender is malicious or later compromised, it may use the remaining allowance to take tokens.

Why can a pool prompt ask for a signature?

A prompt may ask for a signed permit instead of an on-chain approval transaction. A permit is a message that, when valid, lets a contract set or use an allowance without the token holder first sending a separate approval transaction. The signature itself is not the swap: an application or another contract still needs to submit the relevant transaction for the permission to take effect.

Wallets may also show signatures for other typed messages or bundled actions. Read the fields the wallet exposes. A token name and amount are not enough if the spender, chain, deadline or other permissions are unclear. A familiar site can still present a request whose contents do not match the trade you intended.

What should you check before you sign?

Check the permission against the trade you initiated. If the wallet cannot show enough detail to identify the spender and scope, reject the request and inspect it through a trusted interface before trying again.

• Token: Confirm the asset being authorized matches the one you plan to trade.
• Spender: Check the contract address against the application’s verified information for the correct network.
• Amount: Prefer an allowance close to the amount needed. Unlimited access is convenient, but leaves more permission in place.
• Chain and expiry: Make sure the request is for the network you selected and, for a permit, note any deadline.

These checks reduce the permission granted; they do not prove that a pool, router or token is safe. If you already approved a spender and no longer need it, you can submit a transaction to reduce that token’s allowance, often to zero. The practical rule is simple: treat every approval or permit as a distinct instruction, and sign only when its scope matches the trade.