A decentralized exchange may ask for permission to spend a token before it can perform your swap. That request deserves its own review. An attractive quote does not explain which contract will receive permission, how much it can spend, or whether the permission will remain after the trade.

This guide focuses on common Ethereum and EVM token workflows. Other networks and token standards can use different permission systems. The useful habit is consistent: identify the account, asset, spender, amount, and duration before authorizing anything. Treat each wallet request as a separate decision, even when the application presents the entire journey as one simple swap.

What a token approval actually permits

For a conventional ERC-20 token, an allowance records how much a specified spender may transfer from a particular owner's balance. The approval is associated with that token contract on that network. It does not automatically give the spender access to every asset in the wallet. The spender may nevertheless be able to move the approved token without another approval prompt, subject to its contract logic and the remaining allowance.

An approval ordinarily grants authority; the later swap uses that authority to transfer tokens. The approval itself does not establish the exchange rate or guarantee that a swap will follow. A malicious spender can misuse authority it has received. A legitimate contract can also have a vulnerability that makes an existing allowance relevant long after you last visited its website.

Read the amount as continuing exposure

Imagine an account holding 800 units of a fictional token called ALPHA. Its owner plans to swap 100. Approving a cap of 100 limits the allowance to that amount. Approving an effectively unlimited amount can expose the existing balance and later deposits of ALPHA while that permission remains usable. The wallet's current balance is not necessarily the approval limit.

This example describes permission scope, not a prediction of loss. Some tokens and routers handle allowance consumption differently, and the owner should inspect the resulting state. The main question is whether the requested authority matches the intended action. A convenience setting should never substitute for understanding that scope.

Connection, approval, and execution are separate actions

  • Connecting a wallet gives a site access to the accounts and connection permissions you accept. A conventional connection alone is not an ERC-20 spending allowance.
  • Approving a spender changes token permission state or uses an authorization mechanism that can establish spending rights. It deserves a review independent of the quote.
  • Executing the swap requests the actual exchange, with its own recipient, amounts, route, and price protection settings.

Closing a tab or disconnecting the site does not remove an on-chain allowance. MetaMask's official guide to token approvals and revocation explains this distinction. Public blockchain history also remains public after a connection ends. Disconnection is a useful session control, but it does not rewrite the token contract's records.

A signature can grant meaningful authority

Some workflows replace a standalone approval transaction with signed data. Under ERC-2612, a valid permit signature can be submitted to the token contract to set an allowance. The message includes the owner, spender, value, nonce, and submission deadline, with a domain identifying the signing context. Signing may not itself incur a network fee, but the authorization can still enable token movement.

A subtle distinction matters: an ERC-2612 deadline limits when the signed permit can be submitted. It does not automatically expire an allowance that the permit already established. A nonce helps prevent the same permit from being successfully reused, but this is different from revoking all future spending authority.

Permit2 is another mechanism, implemented through a separate contract. It can support individual signature transfers and allowances with their own expirations, while an underlying ERC-20 approval to Permit2 can remain in place. Read both layers. A screen labeled “signature” or “gasless” is not evidence that the request is harmless, and different signing standards should not be treated as interchangeable.

Check the request against your intention

Before confirming, compare the wallet details with an independently verified description of the action:

  • Network and account: confirm the chain and the address whose assets will be affected. An identical-looking token symbol on another chain can represent a different contract.
  • Token and spender: verify both addresses through the project's established documentation. A familiar logo or a contract name displayed by an explorer is insufficient evidence by itself.
  • Amount: compare the spending cap with the intended input. Check token units and decimals rather than assuming a large displayed number is merely a formatting detail.
  • Duration and nonce: for signatures, inspect the relevant deadline, expiry, and authorization scope. These fields differ across permission systems.
  • Recipient and purpose: make sure the next action sends the expected asset to the intended address. Decline unrelated permissions that the proposed swap does not explain.

When a wallet cannot present a request clearly, pause and consult the protocol's documentation. Guessing from the button label is a poor substitute for understanding the effect. The DeFi glossary can help decode the terms shown during review.

Choose a cap with the tradeoff in view

A limited allowance can reduce the amount available to a spender. Repeated swaps may then require fresh approvals and additional network fees. An unlimited allowance can reduce those repeated prompts, while leaving a wider and longer-lived permission. Neither choice validates the spender's code.

For an unfamiliar workflow, a narrowly scoped permission makes the intended boundary easier to inspect. Avoid increasing a cap merely because an unexplained transaction failed. The underlying problem might concern token compatibility, the wrong network, an expired quote, or another condition. Review the error before changing authority. Our swap cost guide explains why approval and execution expenses should be considered separately.

Review what remains after the swap

Check the confirmed transaction and current allowance using a trusted wallet or explorer for the correct network. If permission is no longer needed, an appropriate revocation transaction usually sets the allowance to zero. On-chain revocation generally requires gas, and it takes effect when the transaction is successfully included. A pending revocation has not yet changed the permission.

If an approval or revocation transaction is included but reverts, gas may still be charged and the intended permission change will not take effect. Check the receipt and current allowance before considering the task finished.

Signed authorizations require additional care. Reducing a current ERC-20 allowance does not necessarily invalidate an unused, still-valid permit signature. The relevant mechanism may require nonce invalidation or another cancellation procedure. Follow the specific contract's documentation rather than assuming one revocation screen covers every kind of authorization. Revocation also cannot reverse transfers that already happened.

Security tools help you evaluate risk

Hardware wallets protect key handling, but they can still sign an unsafe approval that their owner confirms. Transaction simulation may make a proposed result easier to understand, yet its accuracy depends on the simulation and the state it evaluates. Audits, verified source code, and warning systems provide evidence to assess; none guarantees a contract's future behavior.

Keep account exposure proportionate to the activity, retain enough native currency for necessary transactions, and avoid signing under time pressure. A small test can confirm a particular route or recipient, but a successful test does not prove that a contract is safe. The broader wallet and transaction security guide explains these controls in context.

Respond carefully to an unexpected request

If the request does not match your action, reject it and check the site's address through a trusted starting point. Never enter a recovery phrase into a swap website or send it to someone offering support. If you already signed something suspicious, preserve the transaction or message details and identify precisely which permission was granted.

Possible private-key compromise is a different problem from an unwanted allowance. Revoking one spender cannot repair a stolen key. Use your wallet provider's official incident guidance, and avoid depositing more funds into a potentially compromised account without understanding the situation.

Make authorization an explicit decision

A disciplined swap review asks two separate questions: is the proposed exchange acceptable, and is the requested authority appropriate? Confirm both before signing. After execution, review any permission that remains. This approach cannot remove every smart-contract or market risk, but it gives you a clearer account of what your wallet has authorized and why.