pith. sign in

arxiv: 1907.00903 · v1 · pith:6ZH4IOGUnew · submitted 2019-07-01 · 💻 cs.CR

Resolving the Multiple Withdrawal Attack on ERC20 Tokens

Reza Rahimian , Shayan Eskandari , Jeremy Clark This is my paper

Pith reviewed 2026-05-25 11:41 UTC · model grok-4.3

classification 💻 cs.CR
keywords ERC20multiple withdrawal attackapprove methodfront-runningEthereumtoken securitymitigationallowance
0
0 comments X

The pith

Two new mitigations resolve the multiple withdrawal attack on ERC20 tokens, one within standard constraints.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

ERC20's approve method lets a token owner grant another address permission to withdraw up to a set number of tokens. Changing this number exposes a front-running vulnerability where the approved party can withdraw the old amount before the change takes effect and the new amount afterward. The paper reviews ten existing proposed fixes and finds none fully satisfactory. It introduces two original solutions that block the attack, with the first complying with ERC20 requirements and the second exposing a broader limit in securing the issue through the approve method.

Core claim

No existing mitigation is fully satisfactory; the two proposed solutions mitigate the attack, with one fulfilling the constraints of the ERC20 standard and the second showing a general limitation in addressing this issue from ERC20's approve method.

What carries the argument

The ERC20 approve() method, which sets an allowance that can be front-run during changes from one value to another.

If this is right

  • Tokens using the first proposed solution allow safe changes to approval amounts without double withdrawal risk.
  • The first solution preserves compatibility with current ERC20 dapps, UIs, and web applications.
  • The second solution shows that adjustments to the approve method alone cannot fully close the vulnerability.
  • Both solutions stop the attacker from withdrawing both the prior and updated allowance amounts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Token developers may shift toward standards that mandate separate increase and decrease allowance functions.
  • This attack type points to wider risks from transaction reordering in permission systems on public blockchains.
  • Similar front-running issues could appear in other smart contract mechanisms that rely on mutable approvals or permissions.

Load-bearing premise

The front-running attack on approval changes is realistic in practice and the proposed mitigations prevent it without introducing new attack vectors or breaking interoperability with existing dapps and UIs.

What would settle it

A working demonstration of the multiple withdrawal attack succeeding on a token that implements either of the two proposed mitigations.

Figures

Figures reproduced from arXiv: 1907.00903 by Jeremy Clark, Reza Rahimian, Shayan Eskandari.

Figure 1
Figure 1. Figure 1: The ERC20 standard defines 6 methods and 2 events that must [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Comparison of 10 proposals and 2 contributed by this paper. In our first proposal, CAS is used to mitigate the attack by comparing [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Possible “multiple withdrawal attack” in ERC20 tokens when Alice changes Bob’s allowance from N to M. By front-running, Bob is able to move total of N+M tokens from Alice. Possible mitigation should consider Bob’s initial transfer of N tokens as legitimate transaction (step 3) and prevent the second transfer of M tokens (step 4). In summary, in attempting to change Bob’s allowance from N to M, Alice makes … view at source ↗
Figure 4
Figure 4. Figure 4: Recommendation of ERC20 standard to mitigate [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: In “Detecting token transfers”, the approve method needs to be modified by adding a line of code like allowed[msg.sender][_spender].used = false; between lines 16 and 17 to unlock spender flag for the next legitimate change. However, this change makes attack mitigation ineffective. safer functions will not be used by ERC20-compliant web apps and smart contracts that are already deployed. Such deployments w… view at source ↗
Figure 8
Figure 8. Figure 8: An overloaded approve method adds a method with three [PITH_FULL_IMAGE:figures/full_fig_p006_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Modified version of transferFrom for keeping track of transferred tokens per spender. purposes, mostly around functionality but some address multiple withdrawals. We summarize the main proposals in [PITH_FULL_IMAGE:figures/full_fig_p007_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Added code block to approve function to prevent the attack by comparing and setting new allowance atomically. new variable to the transferFrom method (see Fig￾ure 9). Since this is an internal variable, it is not vis￾ible to already deployed smart contracts and keeps the transferFrom function ERC20-compatible. Similarly, a block of code is added to the approve function (see [PITH_FULL_IMAGE:figures/full_… view at source ↗
Figure 11
Figure 11. Figure 11: Comparison of gas consumption between standard implemen [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 13
Figure 13. Figure 13: ERC20 transferFrom method definition that emphasizes on throwing an exception when the spender is not authorized to move tokens. with the ERC20 standard (see figure 13). In our solution, there is no relation between allowance (allowed[_from][msg.sender]) and transferred tokens (transferred[_from][msg.sender]). The first variable shows lifetime transferable tokens by a spender and can be changed independen… view at source ↗
read the original abstract

Custom tokens are an integral component of decentralized applications (dapps) deployed on Ethereum and other blockchain platforms. For Ethereum, the ERC20 standard is a widely used token interface and is interoperable with many existing dapps, user interface platforms, and popular web applications (e.g., exchange services). An ERC20 security issue, known as the "multiple withdrawal attack", was raised on GitHub and has been open since November 2016. The issue concerns ERC20's defined method approve() which was envisioned as a way for token holders to give permission for other users and dapps to withdraw a capped number of tokens. The security issue arises when a token holder wants to adjust the amount of approved tokens from N to M (this could be an increase or decrease). If malicious, a user or dapp who is approved for N tokens can front-run the adjustment transaction to first withdraw N tokens, then allow the approval to be confirmed, and withdraw an additional M tokens. In this paper, we evaluate 10 proposed mitigations for this issues and find that no solution is fully satisfactory. We then propose 2 new solutions that mitigate the attack, one of which fully fulfills constraints of the standard, and the second one shows a general limitation in addressing this issue from ERC20's approve method.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript evaluates ten existing mitigations for the multiple-withdrawal (front-running) attack on ERC20's approve() method, in which an approved party can withdraw both the old and new allowance amounts by ordering transactions appropriately. It concludes that none of the ten is fully satisfactory under the authors' criteria. The authors then present two new proposals: one that remains compliant with the ERC20 interface and a second that demonstrates an inherent limitation when attempting to solve the problem solely through modifications to approve().

Significance. If the case-by-case analysis is accurate, the paper supplies a useful consolidation of a long-standing ERC20 security issue first noted in 2016. By enumerating shortcomings of prior patches and offering concrete alternatives, it can inform token developers and future token standards. The work is an external security analysis rather than a formal proof or empirical measurement study; its value therefore lies in the clarity of the enumeration and the identification of a general limitation in the approve() design.

major comments (2)
  1. [Section 4] The central claim that 'no solution is fully satisfactory' rests on the evaluation of the ten mitigations (Section 4). The manuscript does not supply the concrete test scenarios, code snippets, or decision criteria used to reach that verdict for each mitigation; without these details the conclusion cannot be independently verified.
  2. [Section 5.2] Proposed Solution 2 (Section 5.2) is presented as exposing a general limitation of the approve() method, yet the text does not demonstrate that the new proposal itself avoids introducing fresh front-running vectors or breaking existing dApp integrations—the two assumptions identified as weakest in the analysis.
minor comments (2)
  1. [Abstract / Introduction] The abstract and introduction should include the URL or issue number of the original GitHub discussion referenced in November 2016.
  2. [Section 4 / Section 5] A summary table listing all twelve approaches (ten existing + two new) together with the authors' pass/fail verdict on each would improve readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our analysis of the ERC20 multiple-withdrawal attack. The comments highlight areas where additional detail will improve verifiability and completeness. We address each major comment below and will incorporate the suggested clarifications in the revised manuscript.

read point-by-point responses

  1. Referee: [Section 4] The central claim that 'no solution is fully satisfactory' rests on the evaluation of the ten mitigations (Section 4). The manuscript does not supply the concrete test scenarios, code snippets, or decision criteria used to reach that verdict for each mitigation; without these details the conclusion cannot be independently verified.

    Authors: We agree that the evaluation in Section 4 would benefit from greater explicitness to support independent verification. The original analysis applied a consistent set of criteria (compliance with the ERC20 interface, resistance to the described front-running attack, and preservation of existing dApp behavior) across all ten mitigations, but these were not enumerated with per-mitigation test cases. In the revision we will add a dedicated subsection listing the precise decision criteria, one or more concrete transaction-ordering test scenarios for each mitigation, and pseudocode or Solidity snippets illustrating the attack surface where relevant. This will make the conclusion that none of the ten mitigations is fully satisfactory directly checkable. revision: yes

  2. Referee: [Section 5.2] Proposed Solution 2 (Section 5.2) is presented as exposing a general limitation of the approve() method, yet the text does not demonstrate that the new proposal itself avoids introducing fresh front-running vectors or breaking existing dApp integrations—the two assumptions identified as weakest in the analysis.

    Authors: We accept that the current text of Section 5.2 does not contain an explicit argument that Solution 2 introduces no new front-running vectors and maintains dApp compatibility. Solution 2 is intentionally non-compliant with the ERC20 interface precisely to illustrate the inherent limitation of working only inside approve(); its design therefore trades interface compatibility for attack resistance. In the revision we will add a short subsection that (a) enumerates why the new call pattern cannot be front-run in the same manner and (b) discusses the resulting breakage of existing dApp integrations, thereby making the trade-off explicit rather than implicit. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper performs an external security analysis of the ERC20 multiple-withdrawal attack and evaluates ten prior mitigations plus two new proposals through case-by-case reasoning. No equations, fitted parameters, predictions, or self-citation chains appear in the argument structure; the claims rest on direct examination of the ERC20 interface and documented attack scenarios rather than any reduction of results to the paper's own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The analysis rests on the documented ERC20 standard definition of approve() and the described front-running attack scenario from GitHub discussions; no free parameters or invented entities are introduced.

axioms (2)
  • domain assumption The ERC20 approve() function behaves as specified in the standard and is used by existing dapps and UIs without modification.
    Invoked throughout the abstract as the basis for the attack and all mitigations.
  • domain assumption Front-running of transactions is possible on Ethereum due to public mempool visibility.
    Required for the multiple withdrawal attack to be feasible.

pith-pipeline@v0.9.0 · 5760 in / 1254 out tokens · 32907 ms · 2026-05-25T11:41:33.696919+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages · 1 internal anchor

  1. [1]

    Ethereum project repository

    Ethereum. Ethereum project repository. https://github.com/ ethereum, May 2014. [Online; accessed 10-Nov-2018]

    work page 2014

  2. [2]

    ERC-20 Token Stan- dard

    Fabian V ogelsteller and Vitalik Buterin. ERC-20 Token Stan- dard. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20. md, November 2015. [Online; accessed 2-Dec-2018]

    work page 2015

  3. [3]

    Attack vector on ERC20 API (approve/transferFrom methods) and suggested improvements

    Mikhail Vladimirov. Attack vector on ERC20 API (approve/transferFrom methods) and suggested improvements. https://github.com/ethereum/EIPs/issues/20#issuecomment- 263524729, November 2016. [Online; accessed 18-Dec-2018]

    work page 2016

  4. [4]

    Resolution on the EIP20 API Approve / TransferFrom multiple withdrawal attack #738

    Tom Hale. Resolution on the EIP20 API Approve / TransferFrom multiple withdrawal attack #738. https://github.com/ethereum/ EIPs/issues/738, October 2017. [Online; accessed 5-Dec-2018]

    work page 2017

  5. [5]

    Sok: Transparent dishonesty: front-running attacks on blockchain

    Shayan Eskandari, Seyedehmahsa Moosavi, and Jeremy Clark. Sok: Transparent dishonesty: front-running attacks on blockchain

    work page

  6. [6]

    https://rinkeby.etherscan.io/address/0x5d148c948c01e1a61e280c8 b2ac39fd49ee6d9c6 International Conference on Financial Cryptography and Data Security, 2019

    work page 2019

  7. [7]

    openzeppelin-solidity

    OpenZeppelin. openzeppelin-solidity. https://github.com/ OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ token/ERC20/ERC20.sol, December 2018. [Online; accessed 23-Dec-2018]

    work page 2018

  8. [8]

    ConsenSys/Tokens

    ConsenSys. ConsenSys/Tokens. https://github.com/ConsenSys/ Tokens/blob/fdf687c69d998266a95f15216b1955a4965a0a6d/ contracts/eip20/EIP20.sol, April 2018. [Online; accessed 24-Dec-2018]

    work page 2018

  9. [9]

    Compare-and-swap

    Wikipedia. Compare-and-swap. https://en.wikipedia.org/wiki/ Compare-and-swap, July 2018. [Online; accessed 10-Dec-2018]

    work page 2018

  10. [10]

    Measuring ethereum-based erc20 token networks

    Friedhelm Victor and Bianca Katharina L ¨uders. Measuring ethereum-based erc20 token networks. In International Confer- ence on Financial Cryptography and Data Security , 2019

    work page 2019

  11. [11]

    EIP 777: A New Advanced Token Standard

    Jacques Dafflon, Jordi Baylina, and Thomas Shababi. EIP 777: A New Advanced Token Standard. https://eips.ethereum.org/EIPS/ eip-777, November 2017. [Online; accessed 12-Jan-2019]

    work page 2017

  12. [12]

    Detecting Token Systems on Ethereum

    Michael Fr ¨owis, Andreas Fuchs, and Rainer B ¨ohme. Detecting token systems on ethereum. arXiv preprint arXiv:1811.11645 , 2018

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  13. [13]

    minime/con- tracts/MiniMeToken.sol

    Jordi Baylina, Danil Nemirovsky, and sophiii. minime/con- tracts/MiniMeToken.sol. https://github.com/Giveth/minime/blob/ master/contracts/MiniMeToken.sol#L225, December 2017. [On- line; accessed 23-Dec-2018]

    work page 2017

  14. [14]

    MonolithDAO/token

    Peter Vessenes. MonolithDAO/token. https://github.com/ MonolithDAO/token/blob/master/src/Token.sol, April 2017. [On- line; accessed 23-Dec-2018]

    work page 2017

  15. [15]

    flygoing/BackwardsCompatibleApprove.sol

    Nate Welch. flygoing/BackwardsCompatibleApprove.sol. https: //gist.github.com/flygoing/2956f0d3b5e662a44b83b8e4bec6cca6, February 2018. [Online; accessed 23-Dec-2018]

    work page 2018

  16. [16]

    outofgas comment

    outofgas. outofgas comment. https://github.com/ethereum/EIPs/ issues/738#issuecomment-373935913, March 2018. [Online; ac- cessed 25-Dec-2018]

    work page 2018

  17. [17]

    Vladimirov and D

    M. Vladimirov and D. Khovratovich. ERC20 API: An Attack Vector on Approve/TransferFrom Methods. https://docs.google.com/document/d/ 1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA jp- RLM/edit#heading=h.m9fhqynw2xvt, November 2016. [Online; accessed 25-Nov-2018]

    work page 2016

  18. [18]

    StandardToken.sol

    Enrique Chavez. StandardToken.sol. https://github.com/kindads/erc20-token/blob/ 40d796627a2edd6387bdeb9df71a8209367a7ee9/contracts/ zeppelin-solidity/contracts/token/StandardToken.sol, March 2018. [Online; accessed 23-Dec-2018]

    work page 2018

  19. [19]

    ERC223 token standard

    Dexaran. ERC223 token standard. https://github.com/ethereum/ EIPs/issues/223, March 2017. [Online; accessed 12-Jan-2019]

    work page 2017

  20. [20]

    transferAndCall Token Standard

    Steve Ellis. transferAndCall Token Standard. https://github.com/ ethereum/EIPs/issues/677, July 2017. [Online; accessed 12-Jan- 2019]

    work page 2017

  21. [21]

    ERC-721 Non-Fungible Token Standard

    William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs. ERC-721 Non-Fungible Token Standard. https://github. com/ethereum/EIPs/blob/master/EIPS/eip-721.md, January 2018. [Online; accessed 12-Jan-2019]

    work page 2018

  22. [22]

    ERC827 Token Standard (ERC20 Extension)

    Augusto Lemble. ERC827 Token Standard (ERC20 Extension). https://github.com/ethereum/eips/issues/827, January 2018. [On- line; accessed 12-Jan-2019]

    work page 2018

  23. [23]

    ERC-1155 Multi Token Standard

    Witek Radomski, Cooke Andrew, Philippe Castonguay, James Therien, and Eric Binet. ERC-1155 Multi Token Standard. https: //github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md, June

    work page

  24. [24]

    [Online; accessed 12-Jan-2019]

    work page 2019

  25. [25]

    Service-Friendly Token Standard

    Atkins Chang, Noel Bao, Jack Chu, Leo Chou, and Darren Goh. Service-Friendly Token Standard. https://github.com/fstnetwork/ EIPs/blob/master/EIPS/eip-1376.md, September 2018. [Online; accessed 12-Jan-2019]

    work page 2018

  26. [26]

    The ico phenomenon and its relationships with ethereum smart contract environment

    Gianni Fenu, Lodovica Marchesi, Michele Marchesi, and Roberto Tonelli. The ico phenomenon and its relationships with ethereum smart contract environment. In 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE) , pages 26–

    work page 2018