Open app

HostDeFi › EVM swap allowance review

Review an EVM swap allowance before you approve it

Every ERC-20 swap on HostDeFi can ask for one extra signature first: the token approval. The card's primary button becomes Approve <symbol> exactly when the allowance math requires it — this is what that step grants, who it grants it to, and how to read the wallet prompt instead of blind-signing it.

Product guide · 7 min read · updated September 2026

An ERC-20 token can't be pulled out of your wallet by a contract unless you first tell the token contract to allow it. That permission record is the allowance: stored on the token contract, keyed to one spender address, with a hard cap on how much it can move. On /evm — the KyberSwap-routed swap card covering Ethereum, Optimism, BNB Chain, Polygon, Monad, Base, Arbitrum and Avalanche — the router contract is what executes the trade, so paying with a token means the router needs an allowance for it first.

When the card actually asks

Two conditions have to line up, and the button text tells you which rung you're on:

One honest ordering note: the button checks your balance before it checks the allowance. An unfunded wallet shows Insufficient <symbol> (or Insufficient <gas token> for fee + gas) and never reaches the Approve rung — the approval only surfaces once the balance could actually fund the swap. That's deliberate: there is no reason to sign a permission for a trade you can't pay for.

The observed ladder on /evm: Enter amount → Getting quote… → Insufficient <symbol> → Approve <symbol> → Swap <in> → <out>. The Approve rung sits between a funded balance and the final swap — if you see it, the quote and balance already cleared.

What the wallet prompt is really asking

The approval is a separate transaction to the token contract, not to the swap — the function is approve(spender, amount). Two fields in the wallet prompt deserve your eyes:

FieldWhat it isWhat to check
SpenderThe contract that may move your tokens — the chain's swap router, or its fee-forwarder contract on the chains that use oneIt should be an address the swap needs, not an EOA and not a random contract; the explorer label for the router is the cheap verification
AmountThe cap on what the spender can ever pull — capped allowances bound the risk, unlimited approvals trade one signature now for a standing permissionKnow which you're signing; an unlimited grant is normal UX but it is a standing permission, not a per-trade one

On chains where HostDeFi charges its fee through a forwarder contract, the approval points at that forwarder — it is the address that actually pulls the token in the swap transaction. That's plumbing, not a red flag, but it means the spender name won't always be the famous router; what matters is that it matches the trade you're about to do.

The USDT double-sign is real, not a scam

USDT and a handful of look-alike tokens revert on a nonzero→nonzero allowance change: the contract refuses to let a spender's cap go from 5 straight to 500. The only valid sequence is approve(0), wait for it to confirm, then approve(new). So a second approve prompt after the first is the card doing the safe reset — and if the reset is still pending, it tells you to wait instead of sending the doomed second one. A wallet asking twice in a row for the same token is annoying but correct here.

What the approval does not cover

Scope the permission honestly — it is narrower and broader than people assume at the same time:

The five-second review that matters

Before any approve signature, run the cheap audit: confirm you're on the real /evm surface (the card identifies the connected account and chain, and the chain chips at the top match the network you're paying on), confirm the token contract is the one you meant (the picker's verified check and the address — reading an EVM transaction covers the explorer half), and read the spender + amount fields in the wallet prompt. The approval is the moment a contract gains rights over a token — it deserves more attention than the swap itself, because the swap only runs once while the allowance persists.

Frequently asked

What is a token allowance on an EVM swap?

An ERC-20 allowance is an on-chain permission: the token contract records that one specific spender address may move up to a set amount of your token. Swaps need it because the router contract, not your wallet, performs the token transfer — it can only pull what you approved.

Why does HostDeFi show an Approve button before the swap?

When you pay with an ERC-20 token and your existing allowance is below the amount you entered, the card can't build a fillable transaction — so the primary button becomes "Approve <symbol>". Approving sends a separate transaction to the token contract; once it confirms, the button turns into the real swap.

Does a native-token swap ever ask for approval?

No. ETH, BNB, POL and the other chain gas tokens aren't ERC-20s, so there is no allowance to grant — paying with the chain's native token goes straight to the swap step. The Approve step only ever appears for ERC-20 inputs.

Why did my USDT approval ask me to sign twice?

USDT-style tokens revert if a transaction tries to move a nonzero allowance straight to another nonzero value. The safe sequence is approve(0) first, then approve(the new amount) — two signatures on purpose. If the reset hasn't confirmed yet, the card tells you to wait for it rather than submitting a doomed second approval.

How do I check or revoke an allowance afterward?

The allowance lives on the token contract, not on HostDeFi — read it on the chain's explorer under the token's approval list for your address, or revoke it there (and via the revocation walkthrough in the approvals guide). Approving a fresh swap never quietly widens old permissions; it writes the value you just signed.

HostDeFi is an educational risk tool, not financial advice. On-chain data can be incomplete or manipulated; a clean check is a dated snapshot, not a guarantee. Always do your own research. Free · no signup · a HostDeFi product