User can call Premarkets::createTaker(...)
to fully or partially fill offers. But this can lead to a DOS if the first taker only fills the offer partially
Premarkets::createTaker(...)
does not update the offer
to Ongoing
considering that the as shown in the OfferStatus.sol
NATSPEC comment below
The problem is that,
contrary to the DOCs, orders do not get updated from Virgin
to Ongoing
when they get at least one trade
the check in the createTaker(...)
does not give room for ongoing orders to to be filled by takers and as such if the proper update is done from Virgin
to Ongoing
, as pointed out in this report, the remaing unfill points in the offer cannot be filled or by another taker and the
I am reporting this as a low because it is a missing update, however, if the update is done in the createTaker(...)
function and it is not
Manual review
Modify the createTaker(...)
function as shown below
The reason for severity for this issue and duplicates are very similar to issue #1164. However, in this case, the issues correctly identified that offer statuses should be updated accordingly based on points transaction (partially filled orders = `Ongoing`, fully filled orders = `Filled`). There is currently no impact on the tadle system since the above two statuses are unused, and while sementically `Virgin` status is not the correct status representing whether taker orders can be created agains maker offers, it can still be performed without a DoS. However, if we are basing it off of the correct status implementation (i.e. `Ongoing` phase appropriately updated when takers create taker offers), then the DoS will occur, essentially blocking any taker offers from being created by subsequent takers for partially filled orders. All issues that does not mention the DoS impact will be low severity, since they still correctly highlighted the wrong status accounting. All issues that mention the possible bypass of `Virgin` status is incorrect, because the usedPoint checks will always ensure points are filled only up to the points posted for offer as seen [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L180-L186). Note for downgrade to low severity: Agree with appeals and low severity, this is more of a status accounting error and does not have any impact, since the statuses consistently do not utilize a switch from Vigin to Ongoing/Filled and the protocol can function appropriately even without the use of such statuses (presuming other bugs are fixed), the DoS impact will not occur.
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.