Closed code423n4 closed 1 year ago
This is a typo in the pdf. The code is fine. We will update the whitepaper.
gte620v marked the issue as sponsor disputed
gte620v marked the issue as disagree with severity
we disagree with severity, but do not dispute the finding that the pdf has a typo.
I agree with the finding except that this should be rated as a QA. The issue results in unnecessary movement of bins not resulting in loss of funds.
Lines of code
https://github.com/code-423n4/2022-12-Stealth-Project/blob/fc8589d7d8c1d8488fd97ccc46e1ff11c8426ac2/maverick-v1/contracts/models/Pool.sol#L453 https://github.com/code-423n4/2022-12-Stealth-Project/blob/fc8589d7d8c1d8488fd97ccc46e1ff11c8426ac2/maverick-v1/contracts/models/Pool.sol#L470
Vulnerability details
Impact
Calculation of
startingTick
is wrong and unnecessary bins are moved (and possibly merged). This results in unnecessary stacking of bins and the protocol can suffer DOS later.Proof of Concept
According to the PDF document provided, the bins are moved according to the rules as below.
This is implemented in the function
_moveBins()
ofPool.sol
as belows.The implementation is calculating starting ticks inconsistent to the document. For example, for the first case the correct starting tick is supposed to be calculated as
min(startingTickInitial - 1, lastTwap)
but it's implemented asmin(startingTickInitial, lastTwap) - 1
(actual starting tick from L#460). Because $min(a,b)-1=min(a-1,b-1)<min(a-1,b)$, this results in moving an unnecessary bin. The similar glitch is on the line L#470 as well.Tools Used
Manual Review
Recommended Mitigation Steps
Fix as below.