ERC20 Infinite Approval: A Battle Between Convenience and Security

With the popularity of DeFi, blockchain users now have to authorize DeFi projects more than once. Whenever a user wants to use a new DApp, you need to authorize the DApp to spend your tokens.

In addition to the complex process, every approval has to pay a lot of fees. In order to save money and time, many users choose infinite approval when needed.

As a result, they do not know the day when they suddenly find that their token has been transferred away. The reason is not that the private key was stolen, but because they granted infinite approval to the DeFi contract. Why is there infinite approval? Is there a solution?

Why is there ERC20 approval?

With the native token on Ethereum, you can send ETH to the smart contract and call it at the same time. This is achieved through the so-called payable function.

However, since the ERC20 token itself is a smart contract, Ethereum cannot call it directly by sending the smart contract tokens to the smart contract. The reason is that the transaction occurs on the ERC20 token contract, not on the DeFi contract.

Then what if the contract is required to call ERC20? In the ERC20 standard, a solution is provided for smart contracts to use the transferFrom() function to transfer tokens on behalf of users. In order to activate this function, the user needs to authorize the smart contract to do so.

After approval, the user can “deposit” the token into the smart contract to use the DeFi application.

For example, if a user deposits USDT into Aave to earn interest, they first need to authorize the Aave contract to withdraw USDT from the user’s wallet.

Then call the Aave contract function to specify the amount of USDT the user wants to deposit. Then, the Aave contract uses the

transferFrom()

Issues With Infinite ERC20 Approval

When authorized to use DeFi, you can choose to authorize once, that is, only agree to this transaction, or infinite times, which allows the contract to operate this token in your wallet unlimited times in the future.

Currently, the Ethereum infrastructure that DeFi relies on is imperfect. So granting infinite approval to DeFi contracts is an effective way to improve the DeFi experience.

It avoids the trouble of approval each time before use and the consumption of the GAS fee caused by approval before each transaction. After setting up the infinite approval, the user only needs to agree once and then avoids repeating the process in future deposits.

However, this setting has big drawbacks. Because what the user grants is not just the right to operate the tokens transferred into the contract, but also the right to control the tokens in the wallet.

In other words, once the contract is attacked by hackers, not only the tokens deposited in the DeFi project but the tokens in our own wallets will also be threatened.

Because this approval is authorized by its own private key signature, once it is attacked, it cannot prevent it from being stolen even if using a cold wallet.

How to Prevent?

1. Cancel approval for the assets that are not being traded

Now DeFi projects are springing up, and many projects may be authorized unknowingly, which increases the risk of being stolen. We can query the authorized contract on DeBank by querying our own wallet addresses, and then cancel approval to the high-risk projects.

2. Use multi-accounts, transfer out assets in time after trading

Even the most reliable projects are likely to be attacked. Therefore, it is more important not to put all your eggs in one basket.

3. Consider other platforms

Since the Ethereum infrastructure cannot be changed, other public chains with flexible infrastructure have become the future choices.

For example, QuarkChain, which has multi-native token functions, will be the alternative. Multi-native tokens have the same status as QKC in the QuarkChain system.

They can call contracts, cross-chain, and pay transaction fees under certain conditions.

In addition to being able to participate in QKC network governance, multi-native tokens can achieve all the functions of QKC, including cross-chain transfers.

Most of the non-native asset inconvenience problems faced by Defi can be solved. In future contracts, the functions of multi-native tokens will be exactly the same as QKC, eliminating the last barrier to applying multi-native tokens. In other words, there is no need for approval, which avoids the problem of infinite approval.

Conclusion

Token approval has great security risks. If we want to improve the user experience and security of cryptocurrency applications, we obviously need to improve the token approval function.

At present, the multi-native token function has the most potential to solve the security problems from the root cause. However, there are still few DeFi projects built on QuarkChain, and we believe there will be great eruptions in the future.

About QuarkChain

Website | Telegram | Twitter | Medium | Reddit | Developer Community