Algo Ssstablecoinsss

AI First Flight #2
Beginner FriendlyDeFi
EXP
View results
Submission Details
Impact: low
Likelihood: high
Invalid

Missing dedicated mint, burn, and liquidation events weakens monitoring and incident response

Root + Impact

Description

  • critical state transitions should emit dedicated protocol events.

  • the engine emits collateral deposit and collateral redeem events, but not dedicated mint, burn, or liquidation events.

    Offchain systems must reconstruct debt transitions indirectly from token transfers and storage changes.

    This weakens monitoring, indexing, and incident response.

event CollateralDeposited:
user: indexed(address)
amount: indexed(uint256)
event CollateralRedeemed:
token: indexed(address)
amount_collateral: indexed(uint256)
_from: address
_to: address
// No dedicated DscMinted / DscBurned / Liquidated events

Risk

Likelihood:

  • Every mint, burn, and liquidation currently occurs without a dedicated engine event.

  • Monitoring systems will consistently lack direct observability.

Impact:

  • Security monitoring and accounting are harder.

  • Liquidation analysis and incident triage become slower and more error-prone.

Proof of Concept

/*
The engine currently emits events for collateral deposit and collateral redemption,
but it does not emit dedicated events for debt creation, debt repayment, or liquidation.
Example 1: user mints DSC
When a user calls mint_dsc():
- the engine increases user_to_dsc_minted[user]
- the stablecoin contract emits a generic ERC20 Transfer event from address(0) to user
- but the engine does not emit an event that directly says:
- which user’s debt increased
- by how much debt increased
- that the mint happened through the engine rather than some other privileged mint path
So an offchain indexer or monitoring system must infer protocol debt creation indirectly by:
- watching ERC20 Transfer events on the DSC token
- correlating them with engine calls
- reading storage if needed to confirm debt accounting
Example 2: user burns DSC
When a user calls burn_dsc():
- the engine reduces user_to_dsc_minted[user]
- the stablecoin may emit a burn-related Transfer event
- but the engine does not emit an event that cleanly links:
- whose debt was reduced
- who supplied the DSC
- the exact engine-side debt delta
Example 3: liquidation
When liquidation happens, this is the most important place for observability.
A monitoring system would want one event that clearly states:
- liquidator
- borrower
- collateral token
- debt amount covered
- collateral amount seized
- liquidation bonus effect
Instead, observers must reconstruct the action indirectly from:
- collateral transfer effects
- DSC burn behavior
- transaction input decoding
- storage diffs or post-state reads
That makes operational analysis harder.
In practice, this means:
- a dashboard cannot reliably index debt changes from events alone
- liquidation bots and risk monitors need more fragile offchain logic
- post-incident analysis takes longer because there is no single canonical event describing what happened
*/

Recommended Mitigation

+ event DscMinted:
+ user: indexed(address)
+ amount: uint256
+
+ event DscBurned:
+ on_behalf_of: indexed(address)
+ dsc_from: indexed(address)
+ amount: uint256
+
+ event Liquidation:
+ liquidator: indexed(address)
+ user: indexed(address)
+ collateral: indexed(address)
+ debt_covered: uint256
+ collateral_seized: uint256
+
+ emit DscMinted whenever _mint_dsc() succeeds
+ emit DscBurned whenever _burn_dsc() succeeds
+ emit Liquidation whenever liquidate() completes successfully
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 6 days 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!