Liquidity Management

KeeperProxy.sol

Summary:
The _check function is meant to compare an internal market price (provided in the MarketPrices struct) against the Chainlink price feed value for a given token. Internal prices are assumed to use 30 decimals (as evidenced by ONE_USD in PerpetualVault), while Chainlink feeds use 8 decimals. To compare these values, the contract scales the provided price as follows:

Issue Path:
For a typical ERC20 token (say with 18 decimals) the calculation proceeds as follows:

• With token decimals = 18, the computed variable is
  decimals = 30 - 18 = 12.

• Then the scaling becomes
  price = price / 10 ** (12 - 8) = price / 10 ** 4.

If the internal price is meant to be 30 decimals (e.g. a price of $1 is represented as 1e30), converting it to an 8‑decimal value should require dividing by 10^(30–8) = 10^22. Instead, dividing by 10^4 leaves the scaled price roughly 10^(22–4) = 10^18 times too high.

Impact:
This mis‑scaling means that when _check compares the (incorrectly scaled) internal price against the Chainlink price (which is roughly on the order of 1e8 for a $1 asset), the computed absolute difference will be off by many orders of magnitude. The result is that even valid keeper calls will revert with "price offset too big" because the relative difference (multiplied by BPS and divided by the Chainlink price) far exceeds the configured threshold.

Recommendation:
Revise the scaling calculation. Because internal prices are standardized to 30 decimals regardless of the token’s native decimals, the conversion to 8 decimals should be independent of IERC20Meta(token).decimals(). For example, a correct conversion might be:

This change ensures that a price of 1e30 (representing $1) becomes 1e8, matching the Chainlink feed. If token-specific adjustments are needed, they must be introduced with a clear rationale and tested against the protocol’s invariant that all internal price data uses a uniform 30-decimal format.