ERC20’s unlimited authorization: a contest between convenience and security

With the popularity of DeFi, blockchain users now need to authorize DeFi projects multiple times. Whenever a user wants to use a new DApp, you need to authorize the DApp to use your tokens.

In addition to cumbersome procedures, each authorization has to pay a lot of fees. In order to save money and time, many users choose unlimited authorization when needed.

Therefore, they don’t know when they suddenly discovered that their tokens were transferred away. The reason is not that the private key was stolen, but because they granted unlimited authorization to the DeFi contract. Why is there unlimited authorization? Is there any solution?

Why is there an ERC20 authorization?

Using native tokens on Ethereum, you can send ETH to a smart contract and call it at the same time. This is achieved through the so-called authorization function.

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

So what if the contract needs to call ERC20? In the ERC20 standard, a solution is provided for smart contracts by using 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 perform this operation.

After authorization, users can “deposit” tokens into smart contracts to use DeFi applications.

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 that the user wants to deposit. Then, the Aave contract uses the transferFrom() function to withdraw the corresponding amount of USDT from your wallet to complete the transaction.

The issue of unlimited ERC20 authorization

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

At present, the Ethereum infrastructure on which DeFi relies is not perfect. Therefore, unlimited authorization DeFi contracts are an effective way to improve the DeFi experience.

It avoids the trouble of authorization before each use and the consumption of GAS fees caused by authorization before each transaction. After setting unlimited authorization, the user only needs to agree once to avoid repeating the process in subsequent deposits.

However, this setting has great disadvantages. Because the user grants not only the right to operate the tokens transferred to the contract, but also the right to control the tokens in the wallet.

In other words, once the contract is hacked, not only the tokens deposited in the DeFi project, but also the tokens in our own wallet will be threatened.

Because this authorization is authorized through its own private key signature, once it is attacked, even the use of a cold wallet cannot prevent theft.

How to prevent it?

1.  Cancel the authorization of untraded assets

Now DeFi projects are springing up like mushrooms, and many projects may be authorized without knowing it, which increases the risk of theft. We can query the authorization contract on DeBank by querying our wallet address, and then cancel the authorization of high-risk projects.

2. Use multiple accounts, transfer assets in time after transaction

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

3. Consider other platforms

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

For example, QuarkChain, which has multiple native token functions, will become an 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 participating in QKC network governance, multi-native tokens can also implement all the functions of QKC, including cross-chain transfers.

Most of the non-native asset inconveniences that Defi faces can be resolved. In future contracts, the functions of multi-native tokens will be exactly the same as QKC, eliminating the final obstacle to the application of multi-native tokens. In other words, no authorization is required, avoiding the problem of unlimited authorization.

 in conclusion

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

At present, the multi-native token function has the most potential to solve the security problem from the root cause. However, there are still few DeFi projects based on QuarkChain, and we believe that there will be a big explosion in the future.

Total
0
Shares
Leave a Reply
Related Posts

How to map and claim DOT in Polkadot

After Polkadot CC1 went online yesterday, I received a lot of small partners’ inquiries about how to map DOT. Today we will share one of the functions of Polkadot CC1: how to map DOT on polkadot.js.org/apps/#/claims! Regardless of whether your DOT has…
Read More