Why approvals exist at all
The ERC-20 standard has no way for a contract to pull tokens from you unprompted. Instead the token contract keeps an allowance ledger: owner, spender, amount. A swap router calls transferFrom, the token checks the allowance, and the transfer succeeds only within that limit.
Native coins — ETH, BNB, POL, AVAX — do not need this. They travel with the transaction itself, which is why swapping a native coin is a single signature.
Unlimited versus exact allowances
Many interfaces default to an effectively unlimited allowance so you never approve that token again. It is convenient and it is a standing permission: whatever that contract is, or becomes, can move your entire balance of that token at any future moment.
An exact allowance costs one extra approval per swap in gas and removes that standing exposure. On cheap networks the trade-off is easy; on Ethereum mainnet it is a real cost you weigh.
The attack that uses nothing but approvals
A drainer site shows something harmless — a claim button, a mint, an airdrop check — and requests an approval for a valuable token. Nothing leaves your wallet, so nothing looks wrong. Hours or weeks later the spender calls transferFrom and takes the balance.
The defence is reading the approval screen: which token, which spender address, and what amount. If a page that should not need your USDT is asking for unlimited USDT, that is the whole attack visible in one line.
Keeping the list short
Allowances persist until you change them. Reviewing them periodically and revoking the ones you no longer use removes exposure you are not using, which is the cheapest security improvement available to most wallets.
FBT Swap requests approvals only for the token you are swapping and only for the aggregator router that will execute it. Your wallet shows the spender address; that address is worth a glance every time.