In the DeliveryPlace.settleAskMaker
function, it does not check the offer
is makerInfo.originOffer
and it refunds the collateral for settled points.
Thus, in Turbo
mode, settling listed ask offer which is not makerInfo.originOffer
also refunds collateral.
In Turbo
mode, listing ask offer does not require collateral.
As a result, not provided collateral are refunded and this causes the protocol's loss of funds.
In the DeliveryPlace.settleAskMaker
function, collateral for settled points are refunded from L301.
In Turbo
mode, collaterals are provided only for makerInfo.originOffer
, not for listed offer whith is not makerInfo.originOffer
.
Let's assume that makerInfo.offerSettleType
is Turbo
and user tries to settle the listed ask offer.
If offer.authority
tries to settle the offer, the DeliveryPlace.settleAskMaker
function refunds the collateral which is not provided by authority.
This causes the protocol's loss of funds.
Manual Review
It is recommended to change the code as following:
Valid high severity, this allows resellers listing offers via `listOffer/relistOffer` to game the system. Based on the inherent design of Turbo mode not requiring takers making ask offers for the original maker offer to deposit collateral, the wrong refund of collateral to takers even when they did not deposit collateral due to turbo mode during settleAskMaker allows possible draining of pools.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.