3.10 Transaction Order Dependence

This security pitfall is related to transaction order dependence (TOD for short). Remember that in Ethereum transactions submitted by users sit in a data structure known as the mempool and get picked by the different miners for inclusion within blocks.

The specific transactions that are picked, the specific order of those transactions included within the blocks depends on multiple factors and specifically the Gas Price of those transactions itself.

So from an attacker's perspective one can monitor the mempool for interesting transactions that may be exploited by submitting transactions with a Gas Price appropriately chosen, so that the attackers transaction either executes right before or right after the interesting transaction. This is typically known as Front-running and Back-running and may lead to what are known as Sandwich Attacks.

All these aspects are related to assumptions being made on the transaction being included in a specific order by the minor within a block.

So from a security perspective logic within smart contracts should be evaluated to check, if transactions triggering that logic can be front run or background to exploit any aspect of it.

ERC20 approve() Race Condition

A classic example of transaction order dependence is the approve() functionality in the popular ERC20 token standard. Remember that the ERC20 token standard has the notion of an owner of a certain balance of those tokens and there's also the notion of a spender which is a different address that the owner of tokens can approve for a certain allowance amount which the spender is, then allowed to transfer.

Let's take an example to see how the race condition works. Let's say that I am the owner of a certain number of tokens of an ERC20 contract and I want to approve a particular spender with 100 tokens of allowance, so I go ahead and do that with an approve(100) transaction and later I change my mind and I want to reduce the allowance of the spender from 100 to 50.

So I submit a second approve 50 transaction and, if that spender happens to be malicious or untrustworthy and monitors the mempool for this approval transaction, they would see that I'm reducing their approval to 50 by noticing the approve(50) transaction.

In that case they can front run the reduction of approval transaction with a transaction that they send that spends the earlier approved hundred tokens. So that goes through first because of Front-running and when my approve(50) transaction goes through that, would give the spender an allowance of 50.

Now the spender would further go ahead and spend those 50 tokens as well, so effectively instead of allowing the spender to spend only 50 tokens I have let them spend 150 tokens of mine, this is made possible because of transaction order dependence or Front-running.

The mitigation to this the best practice recommended is to not use the ERC20 approve() that is susceptible to this race-condition, but to instead use the increaseAllowance(), the decreaseAllowance() functions that are supported by such contracts.