A token swap begins before the trade. It begins when you find a website, connect a wallet, select a network, import a token, review a quote, approve a spender, or sign a message. Each step can introduce a different risk. A polished interface can still point to the wrong contract, request broad permissions, or imitate a legitimate service.
This checklist is meant to create a deliberate pause before any signature. It cannot guarantee that a contract or asset is safe, but it can catch common errors and deceptive prompts. The shorter secure swap topic page is useful as a quick reference; this article explains why each check matters.
Start from a verified website address
Phishing sites often use misspellings, alternate top-level domains, Unicode characters, sponsored advertisements, fake support messages, and cloned design. Use a trusted bookmark or navigate from an independently verified official source. Read the domain character by character. A padlock only means the connection is encrypted; it does not prove that the site is legitimate.
Be cautious with links in direct messages, search ads, social replies, token comments, and unsolicited emails. Attackers frequently create urgency around an airdrop, migration, support case, or failed transaction. If a route was introduced by someone contacting you first, stop and verify through a separate channel.
Protect the recovery phrase and private keys
A swap website does not need a seed phrase, recovery phrase, private key, wallet backup, or one-time authentication code. Those secrets can control the wallet. Entering them into a website or sending them to “support” can lead to complete loss. Legitimate wallet connections and signatures occur through the wallet application.
Store recovery information offline using a method appropriate to your risk model. Avoid screenshots, cloud notes, email drafts, or shared documents. Keep devices and browser extensions updated, remove extensions you do not use, and separate high-value storage from experimental activity when practical.
Understand what “connect” does
Connecting a wallet usually shares public addresses and lets the site request signatures or transactions. Connection alone normally does not transfer funds, but it can reveal holdings and create a trusted-looking context for later prompts. Disconnecting a site does not revoke token approvals that were already recorded on-chain.
Read the wallet’s connection details. Confirm the requested account and network. If the site asks to add an unfamiliar network, verify the chain ID, RPC information, currency symbol, and explorer through official documentation. A malicious RPC can misrepresent data even though it cannot directly derive the private key.
Verify token contracts independently
Anyone can deploy a token with a familiar name or symbol. Confirm the source and destination contract addresses, network, decimals, and token type. Do not rely on logos or auto-complete. Compare the address with official issuer or project documentation and inspect it on a reputable block explorer.
Review holder distribution, liquidity, contract verification, privileged roles, recent transfers, and whether the token has unusual restrictions. These signals do not prove safety, but they can reveal obvious inconsistencies. The MetaMask Help Center’s token safety practices also emphasize verifying token addresses because malicious tokens can imitate popular assets.
Distinguish connections, signatures, permits, approvals, and swaps
A wallet can present several types of request:
- Connection: shares account information and allows future requests.
- Message signature: signs data that may be used for login, orders, permits, or other authorization.
- Token approval: records an on-chain allowance for a spender contract.
- Permit: uses a signature to authorize token spending under a supported standard or contract.
- Swap transaction: sends a contract call that attempts the exchange.
Do not assume a gasless signature is harmless. Some signatures create transferable orders or spending permissions. Read the domain, spender, token, amount, nonce, deadline, and chain data when the wallet exposes them. Reject requests that do not match the action you initiated.
Review token approvals as lasting permissions
An approval can allow a contract to transfer a defined amount or a very large amount of a token. Confirm the spender address returned by the selected route. A familiar protocol name in the interface does not prove that the spender is correct. If the wallet allows a custom spending cap, consider limiting it to the intended amount plus only the margin you understand.
Approvals can remain after a swap and after a site is disconnected. Review allowances periodically using a trusted wallet or block-explorer tool. Revoking an allowance is itself an on-chain transaction and costs gas. Revocation reduces future permission but cannot reverse a transfer that already occurred.
Inspect the transaction before signing
Confirm the network, contract, source amount, output amount, minimum received, recipient, route, slippage, deadline, and network fee. For cross-chain routes, verify source and destination chains, bridge or solver, transferred asset, destination asset, and expected timing. If the wallet displays token movements, compare them with the quote.
Transaction simulation can estimate likely effects and warn about suspicious approvals or asset loss. It is a useful signal, not a guarantee. Simulations depend on current chain state and may not capture later changes, upgradeable contracts, off-chain components, private ordering, or deceptive asset economics.
For a stablecoin destination, verify the issuer or mechanism and the exact network version rather than assuming the symbol represents cash. The altcoin-to-stablecoin route checklist covers native and bridged versions, downstream gas, and post-swap verification.
Use a fresh quote and proportionate limits
Do not sign an old quote after leaving the page idle. Refresh and verify the route again. A failed swap does not automatically mean slippage should be increased. Investigate liquidity, token taxes, amount, gas, approval, and route changes. A broad tolerance can allow a worse execution than intended.
For an unfamiliar route, a smaller test can catch a wrong network, unsupported deposit, basic transfer restriction, or destination-gas problem. A test does not prove that a larger trade will work. Some risks grow with size, and malicious contracts can behave differently under different conditions.
Verify the result and clean up
After confirmation, inspect the transaction on a block explorer. Confirm the output token contract and amount, not only the wallet’s display label. Save the transaction hash, route, timestamp, quote, and fees. Review remaining approvals, especially if the route used a new or broad spender.
If the result is unexpected, stop. Do not respond to unsolicited recovery accounts, do not reveal secrets, and do not sign a second transaction without understanding the first. Identify which transaction confirmed, which assets moved, and which contracts were involved. Use only official support links reached independently.
Urgency is a warning sign. A legitimate support process does not require your seed phrase, remote-control access, or an immediate “verification” transaction to prevent loss.
A pre-signing checklist
- Open the site from a verified bookmark or official source.
- Confirm the domain, connected account, and chain ID.
- Verify source, intermediary, and destination token contracts.
- Identify whether the prompt is a connection, signature, permit, approval, or transaction.
- Check the spender, permission amount, deadline, and network.
- Review route, recipient, expected output, minimum received, slippage, and fees.
- Use simulation and block-explorer data as supporting evidence.
- Retain enough native token for gas and a possible revocation.
- Save records and review allowances after execution.
Conclusion
Wallet safety is a sequence, not a single setting. Verify where you are, what asset you are using, what permission is being requested, what transaction will execute, and what result should appear. A careful review takes longer than clicking a familiar button, but it is much faster than investigating an irreversible transaction after the fact.