Open code423n4 opened 2 years ago
The warden has identified an issue whereby newIbRatio
uses an incorrect startSupply
variable which is under-represented. As new tokens may be minted in handleFees()
, this will lead to an incorrect ibRatio
which is used in all other areas of the protocol. A lower ibRatio
causes pushUnderlying()
and pullUnderlying()
to be improperly accounted for. As a result, burning basket tokens will redeem a smaller amount of underlying tokens and minting basket tokens will require a smaller amount of underlying tokens.
This causes the protocol to leak value from all basket token holders but it does not allow assets to be stolen. As such, I think this is better put as a medium
severity issue.
Handle
0x0x0x
Vulnerability details
The function is implemented as follows:
When
handleFees
is called,totalSupply
andibRatio
changes accordingly, but fornewIbRatio
calculation tokens minted inhandleFees
is not included. Therefore,ibRatio
is calculated higher than it should be. This is dangerous, since last withdrawing user(s) lose their funds with this operation. In case this miscalculation happens more than once,newIbRatio
will increase the miscalculation even faster and can result in serious amount of funds missing. At each timeauctionBurn
is called, at least 1 day (auction duration) of fees result in this miscalculation. Furthermore, all critical logic of this contract is based onibRatio
, this behaviour can create serious miscalculations.Mitigation step
Rather than
uint256 newIbRatio = ibRatio * startSupply / (startSupply - amount);
A practical solution to this problem is calculating
newIbRatio
as follows: