Does disconnecting my wallet from a dApp revoke token approvals?

No. Disconnecting is a UI-level action and does not change the allowance stored on the token contract. The spender can still use transferFrom up to the approved amount until you revoke or reduce that allowance on-chain.

How do I know which token approvals are most dangerous?

Unlimited approvals are the highest-impact because they let a spender pull as many tokens as you hold if it is malicious or compromised. Old approvals to contracts you no longer use are also common attack surface because they persist until changed.

Is revoking approvals free?

No. Revoking is an on-chain transaction that updates the allowance state, so it costs gas on the network where the approval exists. That cost is why many wallets accumulate dormant approvals over time.

What is Permit2 and why might I not see an approve() transaction?

Permit2 is a Uniswap Labs singleton approval contract that uses EIP-712 signatures to authorize spending with deadlines and nonces. You might only see a one-time on-chain approval to Permit2 for a token, while later authorizations happen via signed typed-data messages rather than separate approve() transactions.

Can I reduce an approval instead of fully revoking it?

Yes. Reducing an allowance is the same mechanism as revoking, just setting it to a smaller number instead of 0. When changing a nonzero allowance to another nonzero value, the safer operational pattern is “approve-to-zero-then-set.”

How to revoke malicious approvals and close the drain path

Revoking malicious approvals means submitting an on-chain transaction that rewrites a token’s allowance, usually setting it to 0 for the spender that can call transferFrom on your balance. Disconnecting a wallet from a dApp is only a UI action, so it does not remove token approvals or stop a wallet drainer that already has spend permission.

Key Takeaways

A token approval is a standing permission at the token contract, and it persists until you change it on-chain.
To revoke approval, you send a transaction that sets the spender’s allowance to 0 or to a smaller amount, and you pay gas.
Unlimited approvals are the blow-up version of allowances because a compromised spender can drain that token balance up to the allowance.
Permit2 can hide risk behind signatures: you might only see one on-chain approval to Permit2 while the real danger is signing a malicious EIP-712 authorization.

Why token approvals can be dangerous

A malicious approval is not “a dApp connection.” It is a live permission sitting on a token contract that says a specific spender can move your tokens with transferFrom. ERC-20 delegated transfers run on three functions: approve(spender, amount), allowance(owner, spender), and transferFrom(from, to, amount). Once that allowance exists, the spender does not need your wallet again. It just needs the allowance to still be nonzero.

That persistence is the whole problem. Allowances stay active until explicitly changed, which is why “disconnect wallet” buttons and wallet connection lists are a false sense of safety. Disconnecting removes a site’s ability to prompt your wallet. It does nothing to the token contract state that actually authorizes spending. This is why approval phishing works: the attacker’s goal is to get a token approval (or a permit-style signature) once, then use it later when the victim is no longer paying attention.

Unlimited approvals are where the tail risk lives. Many UIs default to “infinite” because it reduces future friction, but approving the maximum uint256 amount effectively hands the spender a blank check for that token. If the spender contract is malicious today, or gets exploited later, the allowance is the drain path.

For traders, the mental model that holds up is “standing credit line.” Each token approval is a line item: token → spender → limit. If the reader cannot point to the exact contract that currently has permission to call transferFrom (either directly, or via Permit2), the real exposure is unknown. This is one of the core mechanics behind crypto wallet scams and how to avoid them.

How revoking an approval works

Revoking is not a settings toggle. It is a state change on-chain, which means it costs gas and it leaves a transaction record. Mechanically, a revoke approval is just rewriting the allowance mapping at the token contract so the spender’s allowance becomes 0 (or a smaller number if the goal is to keep using the app with a capped limit).

Two operational details matter more than most guides admit.

One is that “remove token approval” is token-specific. Revoking USDC for a spender does nothing for WETH approvals to the same spender. The allowance ledger is per token contract.

The other is allowance updates can have a race-condition edge case when changing a nonzero allowance N to another nonzero allowance M. The safer pattern is the one Speedrun Ethereum calls “approve-to-zero-then-set.” The idea is simple: set allowance to 0 first, wait for confirmation, then set the new amount. That removes the window where a spender could potentially use both the old and new allowance values.

If a wallet or dApp throws errors like “Approve to zero failed” or “Approve to new amount failed,” it is usually not a sign that revoking is impossible. It is a sign the token’s approval behavior is quirky or the UI is not handling the token’s rules cleanly. The fix is to use a different allowance tool or a block explorer’s token approval interface, then retry the same on-chain change.

The key framing stays consistent: revoking is simply rewriting permission on-chain. If the reader cannot identify the spender that holds the permission, the revoke cannot be targeted correctly.

Step-by-step revocation using Revoke.cash

Revoke.cash is a common workflow because it surfaces approvals in a single dashboard and lets the user submit the on-chain revoke transaction from the same screen. The steps below mirror the in-wallet flow Bifrost Wallet documents, but the sequence is broadly the same across wallets.

1. Open a trusted wallet browser and navigate to Revoke.cash. Using an in-wallet browser reduces the chance of landing on a lookalike domain from ads or DMs. 2. Connect the wallet and select the correct network. Approvals are chain-specific, so an Ethereum approval will not show up when the tool is set to Flare, Base, or another EVM chain. 3. Open the token approvals view and sort by risk. Start with unlimited allowances and tokens with meaningful balances, since those are the highest-impact drain paths. 4. Identify the spender for each risky row. The spender is the contract that can call transferFrom. If the spender name looks unfamiliar, treat it as hostile until proven otherwise. 5. Click revoke for the selected approvals. This submits a transaction that sets the allowance to 0 for that token and spender. 6. Confirm the transaction in the wallet and pay gas. If gas is high, revoking the biggest allowances first is still a rational “insurance premium” trade. 7. Re-check the approval list after confirmation. The allowance should now display as 0, or the row should disappear depending on the tool’s UI.

This is the core answer to how to revoke approvals: the user is not “unlinking” anything. The user is changing the allowance at the token contract. If the wallet drainer already has approval, this is the action that closes the path.

Permit and Permit2 approvals to check

Late 2022 is the inflection point most users missed. Uniswap’s Universal Router made Permit2 the default approval path, which shifted a lot of “approval risk” away from obvious approve() transactions and toward EIP-712 signatures. Permit2 is a Uniswap Labs singleton approval contract: users approve Permit2 once per token, then apps request signed authorizations that include spender, amount, deadline, and nonce.

That creates two ledgers to audit.

Ledger one is classic ERC-20 allowances: token → spender. This is what most “token approval” dashboards show, and it is where unlimited approvals to random contracts usually live.

Ledger two is Permit2: token → Permit2 allowance on-chain, plus the off-chain signed authorizations that apps request. Permit2 supports both standing allowance mode and one-shot transfer mode, and its authorizations are deadline-bound. Deadlines can reduce exposure from dormant permissions because authorizations can auto-expire, but they do not solve signature theft. Approval phishing campaigns increasingly target permit and Permit2 signing prompts because a single signed message can be enough to move funds.

The practical implication is uncomfortable but clean: “I don’t remember approving anything” is not a safety signal. A user can be exposed after signing typed data that never looked like an approve() transaction in their history.

When cleaning up after a scare, the audit should answer one question per token: which contract can currently cause a transferFrom of this token from this wallet? Sometimes it is a direct spender. Sometimes it is Permit2 because the token is approved to the singleton and the user keeps signing prompts blindly. The habit that prevents repeat incidents is the same one covered in how to verify a transaction before signing: treat every signature request as spend authority until proven otherwise.

Prevention checklist after you revoke

After the revoke transactions confirm, the goal is to stop recreating the same exposure the next time a swap, bridge, or staking UI asks for permission. The clean posture is to treat approvals like position sizing: the limit should match the intended action, not the maximum possible.

1. Prefer exact-amount approvals when the UI allows it. Unlimited approvals are convenient, but they are also the highest-impact failure mode if the spender is compromised. 2. If an allowance must be changed from one nonzero value to another, use “approve-to-zero-then-set.” It is a small operational habit that reduces a known race-condition risk. 3. Review approvals periodically with an allowance tracker. Tools named in user-security guidance include Etherscan Token Approvals, Revoke.cash, Debank, and Unrekt. 4. Treat Permit and Permit2 prompts as high-risk moments. Permit2 uses EIP-712 signatures with deadlines and nonces, but signature phishing is still the main way users get drained. 5. Keep the “two ledgers” model on the desk: classic allowances and Permit2. Revoking a random spender does not help if the token is still approved to Permit2 and the wallet keeps signing authorizations from an unverified site.

This is where the broader discipline of crypto wallet scams and how to avoid them becomes operational: reduce standing permissions, verify what is being signed, and pay the gas to close old lines when they stop being useful.

The Take

I’ve watched people do the expensive version of this cleanup: they disconnect a site in their wallet, feel safe, and then get hit again because the allowance at the token contract never changed. The only question that matters is whether a spender can still call transferFrom on that token. If the answer is “yes,” the drain path is still open.

The habit that keeps this cheap is treating approvals like margin lines. Size them to the trade, and when something feels off, revoke the unlimited ones first even if gas is ugly. If Permit2 has been in the flow since late 2022, the second habit is refusing to sign EIP-712 prompts you cannot read. That is where approval phishing lives now.