Unlike withdraw()
, deposit()
assumes that the sender knows whether the position is closed or opened prior, because protocol is not refunding the executionFees
in case the position is closed.
But there can be a scenerio when the position is open
and a sender calls deposit()
with some msg.value
as executionFees
. When the transaction is still in txn pool , the keeper immediately calls run()
for closing the position to automate the foreseen risk. Since the keeper for sure prirotise this txn, it will get executed prior to the deposit()
.
Even though the withdraw()
takes care of this scenerio effectively the deposit() lacks this implementaion.
When the position is closed no refunding of the executionFees is made.
The depositor unintendly loses the execution fee paid and will never get refunded.
Manual
Implement like withdraw() by refunding the executionFees if the position is Closed.
Likelihood: Low, send a deposit with execution fees but a “run” keeper is made just before to close the position. Impact: Low/Medium, no refund of the execution fee, althought they were no need for them.
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.