What Is the “Jaeden” ERC‑20 Approve Vulnerability and How to Prevent It?

What Is the “jaeden” Vulnerability?

The ERC‑20 standard’s approve function lets a token holder authorize a third‑party address to spend a specified amount of tokens, which the third party can then transfer using transferFrom. Because Ethereum miners prioritize transactions with higher gas fees, a user who tries to change an allowance can be front‑run by the previously authorized spender, resulting in the spender using both the old and the new allowance.

In the classic scenario, User A approves 100 tokens for User B, then later wants to reduce the allowance to 50 tokens. Before User A’s reduction transaction is mined, User B can submit a transaction with a higher gas price to transfer the full 100 tokens. If the miner includes User B’s transaction first, User B effectively spends the original 100 tokens and, after the allowance change is mined, can also spend the new 50 tokens, totaling 150 tokens.

Result 1: User A’s allowance update succeeds and User B can only spend the new 50 tokens.

Result 2: User B front‑runs the update, spends the original 100 tokens, and later also spends the new 50 tokens.

This double‑spending risk is what the “jaeden” issue describes.

How to Mitigate the “jaeden” Issue

Two practical countermeasures are recommended:

Before changing an allowance, first set it to zero with approve(address spender, uint256 amount). After the zero‑allowance transaction is confirmed and the spender has not used the previous allowance, set the new desired amount.

Prefer using the newer increaseApproval and decreaseApproval functions, which adjust the allowance incrementally and avoid the race condition inherent in resetting the allowance.

Why It May Not Be a Critical Vulnerability

Although the issue stems from Ethereum’s transaction‑ordering mechanism, it only manifests when a token holder actively changes an allowance while the spender is simultaneously trying to exploit the pending transaction. If users do not repeatedly modify allowances, the risk is minimal, and the mitigation techniques above effectively eliminate it.

Additional analysis of the mint function in many top‑500 token contracts shows that not every mint implementation is dangerous; some are essential for project functionality, though misuse can enable unlimited token creation.