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

CollateralDeposited event omits the token address, breaking off-chain accounting (asymmetric with CollateralRedeemed)

bytethebuilder

Description

When a user deposits collateral, _deposit_collateral emits CollateralDeposited, but that event only carries the depositor and the amount — it does not include which collateral token was deposited. The protocol accepts multiple collateral tokens (WETH, WBTC, and anything a fork swaps in), so an off-chain consumer (indexer, accounting dashboard, liquidation bot) reading these logs cannot tell which asset a given deposit was for. Notably this is asymmetric with the sibling CollateralRedeemed event, which does include the token, so deposits and withdrawals cannot be reconciled per-asset from events alone.

# @> event is missing the token field
event CollateralDeposited:
user: indexed(address)
amount: indexed(uint256)
​
event CollateralRedeemed:
token: indexed(address) # <-- redeem HAS the token...
amount_collateral: indexed(uint256)
_from: address
_to: address
​
def _deposit_collateral(token_collateral_address: address, amount_collateral: uint256):
...
self.user_to_token_address_to_amount_deposited[msg.sender][token_collateral_address] += amount_collateral
log CollateralDeposited(msg.sender, amount_collateral) # @> token_collateral_address dropped
...

Risk

Likelihood: Low — the event fires on every deposit, but the consequence is limited to off-chain observability, not on-chain fund safety.
Impact: Low — indexers/monitoring cannot attribute a deposit to a specific collateral token from logs, and deposit/redeem flows can't be reconciled per asset. No funds are at risk, but accounting/monitoring tooling is silently wrong for multi-collateral deployments.

Proof of Concept

The test decodes the emitted CollateralDeposited log and shows it has no field identifying the token, even though two different collaterals (WETH, WBTC) are supported. Using titanoboa/pytest:

def test_deposit_event_omits_token(dsce, weth, wbtc, user):
# user deposits WETH
weth.mint(user, 1 * 10**18)
with boa.env.prank(user):
weth.approve(dsce.address, 1 * 10**18)
dsce.deposit_collateral(weth.address, 1 * 10**18)
​
logs = dsce.get_logs()
dep = [l for l in logs if type(l).__name__ == "CollateralDeposited"][0]
​
# The event exposes only user + amount; there is no token attribute.
assert hasattr(dep, "user")
assert hasattr(dep, "amount")
assert not hasattr(dep, "token") # <-- cannot tell WETH from WBTC off-chain

The failing-by-design assertion is not hasattr(dep, "token"): the deposit log carries no token, so a consumer watching deposits across WETH and WBTC cannot attribute the amount to either asset.

Recommended Mitigation

Add the token to the event and emit it, mirroring CollateralRedeemed.

event CollateralDeposited:
user: indexed(address)
token: indexed(address) # add the collateral token
amount: indexed(uint256)
​
def _deposit_collateral(token_collateral_address: address, amount_collateral: uint256):
assert amount_collateral > 0, "DSCEngine_NeedsMoreThanZero"
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, token_collateral_address, amount_collateral) # include token
success: bool = extcall IERC20(token_collateral_address).transferFrom(msg.sender, self, amount_collateral)
assert success, "DSCEngine_TransferFailed"

Why this fixes it: the deposit log now identifies the exact collateral token, so off-chain indexers can attribute each deposit to the right asset and reconcile it against CollateralRedeemed (which already carries the token). Indexing token lets consumers filter the log stream by collateral. This makes per-asset accounting and monitoring correct for every supported and forked collateral type.

Updates

Lead Judging Commences

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