Combining shorts can cause problems
The system does not permit minting the last shortRecord of a shorter (id = 254) since the last shortRecord of a shorter is reserved for special behavior. To counteract this behavior the shortRecord in position 254 is modified/blended anytime a new shortRecord would have been created with a shortRecordIdCounter greater than 254.
And the fillShortRecord function merges two shorts.
The problem is that the last short id may have been flagged.
When two shorts merge, the merge function uses the SHORT_MAX_ID and. So, the newly created short remained flagged.
Suppose the newly created short will be under minimum CR. In that case, it may get instantly liquidated, which is bad for the user because shorts are considered separated when it comes to liquidation.
Another problem is that when the two shorts merge, the merge function updates the short.updatedAt to the current time. A malicious user can open a new short to update the updateAt parameter so that his flagged short can't be liquidated.
For example :
Alice flags Bob's short.(id=254)(id=254)
Alice needs to wait for the first liquidation time to be able to liquidate Bob's short.
Bob sees this and creates a new short. Shorts merge and newly created short has an updated short.updatedAt.
Alice tries to liquidate Bob, but the transaction reverts because the time difference needs to be greater than the first liquidation time, but it's not.
Users may face unexpected liquidation(collateral loss).
Malicious users may escape primary liquidation.
Manual Review
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.