Is ERC-20 approve dangerous? Allowances, permit and infinite approvals

• set the allowance to 0 first, then to the new value;
• use a protocol design where the spender only pulls exact amounts right after approval.

OpenZeppelin v5 removed increaseAllowance/decreaseAllowance from its ERC-20, so don't count on them existing.

Some tokens add their own quirks. Mainnet USDT, for example, doesn't return a bool from approve and rejects changing one non-zero allowance to another. In contracts, use OpenZeppelin's SafeERC20, whose forceApprove handles both cases:

using SafeERC20 for IERC20;

token.forceApprove(router, amount);

Permit (EIP-2612): approvals by signature

permit lets the owner sign an EIP-712 message off-chain, and anyone can then submit it to set the allowance. The user doesn't need a separate approve transaction, and the signature has a deadline and a nonce, so it can't be replayed.

Signing a permit in ethers v6, for a token that implements EIP-5267 (eip712Domain(), as OpenZeppelin v5 tokens do):

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const owner = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);
const tokenAddress = "0xTokenAddress";
const spender = "0xSpenderContract";
const amount = ethers.parseUnits("100", 18); // check the token's decimals()

const token = new ethers.Contract(tokenAddress, [
  "function nonces(address) view returns (uint256)",
  "function eip712Domain() view returns (bytes1, string, string, uint256, address, bytes32, uint256[])",
], owner);

const [, name, version, chainId, verifyingContract] = await token.eip712Domain();
const nonce = await token.nonces(owner.address);
const deadline = BigInt(Math.floor(Date.now() / 1000) + 15 * 60); // 15 minutes

const signature = await owner.signTypedData(
  { name, version, chainId, verifyingContract },
  {
    Permit: [
      { name: "owner", type: "address" },
      { name: "spender", type: "address" },
      { name: "value", type: "uint256" },
      { name: "nonce", type: "uint256" },
      { name: "deadline", type: "uint256" },
    ],
  },
  { owner: owner.address, spender, value: amount, nonce, deadline }
);
const { v, r, s } = ethers.Signature.from(signature);

On the contract side, wrap permit in try/catch. Anyone who sees the signature in the mempool can submit it first, which would make your permit call revert even though the allowance is now set:

function depositWithPermit(uint256 amount, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external {
    try IERC20Permit(address(token)).permit(msg.sender, address(this), amount, deadline, v, r, s) {} catch {}
    token.safeTransferFrom(msg.sender, address(this), amount); // fails if no allowance
}

The risk with permit is phishing. A signature costs nothing, shows no transaction, and doesn't appear in your wallet's history. A malicious site can ask you to "sign in" with what is actually a permit for your entire balance, then submit it later. Wallets now display typed-data details, but you still have to read them: the spender, value and deadline fields tell you exactly what you're granting.

Permit2

Uniswap's Permit2 is a shared contract that brings signature-based approvals to any ERC-20, even ones without permit. You approve Permit2 once, then grant individual apps allowances by signature, each with an amount and an expiry. It makes per-app allowances short-lived by default, but the one approval to Permit2 is effectively a key to everything behind it, so Permit2 signatures deserve the same scrutiny as permits.

Check and revoke allowances

Read an allowance directly:

cast call $TOKEN "allowance(address,address)(uint256)" $OWNER $SPENDER --rpc-url $RPC_URL

Revoke it by approving zero:

cast send $TOKEN "approve(address,uint256)" $SPENDER 0 --account me --rpc-url $RPC_URL

Block explorers' token-approval pages and tools like revoke.cash list all open approvals for an address. Revoking costs gas, so start with large or unlimited approvals to contracts you no longer use.

Guidance for developers

• Request the exact amount needed by default; offer "unlimited" as a clear opt-in.
• Prefer permit or Permit2 with short deadlines over long-lived approvals.
• Never let users direct arbitrary calls from a contract that holds approvals.
• Use SafeERC20 for every token interaction.
• If your spender contract is upgradeable, remember that users approved today's code; guard upgrades with a multisig and timelock.

Checklist

1. An allowance is standing permission; treat it like a key.
2. Avoid unlimited approvals to contracts you don't use often.
3. Read every typed-data signature: spender, value, deadline. Never sign what you don't understand, and never paste your seed phrase anywhere.
4. Wrap permit in try/catch and use SafeERC20 in contracts.
5. Review and revoke old approvals periodically.

How do I cut gas costs in Solidity contracts?

Storage dominates gas costs: pack variables, cache storage reads, use constant, immutable, calldata and custom errors, emit events for off-chain data, and measure every change with forge snapshot.

#gas-&-fees#performance#solidity