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.
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:
- The pay side is an ERC-20. Pay with the chain's native token (ETH, BNB, POL…) and there is nothing to approve — the swap signs directly. The Approve rung exists only for token inputs.
- Your existing allowance is below the entered amount. The card reads the allowance for your address on that chain and that token. If it already covers the trade, you never see Approve — you go straight to Swap.
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:
| Field | What it is | What to check |
|---|---|---|
| Spender | The contract that may move your tokens — the chain's swap router, or its fee-forwarder contract on the chains that use one | It 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 |
| Amount | The cap on what the spender can ever pull — capped allowances bound the risk, unlimited approvals trade one signature now for a standing permission | Know 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:
- It is not the swap. Approving moves nothing; it only arms the spender. The trade still needs its own signature after the approval confirms.
- It is not the fee. HostDeFi's 1% is charged on top of the swap — never skimmed from your output — and that flow doesn't ride on the token allowance.
- It is a standing permission. An allowance stays live on-chain until you revoke it or a transaction spends it down. If you later distrust the spender, revoke on the token contract — the approvals guide walks the mechanics: token approval drains and revoking.
- It doesn't transfer your whole wallet. One token, one spender, one cap — an approval on USDC grants nothing over your ETH or your other tokens.
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.