ERC-20 approve & transferFrom asset transfer method poses a threat to users’ funds safety.

Dexaran
4 min readJul 22, 2023

--

ERC-20 is the oldest (and the first) Ethereum “token standard” — a documentation of a template of a token that everyone can use to create new tokens.

ERC-20 defines two methods of transferring tokens:

  • transfer function — a “push” transaction of a token.
  • approve function that authorizes someone to perform a “pull transaction” by calling a transferFrom function afterwards.

Push transaction VS Pull transaction

Read a full description of pull vs push payments here.

A push payment is a method of payment whereby a payer initiates the sending of money to a payee. The payer is therefore in control of the payment, including the amount and destination.

A pull payment is a method of payment whereby the payee instructs the payer to send the money. It is therefore the payee who is in control of the payment.

All crypto assets except ERC-20 tokens implement push transaction method including Bitcoin transfers, Ether transfers, ERC-223 token transfers, NFT transfers etc.

A good example of a pull transaction is a credit card payment where you authorize the payee to draw funds from your credit card.

Credit cards are anything but trustless. The adoption of pull transferring method for credit cards is purely based on the legal responsibility of the recipient of the transaction and the operator of the credit card.

ERC-20 pull transactions are similar to card payments where your card operator is totally not responsible for any losses of funds that may occur during the transaction.

Pull transactions pose a huge security threat if applied to decentralized digital assets as you can’t legally pursue the operator of the transfer — you can’t sue a smart-contract and make it return your funds.

Approves do not add any utility. Approves are a deprecated method of bypassing EVM limitations that no longer exist.

ERC-20 pull transaction method is needed for nothing. It was a crutch that fixes a bug in early days EVM.

  • ERC-20 standard was proposed in 2015. At this time there was a bug in Ethereum Virtual Machine 1024 call stack depth. The approve & transferFrom method of the ERC-20 standard was introduced so that this bug does not affect tokens.
  • In Tangerine Whistle hardfork the call stack depth problem was solved. This happened on block 2463000 in 2016. At this time approve+transferFrom method became irrelevant and the ERC-20 standard should have been considered deprecated.
  • In 2017 a new ERC-223 standard was introduced. This standard implements push transaction methods similar to plain Ether transfers.

Here is a Vitaliks’ comment regarding the situation with token standards and call stack depth problem:

It must be noted that there are plenty of assets that do not implement pull transferring method at all:

  • Ether, the native currency of Ethereum platform.
  • ERC-223 tokens
  • EOS and all C++ token contracts of the EOS ecosystem

There is no such problem with digital assets that requires pull transactions to be solved. If an asset implements push transacting method properly — it is totally sufficient for all possible situations.

Poor UI implementations put users funds at serious risk with pull transacting methods

The problem with pull transactions is that it is a pair of transactions in fact. For example in order to swap ERC-20 AAVE for ERC-20 USDT a user needs to approve the contract to withdraw AAVE first, then wait for the transaction to submit and then execute the swap. This needs to be done every time a user wants to swap one ERC-20 asset for another through a smart-contract.

In order to simplify the process for users UI often offers them to issue unlimited approvals for the exchange smart-contract and then execute swaps without approving assets every time.

This is a critical security threat. By issuing an unlimited approval to smart-contract a user actually authorizes the contract to withdraw all the users funds anytime. If a user swapped 1 USDT at an exchange once and then the contract got hacked 15 years later — the contract will be able to drain ALL USERS FUNDS. Multichain was hacked exactly because of this approving method.

If a user sees this small “(one time)” sentence it actually means the service is prompting a user to put all his funds at risk perpetually. Secure implementation can not be “one time” because the standard does not support it.

Do not trust a smart-contract more than you actually need it to take. During 2022 $2,7B worth of assets were stolen as a result of smart-contract hacks. Do not let smart-contract have access to all the funds on your address.

In most cases UIs do not care about removing approvals after a user performs the trade. The users are not even notified that this must be done in most cases which allows approvals to accumulate over time and increases the risks of users funds being drained.

If you trade on an exchange that makes you DEPOSIT funds and you decided to abandon it and removed the funds from your exchange balance — then your funds are safe. If you swapped funds on the AMM exchange and did not remove the approvals from all AMM exchanges you ever interacted with — then your funds can be at risk and even if one of the exchanges will get compromised it will be able to drain your tokens even if you haven’t used this exchange for years.

Push transactions allow the user to stay in control of their funds. Pull transactions are implementation-dependent and involve third parties that can control users funds.

--

--