Many new users of Ethereum are confused about the "approve" operation when they first encounter a smart contract. They don't understand what approve is, and they don't understand why it is necessary to initiate a transaction without carrying any assets, and to pay a miner's fee.
In this article, we will explain the nature of the "approve" operation from the technical point of view.
When a user interacts with an Ethereum smart contract for token assets, the first thing he has to do is to perform an approve operation. So, why is there an approve operation?
Let's take a case of a NEST oracle miner quotation.
Bob is a NEST oracle machine quote miner, and when he participates in the ETH/USDT price oracle machine quote, he needs to transfer both ETH and USDT assets to the quote contract according to his quote data, let's say 10 ETH and 1600 USDT, to perform a quote operation.
Then Bob will first approve the USDT assets to the NEST Oracle Machine's quote contract, giving the quote contract permission to operate the USDT assets in Bob's wallet, so that the transaction logic involving the USDT assets can be executed smoothly when a verifier takes the order during the quote lifecycle.
The approve here is also essentially an on-chain transaction that requires the user to pay a miner's fee (Gas fee). The purpose is to tell the USDT token contract that the target smart contract A has access to X amount of USDT assets in the wallet. Then, when the target contract A needs to make a USDT transaction within it, it will actively retrieve no more than X amount of USDT assets from the USDT token contract.
But in the above case, another question arises: Why is it that only ERC20 token like USDT needs to be approved during the quoting process, but not ETH?
Technical explanation: Because ETH is a native asset of the Ethereum network, when transferring money to the target smart contract, the underlying Ethereum network forces the target contract to have a definite receiving method, so the transaction itself can carry ETH assets to the target contract; while ERC20 token, when transferring money to the target contract, only changes the book information of the ERC20 token contract itself, and the target contract will not receive any notification. will not receive any notification.
Therefore, ETH does not require the same approve as ERC20 token when interacting with the value of a smart contract.
To be precise, the approve operation has 2 steps.
Step 1: Approve the transaction itself. This is to tell an ERC20 token contract that a target smart contract address A may come to my wallet account in the future and take X amount of that token asset.
Step 2: The transaction execution itself. When the execution of the logic in the target contract A requires a token transaction, contract A will initiate a transaction that triggers an ERC20 token to take X amount of the token; conversely, if there is no transaction involving the token, no asset transaction will actually occur, even if it has been approved.
In short, the approved operation does not necessarily execute the token transaction, but only reserves the right to operate the funds for the target contract A.
Many smart contract developers set the maximum number of tokens to be approved to the target smart contract by default in order to avoid repeated approve operations by users. Obviously, there is a risk of losing the token assets if the smart contract is vulnerable or the contract administrator is evil, which is the problem of "over-approve".
We encounter this problem frequently, both in NEST DAPPs and imToken wallets.
In order to solve the problem of "over-approve", NEST DAPP has an approve management page, if the miner himself does not expect to participate in the NEST oracle machine quotation in a short period of time, then he can perform the operation of "cancel approve" to eliminate the security problems caused by the existing approve. The imToken wallet also takes measures such as "clear approve information" for each approve, and has a proprietary DAPP for approve management, allowing users to freely manage their existing approves.
Possible solution to skip the approve operation: The current approve operation can be avoided by implementing a specific transfer logic in the ERC20 token contract, i.e., forcing a method of the target contract to be called at the same time as the transfer. However, in order to maintain the purity of the token contract, this feature is not implemented in the mainstream ERC20 token.