Algo Ssstablecoinsss
AI First Flight #2
Beginner FriendlyDeFi
EXP
View results
Previous Next
Submission Details
Impact: medium
Likelihood: low
Invalid

First Depositor Inflation Attack

lordbolton

Root + Impact

The protocol tracks individual user collateral balances independently without share-based accounting, but a malicious first depositor could exploit rounding by depositing minimal collateral then donating tokens directly to the contract, causing subsequent small deposits to round to zero in USD value calculations.

Description

  • The protocol calculates collateral USD value by multiplying token amounts by oracle prices, with integer division causing small amounts to round down in conversions.

  • A first depositor can deposit 1 wei of collateral, then transfer large amounts directly to the contract (bypassing deposit function), inflating the "value per wei" to cause subsequent users' small deposits to round to nearly zero collateral value.

# dsc_engine.vy lines 310-315
@internal
@view
def _get_usd_value(token: address, amount: uint256) -> uint256:
price_feed: AggregatorV3Interface = AggregatorV3Interface(
self.token_address_to_price_feed[token]
)
# ... get price ...
return (
(convert(price, uint256) * ADDITIONAL_FEED_PRECISION) * amount
) // PRECISION # @> Division causes rounding, small amounts lose precision
​
# No protection against direct token transfers inflating contract balance
# No minimum deposit amount enforced

Risk

Likelihood:

  • A malicious actor monitors mempool for first deployment and races to become the first depositor with 1 wei collateral.

  • Attacker donates significant collateral amount directly via transfer() to contract address, bypassing accounting logic.

Impact:

  • Subsequent users depositing small amounts (< 1000 tokens) suffer from extreme rounding losses where their collateral value rounds to nearly zero USD.

  • Attack requires front-running deployment and donating value, making it economically viable only for high-value protocols or as griefing attack.

Proof of Concept

# Attacker becomes first depositor
with boa.env.prank(attacker):
# Step 1: Deposit minimal amount (1 wei)
weth.approve(dsce, 1)
dsce.deposit_collateral(weth, 1) # Records: 1 wei
# Step 2: Donate large amount directly (bypasses deposit accounting)
weth.transfer(dsce.address, 10_000 * 10**18) # 10,000 ETH donation
# Contract now holds: 10,000.000000000000000001 ETH
# But only 1 wei is recorded in accounting
​
# Victim tries to deposit small amount
with boa.env.prank(victim):
# Deposit 0.001 ETH (1000000000000000 wei)
weth.approve(dsce, 0.001 * 10**18)
dsce.deposit_collateral(weth, 0.001 * 10**18)
# Calculate USD value:
# 0.001 ETH * $2000 = $2
# With precision: 2 * 10**18
# Division by PRECISION: rounds normally
# However, if attacker inflated per-share value in share-based system:
# shares = amount * totalShares / totalAssets
# shares = 0.001 * 1 / 10000 = 0.0000001 → rounds to 0 shares
# (This is for share-based systems like ERC4626)
​
# Note: Current DSC Engine is NOT share-based, so this attack is LIMITED
# Attack mainly affects share-based vaults, not this direct accounting
# But donation still wastes attacker's funds with no clear profit
​
# Real impact: Grief attack where attacker donates 10K ETH to slightly
# affect rounding for tiny deposits (economically irrational)

Recommended Mitigation

# dsc_engine.vy
+MIN_COLLATERAL_AMOUNT: constant(uint256) = 1000 * 10**18 # 1000 tokens minimum
​
@internal
def _deposit_collateral(token_collateral_address: address, amount_collateral: uint256):
- assert amount_collateral > 0, "DSCEngine_NeedsMoreThanZero"
+ assert amount_collateral >= MIN_COLLATERAL_AMOUNT, "DSCEngine_MinimumDepositNotMet"
assert self.token_address_to_price_feed[token_collateral_address] != empty(address),
"DSCEngine__TokenNotAllowed"
self.user_to_token_address_to_amount_deposited[msg.sender][
token_collateral_address
] += amount_collateral
log CollateralDeposited(msg.sender, amount_collateral)
success: bool = extcall IERC20(token_collateral_address).transferFrom(
msg.sender, self, amount_collateral
)
assert success, "DSCEngine_TransferFailed"

Note: This vulnerability has LOW severity for this protocol because:

  1. Not a share-based vault (direct balance tracking)

  2. Attack requires donating significant value with no profit mechanism

  3. Victims can just deposit larger amounts (> 1000 tokens)

  4. Economically irrational for attacker

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 3 hours ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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

Give us feedback!