ERC20 unlimited authorization is convenient for yourself and for hackers, is there a solution?

Many users, in order to save money and trouble, provide unlimited authorization every time they authorize, and as a result, they don’t know which day, they suddenly find that their money is transferred away.

With the explosion of DeFi, the average blockchain veteran user must have authorized the DeFi project more than once, and every time you use a new DApp, you need to authorize this DApp to spend your tokens. In addition to the tedious process, you have to pay a significant fee for each authorization. Many users, in order to save money and trouble, provide unlimited authorization every time, and then suddenly find their money is transferred away one day. The reason for this is not because the private key was stolen, but because of the convenience of giving unlimited authorization to DeFi contracts. Is there a solution?

Why do we need ERC20 authorization?

With the native token ETH on Ether, you can send ETH to that smart contract and invoke the smart contract function at the same time. This is done through a so-called payable funtion. However, since the ERC20 token is itself a smart contract, Ether cannot invoke its functions by sending smart contract tokens directly to the smart contract. The reason is that this transfer happens on the ERC20 token contract, not on the DeFi contract.

So what should you do if you want the contract to call ERC20? The ERC20 standard provides an option for smart contracts to use the transferFrom() function to transfer tokens on behalf of the user. In order to activate this function, the user needs to grant the smart contract permission to transfer tokens.

Once authorized, the user can then “deposit” tokens into the smart contract for use in the DeFi application.

For example, to “deposit” USDT into Aave to earn interest, the user first needs to authorize the Aave contract to withdraw USDT from the user’s wallet, and then call the Aave contract function, specifying the amount of USDT to be deposited. The Aave contract then uses the transferFrom() function to withdraw the appropriate amount of USDT from your wallet to complete the transfer.

Problems with Unlimited ERC20 Authorization

When authorizing the use of DeFi, you have the option to either authorize the coin a single time, i.e., agree to only this transfer, or to authorize it an unlimited number of times in the future, giving the contract the right to manipulate this token in your wallet an unlimited number of times.

Given the imperfection of the underlying Ethernet network on which DeFi currently relies, unlimited authorization of DeFi contracts is a way to effectively improve the DeFi usage experience. It avoids the hassle of authorization before each use and the GAS consumption caused by authorization before each transaction. By setting up unlimited authorization, the user only needs to agree once and the process will not be repeated when making subsequent deposits.

However, there are significant drawbacks to the setup. Because what the user grants, is not just the right to operate the transfer to the contract part of the token, but the dominance of this token in this wallet.

This means that if the contract is left open or hacked, not only the tokens deposited in the DeFi project, but also the corresponding tokens in our own wallets will be at risk. Since this authorization is signed by your own private key, you can’t prevent your property from being stolen in case of an attack, even if you use a cold wallet.

How to prevent the risk?

  1. You can choose to deauthorize assets that are not traded

Nowadays, DeFi projects are like a mushroom, so you may authorize many projects without realizing it, which increases the risk of theft. We can check the authorized contracts on DeBank by checking our own wallet address, and then cancel the authorization of high-risk projects in time.

  1. Use separate numbers and transfer assets in time after transaction

Even if the project is reliable, there is the possibility of being attacked, so it is more important not to put eggs into the same basket.

  1. Consider other projects

Since the bottom layer of Ether cannot be changed, other public chains with flexible bottom layers become the object of subsequent attention.

For example, QuarkChain, which has introduced the Multinative token function, is basically the same as QKC in the QuarkChain mainnet, and can invoke contracts, cross-chains, and pay transaction fees under certain conditions. The native token can perform all the functions of QKC, including cross-chain transfers, except that it cannot participate in QKC network governance. Most of the non-native asset inconvenience issues Defi faces can be addressed. In the future, the native tokens will function exactly the same as QKC in the contract, removing the last layer of barriers to the application of multiple native tokens. This means that no authorization is required, and the problem of unlimited authorization is avoided.


Token authorization is a significant security risk. If we want to improve the user experience and security of cryptocurrency applications, we clearly need to improve the token authorization functionality. Currently, the most promising one is the multi-native token function to solve the security risk caused by the authorization problem from the bottom, but there are still few DeFi projects on the QuarkChain public chain, and I believe there will be a bigger explosion later.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-07-01 01:55
Next 2021-07-01 01:59

Related articles