An attacker can front-run the burn()
function if the amount passed as an argument is substantial, and then back-run the transaction to call distributeFees()
in the LiquidationPoolManager
.
Bob, Alice, and John are borrowers. They have minted 500,000 euros, 1,000,000 euros, and 500,000 euros, respectively. Each of them burns their euros simultaneously. Considering the current burn fee is 0.5%, and the total amount burned is 2,000,000 euros, the quantity sent to the LiquidationPoolManager
will be 10,000 euros. A malicious actor could front-run the euro transfers and call the increasePosition()
function in the LiquidationPool
.
He can then back-run these transactions by calling distributeFees()
in the LiquidationPoolManager
to collect fees. The malicious actor only needs to wait for a day to receive the fees from the burns.
The issue here is that the LiquidationPool
distribute fees to all the TST holders and not only the ones that have a position.
A malicious actor can take a part of the fees without taking any risk and take a part of the TST holders' fees without taking any risk.
Manual review
Refactor in the Liquidation Pool the distributeFees() and getTstTotal()(L55-L62)
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.