TheStandard.io Exploit — SmartVault `swap()` with Zero Slippage Protection Through an Attacker-Controlled Pool

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: 2023-11-TheStandard_io_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/TheStandard_io_exp.sol.

Vulnerability classes: vuln/defi/slippage · vuln/oracle/price-manipulation

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 all compile under one forge build, so this one was extracted). Full verbose trace: output.txt. Verified on-chain artifacts downloaded under sources/ (the in-scope contracts — SmartVaultManagerV2, SmartVaultV2, EUROs, and the pricing calculator — are deployed behind proxies whose implementation source Etherscan did not return as a standalone file, so the SmartVault logic below is reconstructed from the verified execution trace; the attacker-created Uniswap V3 pool is fully verified at sources/UniswapV3Pool_29046f).

Key info#

TL;DR#

SmartVaultV2 lets a vault owner mint EUROs against deposited collateral, and also exposes a convenience swap() that swaps one of the vault's collateral assets for another through Uniswap V3. The swap is executed with the vault's own tokens but the protocol passes amountOutMinimum = 0 to the router (output.txt:4855) — it does not compute a fair minimum output from its own Chainlink price feeds. It also lets the swap route through any fee-tier pool that exists for the token pair, including a pool the attacker created moments earlier.

So the attacker:

1. Flash-borrows 10 WBTC and creates a brand-new WBTC/PAXG 0.3% Uniswap V3 pool, initializing it at a deliberately skewed price and seeding a position with a dust amount of WBTC (10 sats) plus 100 PAXG (output.txt:1655, 4729).
2. Opens a SmartVault, deposits the 10 WBTC as collateral, and mints 290,000 EUROs — this part is honestly collateralized (10 WBTC ≈ $350,103 at the Chainlink price; 290k EUROs ≈ $311k, well inside the 110% rule).
3. Calls the vault's swap(WBTC → PAXG, 10 WBTC). The vault approves the router and does exactInputSingle(..., amountOutMinimum: 0) against the attacker's own pool. The vault hands over 9.95 WBTC and gets back ~99.99 PAXG (worth ~$200) — a ~99.9% value loss it never checks.
4. The 9.95 WBTC is now sitting in the attacker's pool. The attacker decreaseLiquidity + collects its own LP position and walks away with 9.92 WBTC back, plus the 290,000 EUROs it minted.
5. Repays the 10 WBTC flash loan and keeps the EUROs (converting 10k of them to ~10,435 USDC for liquidity, netting 280,000 EUROs + 8,512.23 USDC by the end of the PoC).

Net effect: the attacker minted 290k EUROs against collateral and then immediately extracted that same collateral right back out of the vault through a swap with zero slippage protection. The debt (290k EUROs) is left backed by ~100 PAXG of dust. The protocol is left holding worthless collateral and a fully-circulating, unbacked stablecoin supply.

Background — what SmartVault does#

The Standard (TheStandard.io) is a EUR-pegged CDP/stablecoin protocol. Users mint a per-user SmartVault through SmartVaultManagerV2.mint(), deposit accepted collateral (WBTC, WETH/ETH, ARB, LINK, PAXG), and mint EUROs against it. Key vault mechanics observed in the trace:

• Minting (SmartVaultV2.mint): values all collateral via a TokenManager/calculator (tokenToEur) that uses Chainlink feeds (e.g. BTC/USD 0xd0C7101…, ETH/USD 0x639Fe6…, with an EUR/USD conversion 0xA14d53…), enforces a collateralRate of 110,000 / 100,000 = 110% (output.txt:2510, 4660-4690), and charges a mintFeeRate of 500/100000 = 0.5%. This part is sound — the collateral pricing is not what is manipulated.
• Swapping (SmartVaultV2.swap): a convenience function so a vault can rebalance collateral without first withdrawing. It charges a swapFeeRate of 500/100000 = 0.5% (sent to protocol), approves the Uniswap V3 SwapRouter (0xE592…), and performs exactInputSingle. The minimum output it requests is 0. (output.txt:4793-4905)

The on-chain parameters at the fork block (read from the trace):

The whole exploit lives in the gap between two facts: collateral is valued with Chainlink, but the swap() output is not validated against Chainlink. The attacker swaps at a price the vault never sanity-checks.

The vulnerable code#

The vault implementation source was not returned by Etherscan as a standalone file (it sits behind the SmartVaultManagerV2 proxy and per-vault beacon clones at runtime). The exact router call is nonetheless fully visible in the verified trace. SmartVaultV2.swap() reduces to:

// SmartVaultV2.swap(bytes32 _inToken, bytes32 _outToken, uint256 _amount)
function swap(bytes32 _inToken, bytes32 _outToken, uint256 _amount) external onlyOwner {
    uint256 swapFee = (_amount * swapFeeRate) / HUNDRED_PC;      // 0.5% fee skimmed to protocol
    address inAddr  = getTokenAddressFor(_inToken);
    address outAddr = getTokenAddressFor(_outToken);

    IERC20(inAddr).safeTransfer(protocol, swapFee);              // 5,000,000 sats -> protocol
    IERC20(inAddr).safeApprove(swapRouter, _amount - swapFee);   // 995,000,000 sats approved

    ISwapRouter.ExactInputSingleParams memory params =
        ISwapRouter.ExactInputSingleParams({
            tokenIn:           inAddr,
            tokenOut:          outAddr,
            fee:               3000,                  // any existing pool fee tier works
            recipient:         address(this),
            deadline:          block.timestamp,
            amountIn:          _amount - swapFee,
            amountOutMinimum:  0,                     // ⚠️ NO SLIPPAGE PROTECTION
            sqrtPriceLimitX96: 0                      // ⚠️ NO PRICE LIMIT
        });
    ISwapRouter(swapRouter).exactInputSingle(params);
    // ⚠️ no post-swap solvency / value check: the vault never asserts the EUR value
    //    received is close to the EUR value sent.
}

The concrete router call captured in the trace (output.txt:4855):

SwapRouter::exactInputSingle(ExactInputSingleParams({
  tokenIn:  0x2f2a…5B0f (WBTC),
  tokenOut: 0xfEb4…8429 (PAXG),
  fee: 3000,
  recipient: 0x2E9f…99Cd (the attacker's SmartVault),
  amountIn: 995000000,            // 9.95 WBTC after the 0.5% fee
  amountOutMinimum: 0,            // ← the bug
  sqrtPriceLimitX96: 0
}))
  └─ 0x29046f…855b8d::swap(...)   // routes into the ATTACKER-CREATED pool
       PAXG out: 99,999,998,982   // ≈ 99.99 PAXG (~$200) for 9.95 WBTC (~$348k)

Two independent failures compose:

1. amountOutMinimum = 0 — the vault accepts any output, including ~0.06% of fair value.
2. No restriction on the swap venue — the router uses whatever WBTC/PAXG 0.3% pool exists. The attacker simply created that pool one call earlier and seeded it at an arbitrary price, so it is the price oracle for the swap. (See createAndInitializePoolIfNecessary at output.txt:1655: sqrtPriceX96 = 7,922,816,251,426,433,759,354,395,033,600,000, tick 230270.)

Root cause — why it was possible#

A CDP protocol that already prices collateral with Chainlink has all the information it needs to compute a fair amountOutMinimum. Instead, SmartVaultV2.swap() outsources price discovery to a Uniswap V3 pool that the caller fully controls, and asks for no minimum output. Concretely:

The vault owns ~$348k of WBTC, calls exactInputSingle with amountOutMinimum = 0 into a pool the attacker initialized at a junk price, and receives ~$200 of PAXG. Because the recipient of the swap output is the same vault but the liquidity that absorbed the WBTC is the attacker's LP position, the attacker recovers the WBTC by withdrawing its own liquidity. The vault is left with dust, yet its EUROs debt is unchanged.

The design defects that compose into a critical bug:

1. No slippage floor. amountOutMinimum is hard-coded to 0. The vault never compares valueOut_in_EUR against valueIn_in_EUR. A single sanity check (require(amountOut >= calculator.tokenToEur(inToken, amountIn) * (1 - maxSlippage))) would have reverted.
2. Caller-chosen, manipulable swap venue. The router resolves the pool from the (tokenIn, tokenOut, fee) tuple. Anyone can createAndInitializePoolIfNecessary for that tuple at an arbitrary price and seed dust liquidity — instantly becoming the price source for the vault's swap.
3. Swap bypasses the solvency model. mint() carefully enforces 110% collateralization, but swap() can silently convert $348k of collateral into $200 of collateral with no re-check of vault health. The debt (290k EUROs) survives; the backing evaporates.
4. The output recipient and the liquidity owner are different parties. Because the WBTC the vault "spent" lands in the attacker's own LP range, the attacker reclaims it via decreaseLiquidity + collect. The "swap" is effectively a free transfer of the vault's WBTC to the attacker, laundered through a pool.

Preconditions#

• The vault must hold an _inToken collateral balance to swap (here, freshly deposited 10 WBTC). The attacker funds this with a flash loan.
• An accepted-token pair must be swappable; the attacker manufactures the venue with createAndInitializePoolIfNecessary(WBTC, PAXG, 3000, skewedPrice) and a dust LP position. PAXG was chosen because it is an accepted collateral with an existing path back to USDC for cash-out, and because the attacker controls the only meaningful liquidity in the freshly-created pool.
• Working capital: 10 WBTC for the flash loan (fee 500,001 sats ≈ 0.005 WBTC) plus 100 PAXG seed. Both are recovered intra-transaction, so the attack is flash-loanable with near-zero net capital.

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

All figures are taken directly from the events/returns in output.txt. WBTC has 8 decimals (1 WBTC = 1e8 sats), PAXG 18 decimals, EUROs 18 decimals.

Why "9.95 WBTC out, 99.99 PAXG in" is not a real trade#

Because the WBTC/PAXG pool was created and price-initialized by the attacker one call earlier (step 1) and held only the attacker's dust liquidity (step 6), the vault's exactInputSingle simply pushed 9.95 WBTC into the attacker's own concentrated-liquidity range and pulled out whatever PAXG the attacker had parked there (~100 PAXG). The "price" was whatever the attacker chose. Then in steps 8–9 the attacker withdrew that same liquidity range and reclaimed 9.92 of the 9.95 WBTC. The vault was left holding ~100 PAXG of dust against an unchanged 290k EUROs debt.

Profit / loss accounting#

The attacker ends up roughly WBTC-flat (collateral recovered ≈ collateral deposited, modulo flash fee and the 0.5%×2 protocol fees, which are covered by the EUROs→USDC conversion) and pockets the entire 290,000 EUROs of freshly-minted, now-unbacked stablecoin. Public reporting put the loss at ~$290K. The protocol's loss is the unbacked EUROs supply plus the worthless ~100 PAXG left in the vault.

Diagrams#

Sequence of the attack#

Value flow — collateral is laundered out, debt stays behind#

The flaw inside SmartVaultV2.swap#

Why each magic number#

• Flash loan = 10 WBTC (1,000,000,010 sats): sized so the vault can take a 10-WBTC collateral deposit large enough to mint a meaningful 290,000 EUROs while staying under the 110% gate.
• Mint = 290,000 EUROs: 10 WBTC ≈ $350,103 ≈ 326,560 EUR; at 110% collateral the cap is ~296,873 EUR. 290k sits just under the cap, maximizing extraction while passing the check.
• Pool init price (sqrtPriceX96 = 7.922e33, tick 230270): an arbitrary, attacker-chosen price. Combined with the dust LP position, it makes the vault's 9.95-WBTC exactInputSingle return only ~100 PAXG — the attacker keeps whatever WBTC the vault pushed in.
• LP seed = 10 sats WBTC + 100 PAXG: the minimum liquidity needed for the pool to absorb the vault's WBTC into a range the attacker owns and can later withdraw.
• amountOutMinimum = 0: not the attacker's choice — it is the vault's. This single protocol-controlled parameter is the entire vulnerability.

Remediation#

1. Enforce a fair-value slippage floor in swap(). The protocol already prices every collateral in EUR via Chainlink. Compute the expected output and require it:
   SOLIDITYCopy

   uint256 valueInEur  = calculator.tokenToEur(inToken, amountIn);
   uint256 minOut      = calculator.eurToToken(outToken, valueInEur) * (HUNDRED_PC - maxSlippage) / HUNDRED_PC;
   params.amountOutMinimum = minOut;   // never 0
   

   This alone reverts the attack: 100 PAXG is nowhere near the EUR value of 9.95 WBTC.
2. Re-check vault solvency after the swap. After any operation that changes collateral composition, assert the vault still meets the collateralRate against its EUROs debt. A swap that drops collateral value by 99% must revert.
3. Constrain the swap venue. Do not let the router silently resolve an arbitrary, possibly attacker-created pool. Require a minimum pool age/liquidity, use a canonical fee tier with deep liquidity, or route only through a vetted pool/aggregator; ideally combine with a Chainlink-derived sqrtPriceLimitX96.
4. Use a price-impact-aware router path or TWAP guard. A swap of $350k into a freshly created pool should be flagged by a max-price-impact check derived from the Chainlink reference price.
5. Treat amountOutMinimum = 0 as a banned pattern. Any integration that swaps protocol-owned funds must pass a non-zero, oracle-derived minimum.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo does not build all PoCs together under one forge build):

_shared/run_poc.sh 2023-11-TheStandard_io_exp --mt testExploit -vvvvv

• RPC: an Arbitrum archive endpoint is required (fork block 147,817,765). Configure the arbitrum RPC alias in foundry.toml.
• Result: [PASS] testExploit(). Final attacker holdings logged as 8,512.23 USDC and 280,000 EUROs.

Expected tail (output.txt:1571-1577):

Ran 1 test for test/TheStandard_io_exp.sol:ContractTest
[PASS] testExploit() (gas: 14851392)
  Attacker USDC balance before exploit: 0.000000
  Attacker EURO balance before exploit: 0.000000000000000000
  Attacker USDC balance after exploit: 8512.226242
  Attacker EURO balance after exploit: 280000.000000000000000000

References:

• Phalcon: https://twitter.com/Phalcon_xyz/status/1721807569222549518
• CertiK Alert: https://twitter.com/CertiKAlert/status/1721839125836321195
• Attack tx: https://explorer.phalcon.xyz/tx/arbitrum/0x51293c1155a1d33d8fc9389721362044c3a67e0ac732b3a6ec7661d47b03df9f

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-11-TheStandard_io_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: TheStandard_io_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "TheStandard.io 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.