The function LiquidationBranch::checkLiquidatableAccounts() puts zeros in the non‐liquidatable accounts. It creates the array as:
new uint128[]((upperBound - lowerBound) + 1)
It then iterates from i = 0 to upperBound - lowerBound (inclusive), storing a trading account ID only if the account is liquidatable. For non‐liquidatable accounts, it “continues” without writing a value (zeros -since account IDs start at 1).
For example:
If only account 101 (out of bounds 100–110) is liquidatable, the returned array might be:
[0, 101, 0, 0, 0, 0, 0, 0, 0, 0, 0]
and the caller must watch out to filter the zeros.
This desing forces the caller to watch out and put conditions for the zeros hence error prone.
Also, there is no internal check that lowerBound <= upperBound (though this is handled in the caller).
This is error prone, and the caller has to watch out for the zeros in array positions + more gas. It could simply have handled it right at that same loop. It makes the caller to have more checks and code like upkeepNeeded.
This is very large contract and If its is upgraded, this could be missed in some of nested dirs/files.
Manual review
In the loop, for each account in the range, we:
Check if it has active positions.
Load its trading account data.
Compute its maintenance margin and margin balance.
Check if it meets the liquidatability condition.
If so, store the account ID at the current index (count) in the array and increment count.
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.