QuantAMM
QuantAMM
49,600 OP
View results
Previous Next
Submission Details
Severity: low
Invalid

Missing Timestamp Update In Manual Weight Setting Functions Enables MEV Sandwich Attacks

huntoor

Summary

The setWeightsManually() function fails to update lastPoolUpdateRun timestamp, allowing attackers to sandwich manual weight updates with performUpdate() calls to profit from price differences.

Vulnerability Details

When trusted accounts (pool manager or quantammAdmin) call setWeightsManually(), the function updates weights but doesn't update lastPoolUpdateRun. This allows:

  1. Attacker observes pending manual weight update and two options are available

    1. He sandwich it immediately in the same txn (current Prices returned by oracles favor the attack)

    2. He waits some blocks till the attack gets profitable and prices spike very high

  2. Buys tokens from pool in multiple small trades (bypassing maxTradeSizeRatio)

  3. Calls performUpdate() which changes weights again

  4. Sells tokens at better rates in same transaction

The block multiplier mechanism reduces but doesn't eliminate the profit opportunity since weights can still change significantly between the manual update and forced update.

The root cause is in setWeightsManually() sepcifically

function setWeightsManually() {
// Missing: poolRuleSettings[_pool].timingSettings.lastPoolUpdateRun update
}
​
function performUpdate() {
// Can be called immediately after manual update
// Since lastPoolUpdateRun wasn't updated
}

Impact

  • Financial loss through MEV sandwich attacks

  • Manipulation of pool weights beyond intended changes

  • Bypass one of the protective mechanism against volatile price changes (updateInterval)

Tools Used

Manual review

Recommendations

Add timestamp update in setWeightsManually():

function setWeightsManually(...) {
// Existing code...
poolRuleSettings[_poolAddress].timingSettings.lastPoolUpdateRun = uint40(block.timestamp);
IQuantAMMWeightedPool(_poolAddress).setWeights(...);
}
Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas / Admin is trusted / Pool creation is trusted / User mistake / Suppositions

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Support

FAQs

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

Give us feedback!