Token authorization: What is granted and how to revoke it

Role and revocation method of token authorization

Token authorization is an on-chain permission that is granted by calling the smart contract's approve() function, allowing another contract to transfer a specified amount of a specific token from your wallet at any time without having to request it again. Withdrawing authorization resets the authorization limit to zero-it prevents subsequent use of the authorization, but cannot revoke transfers that have already occurred.

approve() actually awarded

The vast majority of ERC-20 tokens (the standard used by most tokens on Ethereum and its compatible chain) follow a pattern: smart contracts cannot access wallet balances by default. According to multiple sources, before a decentralized exchange, loan agreement or NFT market can transfer user tokens, users must call approve() on the token's own contract and specify the payer's address and authorization amount. Once the transaction is confirmed, the payer contract can call another function transferFrom() at any time to transfer tokens that do not exceed the authorized limit without the wallet holder having to sign again. A common example is: exchanging USDC for ETH on a decentralized exchange requires one transaction to approve the exchange contract to use USDC and another transaction to perform the exchange itself.

According to the instructions, two details are worth noting: authorization is for specific tokens and specific payers-approving a decentralized exchange to use USDC does not mean that the exchange can access ETH or other tokens in its wallet. In addition, the authorization itself is a blockchain transaction that requires payment of network fees and is independent of the operation that triggers it.

Limited and unlimited authorizations

The amount field in the authorizations determines the upper limit. The limited authorization specifies a specific amount-for example, exactly the 500 USDC needed to approve a redemption-and once that amount is used, the next redemption requires a re-initiation of the authorization transaction. Unlimited authorization authorizes the maximum value that the token contract can express, that is, 2^256-1, which is much larger than the total supply of any real token. In effect, this means that the payer can transfer the entire balance of the token in the wallet at any time in the future without having to authorize it again.

Most decentralized applications request unlimited authorization by default because it saves users from repeatedly paying transaction fees-a trade-off. The price for this convenience is that permissions never expire automatically. Some information clearly states that token authorization will not automatically expire. If the contract with unlimited authorization is later exploited, maliciously upgraded, or is not trusted from the start, an attacker can directly withdraw the entire authorized balance without the victim having to sign anything.

How the attack actually works

According to the relevant description, wallet theft operations are usually divided into three steps: bait (phishing website, fake airdrop link or cloned application interface), signature requests disguised as regular connections or pickup operations, and then theft is carried out-the attacker calls transferFrom() through another wallet to extract authorized tokens. Sources indicate that sophisticated attack tools package multiple authorizations (ERC-20, NFT, Permission2 signatures) into one multiple call, empty wallets in seconds, and then transfer funds through exchanges and cross-chain bridges. Another case mentioned that in January 2026, a vulnerability on the SwapNet platform stole approximately US$13.4 million from 20 users who just turned off the platform's default one-time authorization and directly granted unlimited authorization. The attacker then exploited the input verification vulnerability to call transferFrom() on these existing authorizations. In addition, there is also information that the NFT Trader platform lost US$3 million due to attackers taking advantage of the forgotten SetApprovalForAll authorization.

According to relevant data, in the first half of 2025, authorization scams and compromised contracts stole more than US$410 million from cryptocurrency users. In addition, a February 2026 security report showed that signature phishing attacks (i.e. authorized phishing that occurs through signed messages rather than on-chain transactions) increased by 207%.

View and revoke authorizations

Authorizations on the chain with ApprovalIn the form of events, three fields can be seen on the blockchain browser: wallet owner, payer contract, and authorized amount. Revocation of authorization means submitting a new transaction and resetting the authorization limit for a specific payer to zero-this is a one-stop operation that also requires payment of network fees. Common tools include a token authorization checker in the blockchain browser, a stand-alone revocation website, and some built-in authorization management functions in wallets. Some suggestions point out that authorization should be checked regularly every month after a major protocol event occurs, after stopping using a decentralized application. These practices are not total defense, but just a habit of shutting down specific risk exposures.

Permit2: Transfer risks off-chain

According to information, Uniswap Labs deployed a contract called Permit2 in November 2022, which aims to reduce friction and long-term authorization risks in traditional models. Users do not need to grant separate on-chain authorization for each application, but only need to approve the Permit2 contract once for each token; then interactions with each application are authorized through an off-chain signature, which specifies the token, quantity, payer and deadline. By 2025, more than 3.1 million Ethereum main network addresses have been authorized for Permit2 and are used by Uniswap, 1inch, CowSwap and other protocols. Permit2 extends the benefits of the ERC-2612 licensing standard to all tokens and has built-in automatic expiration capabilities. But the trade-off is that the attack surface is shifted rather than eliminated: traditional authorizations are leveraged through forgotten on-chain permissions, while Permission2 signatures are leveraged at signing time-because they appear in the wallet as messages to be signed rather than transactions to be confirmed, phishing websites can present disguised Permission2 authorizations as regular requests.

What is not covered in this article

This article cannot tell readers the total value currently exposed in all wallets. The loss data cited in the article (such as $410 million for the first half of 2025,$13.4 million in January 2026, and $3 million undated) are estimates from single sources or third parties, not audited real-time totals, and no unified data is provided between sources. Revocation of authorization does not reverse the theft that has occurred, but only prevents future use of that specific authorization limit. According to the mechanism description, after an on-chain authorization is given to the Permission2 contract, each application is authorized through an off-chain signature. Revoking an unrelated traditional ERC-20 authorization will not revoke the issued Permission2 signature; to terminate the signature, you need to wait for its expiration time to expire, or revoke the underlying Permission2 level authorization. However, existing information does not detail how to revoke an active Permit2 signature, so this is only based on mechanism inference rather than reported facts. Neither traditional authorization revocation nor Permit2 revocation can solve the problem of stolen private keys or mnemonic phishing, which are independent attack surfaces that are not discussed in depth in this article. As for whether the Permit2 data of 3.1 million addresses has been independently verified online or is only statistics from relevant wallets, the data reviewed in this article does not clearly state.