Long token prices are wrongly validated against index token data.
In the KeeperProxy._validatePrice() function, the long token’s price is compared to prices.indexTokenPrice
instead of prices.longTokenPrice
, allowing deviations for the long token to go undetected.
The correct approach should be to validate the long token’s price using its dedicated price feed (prices.longTokenPrice.min/max
). Using the index token’s price for long token validation fails to catch deviations specific to the long token. As a result, if the long token’s price is manipulated or inaccurate, the keeper may operate on invalid data, potentially leading to mispriced trades.
Proof of Concept:-
Long token (e.g., BTC) and index token (e.g., ETH) with divergent prices.
ETH price drops 10%, BTC remains stable.
KeeperProxy uses ETH’s price for BTC validation.
Invalid liquidations of BTC positions occur.
Therefore, misaligned price references let keepers exploit arbitrage gaps or trigger unfair liquidations.
If the long token price deviates significantly from the true market value without detection, orders that depend on accurate price feeds (such as opening or closing positions) may be executed under wrong conditions. This misalignment risks under-collateralization, unexpected liquidations, or losses that can affect both traders and the overall protocol.
Manual Review
Adjust the code in _validatePrice()
function to use prices.longTokenPrice.min
and prices.longTokenPrice.max
for the long token.
Likelihood: None/Very Low, everytime the keeper send a price via run/runNextAction (sent by the Gamma keeper). Impact: Medium/High, does not check the longTokenPrice, it could go out of range. Keep in mind indexToken == longToken, an error from the keeper could be considered informational.
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.