Token approvals in DeFi: allowances, Permit, Permit2, and how drains happen

If you’ve seen a wallet drain story, there’s a good chance approvals were involved. Not because approvals are “bad,” but because they are powerful and easy to misuse when you’re clicking fast.

This post explains:

• what a token approval is (in plain English)
• why “unlimited approvals” are risky
• how Permit (ERC-2612) and Permit2 work
• the safer habits that reduce approval-related losses

If you’re farming points and bouncing across new apps, approvals matter even more. Start from sourced links: points directory.

Quick take

• An approval is permission for a contract to move your tokens later.
• Unlimited approvals are convenient; they also increase blast radius.
• Permit and Permit2 use signatures to set permissions; signatures can still be dangerous.
• Treat unexpected signature requests like you’d treat a suspicious “claim” page.
• Segment wallets so a bad approval can’t wipe your vault.

Nothing here is financial advice. This is operational security.

What an ERC-20 approval actually does

In ERC-20 tokens, spending is usually a two-step flow:

1. You approve a spender (a contract) to use up to some amount.
2. Later, that spender calls transferFrom to move tokens from your wallet.

The key detail: the second step can happen later, without asking you again, as long as the allowance exists.

That’s why approvals are a common drain vector. If you approve the wrong spender, or approve the right spender on the wrong UI, you can lose tokens without a second “confirm” step.

Why unlimited approvals are risky

An unlimited approval is a convenience trade:

• upside: fewer transactions later
• downside: if the spender is malicious or compromised, it can take more

Unlimited approvals are not always reckless. They are often a reasonable UX choice for low balances. They become dangerous when:

• the wallet holds meaningful size
• the spender is new or not well-understood
• you’re interacting via an unfamiliar quest UI

If you’re doing points farming, treat unlimited approvals as “high-trust mode.” Use them only when you would trust the spender with the entire token balance in that wallet.

Permit (ERC-2612): approvals by signature

Permit is an ERC standard that lets you set an allowance using a signed message instead of an on-chain approve transaction.

What changes:

• You sign a typed message (often EIP-712).
• The contract uses that signature to set your allowance.

This can be safer in some UX flows, but it doesn’t remove risk. You’re still granting permission. If you sign a permit for the wrong spender or wrong amount, you can still get drained.

Permit2: a shared permission layer (why it exists)

Permit2 is a contract system that can manage token transfer permissions for many apps. It exists to unify permissions and improve UX across tokens and apps.

The tradeoff is the same: you’re granting permission. The difference is where the permission is managed and how apps consume it.

If you see a signature request referencing Permit2, don’t assume it’s safe or unsafe by default. Verify:

• who the spender is
• what token and amount are being authorized
• how long the permission lasts (deadlines matter)

The approval risk table

Use this table as a quick mental model as of 2025-12-30.

The mechanism is not the problem. The rushed, unsourced workflow is the problem.

How drains happen (the patterns to recognize)

This section is about recognition, not paranoia.

Common patterns:

• Lookalike domains: you “approved Uniswap,” but you were on un1swap or a cloned UI.
• Fake claim pages: a “claim” prompt is used to get you to sign a permit or approve a malicious spender.
• Unexpected spender: you approve a contract that isn’t the protocol you think you’re using.
• Approval persistence: you approved months ago; the permission is still live today.

The fix is not to avoid DeFi. The fix is to reduce the probability of a bad approval and limit how much it can take.

For link verification, read: how to verify a points program is real.

Safer habits (that don’t require perfection)

These are boring. That’s why they work.

• Use a dedicated farming wallet with limited balances: wallet hygiene for points farming.
• Prefer sourced links and bookmarks; stop searching for apps.
• Review spender addresses when your wallet shows them.
• Avoid unlimited approvals for new or unclear contracts.
• Revoke approvals you no longer need, especially after quests.
• Keep a record of what you approved and why.

If you want a simple recordkeeping template: questing recordkeeping.

How DeFi Farmer helps

DeFi Farmer is built around the biggest operational failure modes:

• unsourced program info
• unsafe outbound links

Start from the directory, open a protocol page, and click out from sourced links:

• points directory
• Protocols

FAQ

Are approvals always dangerous?

No. Approvals are a normal part of ERC-20 UX. They become dangerous when you approve the wrong spender or grant broader permission than you intended.

Is signing a message “safer” than an on-chain transaction?

Not automatically. A signature can authorize powerful actions depending on the system. Treat unexpected signature requests as high risk.

How often should I revoke approvals?

After you finish a quest or stop using a protocol, it’s worth reviewing and revoking what you don’t need. The goal is fewer lingering permissions.

What’s the safest wallet setup?

One that contains blast radius: vault wallet for storage, and smaller hot wallets for higher-risk activity.

Next step

• Start from sourced campaigns: points directory
• Use the safety baseline: airdrop farming checklist
• Set up wallet hygiene: wallet hygiene for points farming

Sources and further reading

• ERC-20 token standard (allowances): https://eips.ethereum.org/EIPS/eip-20
• EIP-712 typed structured data signing: https://eips.ethereum.org/EIPS/eip-712
• Permit (ERC-2612): https://eips.ethereum.org/EIPS/eip-2612
• Permit2 (Uniswap docs): https://docs.uniswap.org/contracts/permit2/overview