Research Summary: SoK: Transparent Dishonesty: Front-running Attacks on Blockchain


  • This paper surveyed front-running attacks across the top 25 DApps on the Ethereum blockchain and the ICO. Finally, they proposed solutions to prevent this type of attack.


  • Eskandari, Shayan, Seyedehmahsa Moosavi, and Jeremy Clark. “Sok: Transparent dishonesty: front-running attacks on blockchain.” International Conference on Financial Cryptography and Data Security. Springer, Cham, 2019.


Core Research Question

  • What are the types of front-running attacks on blockchain and how to prevent them?


  • Front-running is an action where an entity benefits from prior access to privileged market information about upcoming transactions and trades.
  • Front-running attack on blockchain happens when a malicious node observes a transaction after it is broadcast but before it is finalized, and attempts to have its own transaction confirmed before or instead of the observed transaction. Miners on blockchain can reorder transactions to generate profits.
  • Gas is what users have to pay for computations on the Ethereum blockchain.
  • Gas price is how much one should pay for a unit of gas. Miners will execute transactions with higher gas prices more quickly.
  • DApps stand for Decentralized Applications. They are blockchain applications built with smart contracts.
  • ICO stands for Initial Coin Offering, which is how funds are raised for new cryptocurrency ventures.


  • The authors provide background information and review related works on traditional and blockchain front-running.
    • Traditional:
      • Who
        • Anyone that can trade
      • Method
        • A trader overhears a transaction from a broker and buys before her.
        • A broker buys before her own client’s transaction is performed.
      • Regulation
        • illegal, regulated by SEC (Securities Exchange Commission).
    • Blockchain:
      • Who
        • Miners
        • Anyone that runs a full-node Ethereum client
      • Method
        • A miner can reorder known transactions to make his own late transaction be executed before the others.
        • A user can front-run pending transactions by sending transactions with a higher gas price.
        • A user can double-spend her Bitcoin by broadcasting a competing transaction with higher transaction fees that sends the same unspent coins to herself.
      • Regulation
        • None
  • They classify front-running attacks into three different categories: displacement, insertion, and suppression attacks.
    • Displacement attack
      • What
        • The adversary runs a function before the victim, and makes the victim’s action in vain.
      • Example
        • The victim tries to (1) register a domain name, (2) submit a bug bounty, or (3) submit a bid in an auction and the adversary performs it first
    • Insertion attack
      • What
        • The adversary runs a function before the victim and lets the victim execute the function right after her.
      • Example
        • After the victim places a purchase order higher than the best offered price, the adversary inserts two transactions before it: (1) places a purchase order at the best offered price, (2) places a sale order at a slightly higher price than the victim’s original purchase price. If the victim’s transaction is executed, the adversary profits immediately from the price differences without holding the asset.
    • Suppression attack
      • What
        • The adversary delays the victim to run her function until running the function makes no differences to the adversary.
      • Example
        • In Fomo3D, the winner is the one that bought the last ticket when the timer goes to 0. The timer increases whenever a new ticket is bought. The final winner sent multiple high-gas price transactions to let the timer count to 0 before anyone else purchased a ticket.
  • They explain how front-running attacks can be conducted on the top 25 DApps from in September 2018.
  • They categorize the DApps into four types: (1) Markets and Exchanges, (2) Crypto-Collectibles Games, (3) Gambling, (4) Name Services, and describe each of them in detail.
  • They investigate the front-running attack transactions in the ICO and explain how the malicious miners earned profit.
    • Who
      • F2Pool, an Ethereum mining pool with 23% of the mining hash rate at that time
    • Rules to gain profit
      • adopted the token distribution method “Dynamic Ceiling” to increase the opportunity for smaller investors, which means each address has a maximum investing amount.
      • A user can bypass this by investing from multiple different addresses.
    • Steps
      • Before the ICO, F2Pool sent 100 Ether to 30 new Ethereum addresses
      • When the ICO opened, F2Pool constructed 31 transactions to the ICO smart contract without broadcasting them.
      • They used their entire mining power to mine their own transactions.
    • Result
      • F2Pool ended up investing more than the capped amount per address and was able to invest at a better price before other investing transactions were processed.
  • They describe methods to prevent traditional front-running.
    • Dark pool: A privately organized, legal financial exchange for trading securities, which allows institutional investors to trade without exposure until after the trade has been executed.
    • Sealed bid: A written bid placed in a sealed envelope. All bids are opened together. The highest bidder is the winner of the bidding process.
  • They suggest three ways to prevent front-running attacks: (1) remove the miner’s ability to arbitrarily order transactions, (2) use cryptographic techniques to limit the visibility of transactions, and (3) design DApps from the bottom-up to remove the importance of transaction ordering.
    • Transaction sequencing
      • Background: Ethereum stores pending transactions in pools without intrinsic order. Miners are free to select and sequence the transactions from the pools in their favor.
      • Difficulties: FIFO (First In First Out) is not possible on blockchain because transactions may reach nodes in a different order.
      • Solution 1: Sequence transactions pseudorandomly
        • Canonical Transaction Ordering Rule (CTOR): order transactions in lexicographical order according to their hash
        • Method to break: A front-runner can construct multiple transactions with slightly different values, until she finds a candidate that positions her transaction a desirable location in the resulting sequence. She broadcasts only this transaction.
      • Solution 2: Transactions themselves can enforce order.
        • The transaction can specify the current state as the only state to execute on.
        • Drawbacks: (1) This method cannot prevent the displacement attack. (2) Concurrent transactions are hard to adopt this method, since states are updated once per block, which is not applicable for active DApps.
    • Confidentiality
      • Background: Front-running would not be possible on DApps with confidentiality, since the details of transactions is not revealed.
      • Problem: Domain registration DApps require the state changes to be publicly visible.
    • Commit / reveal scheme
      • Background: The commitment scheme is to commit to a digital value while keeping it a secret, then open it at a later time. It can be used to make function call parameters confidential until the function execution order is finalized.
      • Steps:
        • Submit the hash of the value with a random nonce to a smart contract
        • Reveal the original value and nonce
        • The smart contract can validate the value by hashing the revealed value and the nonce.
      • Problem: An adversary can submit multiple committed transactions and only execute the one that is favorable to herself.
      • Solution: Let the user deposit to commit transactions. The deposit will be forfeited if the transaction is not executed at last.
    • Enhanced commit / reveal scheme: Submarine Commitments
      • Background: Instead of submitting the commits directly to the smart contract and having the contract address revealed and the transaction to be front-runnable itself, the user submits to a submarine address and lets the submarine address interact with the target smart contract. The commit transaction is indistinguishable from sending tokens to a fresh address.
      • Open sourced smart contract library:
    • Design best practices
      • Use call market design in a decentralized exchange: The arrival time of orders does not matter as they are executed in batches
      • Provide updated implementations of existing functions that prevents front-running attacks
        • For example, the approve() function in ERC20 was subjected to the insertion attack, where the front-runner spends a user’s previously approved balances right before he updates his new allowance. The new allowance will also be spent afterwards.
        • Solution: decreaseApproval()/increaseApproval() were added in updated implementations to mitigate this attack.


  • The codebase of this work is open sourced on their GitHub.
  • To investigate the transactions in the ICO, the authors use Go Ethereum (Geth) for the full node.
  • They use the Python script ethereum-etl and Google BigQuery to extract, transform, and load Ethereum blocks.
  • They use the data analysis tool Tableau and Blockseer to build the graphs.


  • Observing the distribution of the successful (invest successfully) and failed transactions during the ICO, it is obvious that F2Pool is abnormal.
  • Graphical illustration of the front-running attack during the ICO:

Discussion & Key Takeaways

  • This paper compares front-running between traditional finance and DeFi, and describes how front-running attacks are performed in the two scenarios.
  • In traditional finance, front-runners can be anyone that can trade, while in blockchain, front-runners can be miners or anyone that runs a full node client. Both scenarios require information about the upcoming trade before it is public.
  • Double spending attack can be achieved by front-running.
  • Some front-running attacks require the victim to execute the function call after the execution of the adversary’s function, while some do not.
  • The final winner of Fomo3D won with a front-running attack.
  • In ICO, an Ethereum mining pool called F2Pool conducted a front-running attack to invest with lower prices and more than the maximum amount per account.
  • Mining pools are the most powerful front-runners. They can not only gain first hand information of transactions, but also choose to process the transactions they submitted first.
  • The three ways the authors suggest to prevent front-running attacks in blockchain are (1) remove the miner’s ability to arbitrarily order transactions, (2) use cryptographic techniques to limit the visibility of transactions, and (3) design DApps from the bottom-up to remove the importance of transaction ordering.

Implications & Follow-ups

  • Current developers don’t have the mindset to design DApps that are immune to front-running.
  • While it is possible to mitigate front-running with the application-logic of DApps, modifications on the blockchain level may be more effective.
  • Traditional ways to prevent front-running (dark pool and sealed bid) are hard to be implemented as fully decentralized applications, because the transactions are all publicly visible on the blockchain.


  • DeFi application developers can reference the methods to mitigate front-running attacks in this paper for a more robust system.
  • In the future, most DApps may be running on layer 2 chains. Thus, if layer 2 designs have front-running prevention techniques integrated, this problem can be solved fundamentally.
  • Front-running attack detection systems can be developed by referencing this paper’s survey of current attack vectors.

This is a great analysis of a huge potential problem. These type of attacks are particularly problematic when the mining pools have access to large amounts of capital in tandem with hashing power, as they can run attacks on other chains or on specific tokens within the ethereum ecosystem. It is hard to tell if these design flaws are due to the developers having no knowledge of malicious attackers, or the developers giving users the benefit of the doubt to the detriment of trade integrity. The hidden transaction is a potential step, but that still doesn’t fix offline miner collusion. Removing the capacity for mining pools to order which operation is accepted seems to be one of the only viable solutions to preventing offline collusion if I am reading this correctly?


I’m curious to know if @root has any followup thoughts on this specifically!


It’s impossible to enforce that at the consensus layer because smart contracts are not executed atomically, so the ability to change ordering is critical.

One potential remediation is to externalize the creation of block templates to mining pool constituents instead of operators, similar to what braiins is trying to accomplish with Stratum V2. That would decentralize pools and make collision harder to coordinate, but it’s hard to see a scenario where pool operators give up this power without substantial community pressure.


As of now, it is not a viable solution, there are many ways to bypass any enforced ordering, as an example if you sort transactions by their hash, first of all transactions that were not broadcasted might cause forks in the network, as @tina1998612 wrote a TLDR version of the section:

Darkpool style ordering might work, but requires changes in the protocol to incentive miners to call close_market at the end of the block, which still gives them the ability to add their transactions right before.

One of the ideas of this paper, was to put this issue on the spotlight so developers be aware of this issue, and given the incidents in the last year, they mostly are. But new devs coming from traditional software development to smart contract development are still not fully aware. I discussed this issue and some other in this talk: Security By Design & Smart Contract Audits | Shayan Eskandari - YouTube


Coming back to this thread after reading the TEX thread.

TEX is presented as a solution to the problems being surfaced on this thread. In particular, I wonder if it addresses the observation made by @root that

where the non-viable solution is