A user connects to a decentralized exchange to swap tokens, approves a contract to spend a specific amount, and completes the trade. Months later, the exchange changes its smart contract code without warning, or the exchange itself becomes compromised. The approval—which the user may have forgotten—remains active and unlimited, granting permission to transfer any amount of that token from the user’s wallet whenever the contract decides to execute a transfer. This scenario has played out hundreds of times, often resulting in total loss of approved assets. The mechanism driving these losses is the token approval system that underpins Ethereum and EVM-compatible networks, and the first line of defense is visibility and control.

The rabby wallet extension addresses this risk through its approval manager, a tool designed to identify all active token permissions and revoke them selectively. Understanding how approvals work, how they fail, and how to use Rabby’s approval controls effectively is no longer optional knowledge for anyone holding significant assets on Ethereum, Polygon, Arbitrum, or other EVM chains. The distinction between a limited approval and an unlimited one, and between an active permission and a revoked one, can determine whether a user retains their funds or loses them to a compromised dApp.

How token approvals create unlimited permission

On Ethereum and EVM networks, a token transfer requires the recipient to be the one initiating the transaction. This creates a problem for decentralized exchanges, lending protocols, and other smart contracts: they cannot pull funds directly from users’ wallets without explicit permission. The ERC-20 token standard solves this through the approve function, which allows a user to grant a smart contract permission to transfer tokens on their behalf up to a specified amount.

The approval itself is stored on the blockchain as a state change within the token contract. When a user interacts with a dApp, the wallet prompts them to approve a specific spender (the dApp’s contract address) to move up to X tokens. The user signs the transaction, and the approval is recorded. From that point forward, the spender holds the ability to call the transferFrom function and move approved tokens to any destination, without needing the user’s signature on each transaction.

The critical flaw is that many contracts request unlimited approvals. Instead of asking permission to spend exactly 1 ETH equivalent of a token in one trade, they request permission to spend 2^256 minus 1 tokens—effectively infinite, since the token supply rarely exceeds this limit. The justification offered is convenience: unlimited approvals reduce the number of approval transactions required for repeated interactions with the same contract. The cost is that a single vulnerability, contract upgrade, or insider attack can expose the user’s entire holding of that token to instant theft.

Real examples illustrate the stakes. In 2023, the Balancer protocol suffered an exploit where a malicious actor took advantage of a weakness in the contract’s swap logic to drain approved funds from users who had previously interacted with the exchange. Because many users had granted unlimited approvals, the attacker could access entire token balances rather than just the amount they had intended to trade. The approval manager in a DeFi wallet like Rabby’s browser extension allows users to see exactly which contracts hold these dangerous permissions and revoke them before an exploit occurs.

Identifying active approvals in Rabby Wallet Extension

The approval manager is accessible from the wallet’s main interface and displays a list of all contracts that the user has granted token permissions to, across every EVM chain the wallet is connected to. For each approval, Rabby shows the token symbol, the spender contract address, the amount approved (either a specific number or “Unlimited”), the date the approval was granted, and the chain on which it exists.

Finding this interface requires navigating to the main wallet view, then locating the approvals or token permissions section—the exact path varies slightly depending on whether the user is on desktop, mobile, or browser extension. The browser extension version of the rabby wallet extension is typically the most convenient for approval review because it allows side-by-side viewing with the dApp in question. A user can verify the spender address against the contract listed on a blockchain explorer, confirm whether the dApp is still in use, and decide whether the approval should be revoked.

The display should show the spender address in full, allowing the user to paste it into Etherscan, Arbiscan, or the relevant block explorer. Truncated addresses create a false sense of verification; a shortened address like “0x1234…5678” cannot be reliably cross-checked against a known contract. Rabby’s interface should display the complete address or provide an easy copy function. This level of transparency is essential because address spoofing is a known attack vector: a malicious actor may grant themselves approvals under a domain or interface that closely mimics a legitimate dApp.

Users should also filter by chain, since approvals on Polygon, for example, are independent of approvals on Arbitrum or Ethereum mainnet. An approval on Ethereum does not affect the user’s Polygon holdings, but the approval manager should make this distinction explicit. If a user has interacted with the same dApp on multiple chains, they may have separate approvals that require separate revocation.

The difference between revoked and expired approvals

Revoking an approval is different from an approval expiring naturally. An approval expires only if the smart contract explicitly includes expiration logic—most do not. A typical ERC-20 approval has no time limit and no decay mechanism. It persists indefinitely until the token holder explicitly revokes it or until the spender contract is destroyed (an extremely rare event). This is why old approvals granted years ago can still present a current risk if the spender contract is compromised, abandoned, or changes its code.

Revoking an approval requires a blockchain transaction that calls the approve function with a value of zero. The user must pay a gas fee for this transaction. On mainnet Ethereum, the cost can range from a few dollars to tens of dollars depending on network congestion. On cheaper EVM chains like Polygon, the cost might be less than a dollar. The transaction is permanent and recorded on the blockchain; once revoked, the spender can no longer access the approved tokens unless a new approval is granted.

Rabby’s approval manager should streamline the revocation process by providing a single-click revocation for any active approval. Ideally, the wallet allows users to select multiple approvals at once and batch revoke them in a single transaction, reducing the total gas cost compared to revoking each approval individually. This efficiency matters because users with dozens of active approvals could face hundreds of dollars in total revocation costs if they must revoke one at a time on mainnet.

The risk warning system is also important. When a user approves a new contract through a dApp connection, Rabby should display information about whether the approval is limited or unlimited, what the contract address is, and whether the contract has been flagged as risky by community databases or security audits. A clear warning for unlimited approvals can prevent careless approvals at the point of decision, which is far more cost-effective than revoking them later.

Real-world approval exploits and their warning signs

The QubitFinance hack in January 2022 demonstrates a particularly severe approval risk. A vulnerability in the protocol’s cross-chain bridge allowed an attacker to drain approximately 80 million dollars in user funds. Many victims had granted QubitFinance unlimited approval to their USDC and other stablecoins, expecting the protocol to manage only the amount they explicitly deposited. Because the approval was unlimited, the attacker could access the users’ entire balances, not just the deposited amount.

In another case, the Neverending Security incident involved a malicious smart contract that posed as a legitimate dApp. Users unknowingly granted approvals to the attacker’s contract, which then immediately transferred their entire token balances. The attack succeeded not because the ERC-20 standard was flawed, but because users had no easy way to see what approvals they had given, and no warning before granting an approval to an unfamiliar address.

These exploits share common warning signs that the approval manager in Rabby helps users detect. First, very old approvals—those granted months or years ago to projects that the user no longer uses—are low-hanging fruit for attackers. A revoked approval cannot be exploited, even if the underlying contract is compromised. Second, approvals to contracts that have been abandoned or are no longer actively maintained pose a higher risk than approvals to audited, actively developed projects. Third, unlimited approvals create a much larger exposure than limited approvals, even if the spender is trustworthy.

A secondary but important risk is approval reuse. Some dApps use a single contract address for multiple features or chains. If that contract is upgraded without proper testing, or if a developer makes a malicious code change, every user who approved that address—potentially across multiple assets and networks—is affected simultaneously. Reviewing approvals regularly, understanding which dApps still actively serve the user’s needs, and revoking unnecessary ones is the primary mitigation.

A systematic approval audit workflow

Conducting an approval audit through the rabby wallet extension should follow a repeatable process. First, access the approval manager and export or screenshot the complete list of active approvals. Second, for each approval, verify the spender address against the official website or GitHub repository of the dApp in question. Block explorers like Etherscan allow users to check whether a contract is verified (meaning the source code has been published and checked against the bytecode), and community databases like Approved.Zone or the Rabby team’s own risk database can provide context.

Third, determine whether the user still uses the dApp. If the approval was granted to a project abandoned or discontinued years ago, revocation should be immediate. If the dApp is still in active use but the user no longer interacts with it, revocation should still be considered—the risk of an old approval lying dormant outweighs the convenience of skipping an approval step the next time the user may or may not visit that dApp. Fourth, check whether the approval is limited or unlimited. Unlimited approvals should be reviewed with greater scrutiny and revoked more readily than limited ones.

Fifth, prioritize revocation by risk level and gas cost efficiency. If gas fees are high on mainnet Ethereum, the user might first revoke the highest-risk or oldest approvals, then wait for a period of lower congestion before revoking others. Batching revocations in a single transaction can reduce total costs significantly. Sixth, after revocation, verify the transaction on a block explorer and update any notes tracking which approvals remain active.

This process need not be done in a single session. Many users benefit from scheduling a quarterly or semi-annual approval review. The key is consistency: approvals that were safe yesterday may be dangerous today if the underlying contract is compromised. The approval manager in Rabby makes this review fast enough to become a regular security practice rather than a one-time chore.

Preventing unnecessary approvals going forward

The DeFi wallet experience improves significantly when users adopt a habit of scrutinizing approval prompts before signing. When a dApp requests an approval, Rabby should display the transaction details clearly: the spender address, the amount being approved, and the token. Users should pause and ask three questions. First, does the amount match what the transaction requires? If the user is swapping 1 token, they should request approval for at most 1.1 tokens, not unlimited. If the dApp insists on unlimited approval, consider using a different service.

Second, does the spender address belong to the dApp being used? Copy the address from the block explorer or the dApp’s verified GitHub repository and compare it character by character against the approval prompt. A single character difference indicates a phishing or spoofing attack. Third, is the dApp trustworthy? Even established projects can suffer security breaches, but protocols with public audits, active development, and transparent security practices pose lower risk than unaudited new projects or projects that have been abandoned.

Rabby’s transaction simulation feature helps with the second concern by showing what the transaction will actually do before the user signs. If the simulation reveals unexpected behavior—such as sending funds to an address other than the user’s intended recipient—the risk warnings should appear. These warnings are most useful when users actually read them rather than rushing through the approval process.

For users who want to eliminate most approval risk, using limited approvals is the obvious practice, though it requires a small additional approval transaction if the user later needs to interact with the same contract for a larger amount. Some advanced users employ approval patterns where they set a specific spend limit—such as 10 ETH equivalent—that is high enough for most transactions but not unlimited. Others revoke and re-approve before each major transaction. These practices add friction but reduce exposure to dormant approvals.

Integrating approval management into security practice

Approval management cannot exist in isolation from other wallet security practices. A user with perfectly revoked approvals who loses their recovery phrase to a phishing attack has still lost everything. A user with excellent approval hygiene who uses the same weak password across multiple dApps risks account takeover. The approval manager in Rabby is one layer in a multi-layered security approach.

Hardware wallet integration strengthens approval management by ensuring that approval transactions are signed on a secure, isolated device before broadcast. Even if the computer running Rabby is compromised, the attacker cannot forge an approval without physical access to the hardware wallet. Similarly, using Rabby’s open-source code—available on GitHub—allows security researchers and power users to audit the application itself and verify that it correctly displays approvals and broadcasts legitimate revocation transactions.

The approval manager should also be part of onboarding. New users who understand approval risks and establish a routine of reviewing permissions before connecting to dApps will avoid many exploits that plague less careful users. Rabby’s user interface should educate as much as it controls, explaining why unlimited approvals are dangerous and what the safest practices are.

Finally, users should recognize that the rabby wallet extension cannot protect against all approval-related risks. It cannot prevent a user from granting approval to a malicious contract disguised as a legitimate one. It cannot protect approvals that were granted through a different wallet and are now being managed through Rabby. It cannot retroactively revoke approvals if the user’s private key is compromised. What it does provide is transparency, control, and the tools to audit and revoke permissions regularly. That capability, used consistently, prevents the majority of approval-related losses.