MonoX Finance Exploit — Self-Swap Price Inflation (`swapExactTokenForToken(MONO, MONO)`)

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2021-11-Mono_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Mono_exp.sol.

Vulnerability classes: vuln/oracle/price-manipulation · vuln/logic/price-calculation

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. PoC: test/Mono_exp.sol. The vulnerable Monoswap/MonoXPool logic lives behind upgradeable proxies; only the proxy boilerplate was source-verified on-chain (see sources/ and the _meta.json files), so the implementation snippets below are the canonical MonoX swapIn pricing routine reconstructed and cross-checked against the on-chain events/state in the trace.

Key info#

TL;DR#

MonoX is a single-sided AMM: instead of paired reserves, every token gets its own pool whose value is measured against a virtual stablecoin, vCASH. Each pool stores a price and a tokenBalance; a swap from token A to token B uses A's price to value the input and B's price to value the output, then updates both prices so A gets cheaper and B gets more expensive.

The fatal flaw: swapExactTokenForToken does not forbid tokenIn == tokenOut. When the attacker swaps MONO for MONO, the routine first lowers MONO's price (the "sell" leg) and then raises it (the "buy" leg) — but because the buy-leg write happens last and uses the just-increased balance, each self-swap leaves MONO's stored price strictly higher than before. Iterating this a few dozen times inflates MONO's price by ~11 orders of magnitude.

Concretely in the PoC, MONO's pool price climbs from 5.218e18 (≈5.22 vCASH/MONO) to 5.277e29 (trace pools() returns). The attacker then swaps a dust amount of the now-astronomically-priced MONO into the shared MonoXPool vault and pulls out 4,000,000 USDC — the entire USDC pool — for essentially nothing.

The attacker's full sequence:

1. Buys ~80 MONO with 0.1 ETH to get an initial position.
2. Steals three real LPs' liquidity back to themselves via removeLiquidity (it has no msg.sender == provider check — the recipient is an arbitrary argument), which both nets the attacker MONO and shrinks the pool's MONO balance to a tiny seed (196,875,656 wei).
3. Adds that tiny seed as its own liquidity, then self-swaps MONO→MONO ~30+ times, each time ratcheting MONO's price higher.
4. Swaps ~0.000484 MONO into the vault to receive 4,000,000 USDC.

Background — how MonoX prices things#

MonoX (audited "single-sided" DEX) replaces Uniswap's reserve pairs with a per-token pool valued in vCASH, a virtual unit of account. The pools(token) mapping returns (interface.sol:2760-2775):

function pools(address) external view returns (
    uint256 pid,
    uint256 lastPoolValue,
    address token,
    uint8   status,
    uint112 vcashDebt,
    uint112 vcashCredit,
    uint112 tokenBalance,   // index 6 — the pool's token balance
    uint256 price,          // index 7 — vCASH price of one token
    uint256 createdAt
);

A swap is priced through getAmountOut(tokenIn, tokenOut, amountIn) (interface.sol:2720-2724), which returns (tokenInPrice, tokenOutPrice, amountOut, tradeVcashValue). The internal _swap/swapIn routine then:

1. values the input: tradeVcashValue = amountIn * tokenInPrice
2. computes amountOut = tradeVcashValue / tokenOutPrice (minus fees)
3. updates pools[tokenIn].price downward and pools[tokenIn].tokenBalance upward (you sold into it), and
4. updates pools[tokenOut].price upward and pools[tokenOut].tokenBalance downward (you bought from it).

The public entry point used in the attack (interface.sol:2847-2854):

function swapExactTokenForToken(
    address tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOutMin,
    address to,
    uint256 deadline
) external returns (uint256 amountOut);

All pools share one vault contract, MonoXPool (proxy 0x59653E37F8c491C3Be36e5DD4D503Ca32B5ab2f4), which actually custodies the ERC-20 balances and exposes safeTransferERC20Token (interface.sol:2958+). That shared vault is why a price distortion in the MONO pool lets the attacker walk away with USDC — the price is the only thing that gates how much of the shared vault you can extract.

On-chain state at the fork block (from the trace):

The vulnerable code#

The implementation is the canonical MonoX swapIn price-update logic. Reconstructed and verified against the trace's Swap events and pools() storage writes:

// MonoX Monoswap.swapIn (pricing core) — reconstructed
function _swap(address tokenIn, address tokenOut, uint amountIn, ... ) internal returns (uint amountOut) {
    // value the input using tokenIn's current price
    (uint tokenInPrice, uint tokenOutPrice, uint _amountOut, uint tradeVcashValue)
        = getAmountOut(tokenIn, tokenOut, amountIn);

    // pull amountIn into the shared MonoXPool vault
    _tokenIn(tokenIn, amountIn);

    // --- SELL LEG: tokenIn gets cheaper, its balance grows ---
    _updateTokenInfo(tokenIn,  tokenInPrice  * (BASE - x) / BASE, ... );   // price ↓

    // --- BUY  LEG: tokenOut gets more expensive, its balance shrinks ---
    _updateTokenInfo(tokenOut, tokenOutPrice * (BASE + y) / BASE, ... );   // price ↑

    // send amountOut from the shared vault to `to`
    _tokenOut(to, tokenOut, _amountOut);
    return _amountOut;
}

There is no guard rejecting tokenIn == tokenOut. When both are MONO:

• The sell leg writes pools[MONO].price = oldPrice * (BASE - x)/BASE (a small decrease), then
• The buy leg writes pools[MONO].price = thatValue * (BASE + y)/BASE (a larger increase),

and the buy-leg write lands last, so the net stored MONO price strictly increases each call. The loop also returns amountOut < amountIn to the caller (a fee-like haircut), but that is irrelevant — the attacker doesn't care about the MONO it receives, only about the persisted price.

This is exactly what the trace shows for the very first self-swap (output.txt, Swap event): amountIn = 196,875,655, amountOut = 79,706,446, swapVcashValue = 615,202,980. The MONO it gets back is smaller, but MONO's pool price rose.

Root cause — why it was possible#

Two independent design defects compose into a critical, near-zero-capital drain:

1. A token can be swapped for itself. swapExactTokenForToken(MONO, MONO, …) is accepted. The price-update math was written assuming tokenIn and tokenOut are different pools. When they are the same pool, the two sequential _updateTokenInfo writes operate on the same storage slot, and the second (price-up) write overwrites the first (price-down), so the invariant "a round-trip is value-neutral" is broken. Each self-swap is a free ratchet on pools[MONO].price.

   The trace makes the ratchet unmistakable — MONO's stored price per pools() read:

   After self-swap #	MONO price (vCASH)
   start	5.218e18
   ~24th	7.084e25
   ~25th	1.132e26
   ~late	1.976e28
   …	3.159e28 → 5.051e28 → …
   end of loop	5.277e29

   That is a ~10¹¹× inflation of MONO's price for ~0.1 ETH of starting capital.

2. The price is the only thing gating extraction from a shared vault. Because all tokens sit in one MonoXPool, and an output amount is tradeVcashValue / tokenOutPrice with tradeVcashValue = amountInMONO * priceMONO, an inflated priceMONO means a microscopic amount of MONO is "worth" millions of vCASH, which converts to millions of USDC out of the shared vault. The final swapTokenForExactToken(MONO, USDC, …) pulled only 484,115,476,049,367 wei (≈0.000484 MONO) to satisfy a request for 4,000,000 USDC (output.txt final Swap: amountIn 4.841e14, amountOut 4e12).

A contributing enabler used for setup:

3. removeLiquidity lets you specify an arbitrary recipient with no provider check. The PoC calls monoswap.removeLiquidity(MONO, balanceOf(user_i, 10), user_i, 0, 1) for three real LPs (test/Mono_exp.sol:54-66). The RemoveLiquidity events confirm large real positions were unwound (e.g. provider 0xab51…7355, tokenAmount = 99,940,741,365,832,694,596,828 ≈ 99,940 MONO, output.txt). This drains the MONO pool down to a tiny tokenBalance (196,875,656 wei after the attacker re-adds liquidity), which is what makes each self-swap move the price by a large multiplicative factor.

Preconditions#

• The MonoX router accepts swapExactTokenForToken with tokenIn == tokenOut (no equality guard).
• A token pool with a thin tokenBalance so each self-swap is a large relative trade (the PoC engineers this by yanking three LPs' liquidity, then re-adding a tiny 196,875,656-wei position via addLiquidity(MONO, 196_875_656, this) — test/Mono_exp.sol:45).
• The shared MonoXPool vault holds the target asset (here 4.04M USDC).
• Trivial seed capital: the PoC funds itself with WETH.deposit{value: address(this).balance}() and spends just 0.1 ETH on the initial MONO buy (test/Mono_exp.sol:40-41). This is flash-loanable; the live attacker did exactly this with no real capital at risk.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from the Swap/RemoveLiquidity/AddLiquidity events and the pools() reads in output.txt. The MONO pool is pid=10; the USDC pool is pid=2.

The self-swap ratchet in detail#

The Swap events show swapVcashValue (= amountIn × priceMONO) exploding geometrically, while MONO's stored price (read by pools() between swaps) climbs in lockstep:

Note the input amount of MONO and the price of MONO both grow — by the end one wei of MONO is worth a fortune, so the dust the attacker still holds (51.92 MONO total) is enormously over-valued.

The cash-out#

Right before the cash-out the USDC pool reads (output.txt pools(USDC)): pid=2, tokenBalance = 4,041,432,643,745 (4.04M USDC), price ≈ 9.239e29. The attacker calls:

monoswap.swapTokenForExactToken(
    MONO, USDC,
    mono.balanceOf(address(this)),  // 51.92 MONO as max-in
    4_000_000_000_000,              // exactly 4,000,000 USDC out (PoC's self-imposed cap)
    msg.sender, block.timestamp
);                                  // test/Mono_exp.sol:88-90

The trace's final Swap: amountIn = 484,115,476,049,367 (≈0.000484 MONO), amountOut = 4,000,000,000,000 (4,000,000 USDC). The recipient (msg.sender) ends holding 4e12 USDC, logged as Exploit completed, USDC Balance: 4000000000000.

Profit / loss accounting#

The 4,000,000-USDC figure is the PoC's hard-coded amountOut, not a ceiling: with priceMONO ≈ 5.3e29 the attacker could have requested the pool's entire 4,041,432-USDC balance (and in the live incident repeated this across every MonoX pool for ~$31M).

Diagrams#

Sequence of the attack#

Pool-price state evolution#

Why the self-swap is a one-way ratchet#

Why each magic number#

• 0.1 ETH initial buy: just enough to obtain a MONO position (≈80 MONO) so the attacker is an LP / holder; the real heavy lifting comes from the price ratchet, not capital.
• removeLiquidity(MONO, bal_i, user_i, …) ×3: unwinds three real LPs' positions (the recipient address is an arbitrary argument with no msg.sender ownership check), simultaneously (a) handing the attacker MONO and (b) shrinking the MONO pool's tokenBalance so each self-swap is a large relative move.
• addLiquidity(MONO, 196_875_656, this): re-seeds the pool to a controlled, tiny tokenBalance (196,875,656 wei) so the self-swap loop converges quickly to a huge price.
• swapExactTokenForToken(MONO, MONO, balance-1, 0, this) in a loop (PoC loops up to 55×): each call reads the current pool MONO balance and self-swaps almost all of it; amountOutMin = 0 so it never reverts on slippage. The loop drives price from 5.218e18 to 5.277e29.
• swapTokenForExactToken(MONO, USDC, balance, 4_000_000_000_000, …): requests exactly 4,000,000 USDC out; with MONO so over-priced, only 0.000484 MONO is needed to satisfy it.

Remediation#

1. Forbid tokenIn == tokenOut. The single highest-impact fix: every swap entry point (swapExactTokenForToken, swapTokenForExactToken, the ETH variants) must require(tokenIn != tokenOut). A swap of a token for itself has no legitimate meaning and must revert.
2. Make round-trips value-neutral. Even with distinct tokens, the price-update math must be derived so that buying and then immediately selling the same notional cannot increase a pool's stored price. Apply both legs against a single consistent snapshot and assert a no-free-lunch invariant (poolValue_after <= poolValue_before for fee-bearing swaps).
3. Add ownership checks to removeLiquidity. Liquidity must only be removable by (or on behalf of, via explicit approval) its actual provider. Allowing an arbitrary caller to unwind any LP's position with a chosen recipient is an independent access-control bug used here for setup.
4. Bound single-operation price impact. Reject any single swap that moves a pool's price by more than a small percentage; a swap that multiplies a price is a red flag and should revert.
5. Don't let one manipulable scalar gate a shared vault. Because all assets share one MonoXPool, pool prices should be sanity-checked against an external/oracle reference (or TWAP) before they are allowed to authorize large withdrawals of other tokens from the common vault.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under forge test's whole-project build):

_shared/run_poc.sh 2021-11-Mono_exp -vvvvv

• RPC: a mainnet archive endpoint is required (the fork pins block 13,715,025, Nov 2021). Public pruned RPCs will fail with header not found / missing trie node.
• Result: [PASS] testExploit() with Exploit completed, USDC Balance: 4000000000000 (4,000,000 USDC).

Expected tail:

Ran 1 test for test/Mono_exp.sol:ContractTest
[PASS] testExploit() (gas: 3923859)
Logs:
  WETH Balance: 79228162514264337593543950335
  MonoToken Balance: 79986094311542621010
  Exploit completed, USDC Balance: 4000000000000

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 20.49s (18.94s CPU time)

Reference: MonoX Finance exploit, Ethereum + Polygon, ~$31M, Nov 30 2021. SlowMist / Rekt / DeFiHackLabs. The root cause — a token swappable for itself driving a one-way price ratchet — is the canonical example of a self-referential AMM-pricing bug.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2021-11-Mono_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Mono_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "MonoX Finance Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.