Liquidity Management

Where It Happens

Inside _check(...):

Potential pitfalls:

1. Hard-coded Logic for 30 - token.decimals()

   • The contract expects that the GMX system, or the tokens it deals with, always have decimals in the range [0..30]. If a token uses an unexpected decimals value (e.g., 31 or a negative number for extremely exotic reasons), 30 - IERC20Meta(token).decimals() can underflow or produce a nonsensical shift.

2. Not All Tokens Implement IERC20Meta(token).decimals()

   • ERC20’s original standard does not require an on-chain decimals() method. Some tokens or older tokens might not implement it, causing that call to revert or return 0 incorrectly. In that scenario, _check can revert.

3. (decimals - 8) Underflow

   • If token.decimals() is < 8, (decimals - 8) is negative, so 10 ** (decimals - 8) reverts or produces the wrong shift. For instance, if token.decimals() == 6, then (decimals - 8) = (30 - 6) - 8 = 16, which works. But if token.decimals() == 10, then (30 - 10) - 8 = 12, which might be correct. However, the code’s comment says “Chainlink price decimals is always 8,” but the formula might be inconsistent if token.decimals() < 8.

Impact

• Reverts / Inaccurate Price Validation

  • If a token has fewer than 8 decimals (say 6 decimals) or more than 18 decimals, the shift logic can become inaccurate, leading to overzealous reverts (“price offset too big”) or allowing too large a price difference.

• Possible Underflow

  • If IERC20Meta(token).decimals() is > 30 or less than 8, the expression 10 ** (decimals - 8) can underflow or yield zero.

Why the attention to this issue

1. Non-Standard Decimals: Many tokens follow 18 decimals, but stablecoins can have 6 decimals, bridging tokens might have 8 decimals, etc. If IERC20Meta(token).decimals() is not in the expected range, _check() can revert or do inaccurate scaling.

2. Not All Tokens Implement decimals(): The contract forcibly calls IERC20Meta(token).decimals(), which might revert for older tokens or custom tokens that do not implement an interface for decimals.

Recommended Mitigations

1. Explicit Range Check

   • Validate that IERC20Meta(token).decimals() is in a safe range, for example [6..18], or whatever range you actually support. Revert if it’s outside your design’s scope.

2. Adjust Logic for Low-Decimals Tokens

   • If a token has fewer than 8 decimals, (decimals - 8) is negative, so you might do something like:

     uint256 tokenDecimals = IERC20Meta(token).decimals();

     require(tokenDecimals <= 30, "Unsupported token decimals");

     uint256 shift = 0;

     // If tokenDecimals < 8, skip or set shift = 0

     // If tokenDecimals > 8, shift = ...

     ​

   • Provide a clear branch for stablecoins with 6 decimals, for instance.

3. Document That All Tokens Must Implement decimals()

   • If you only support tokens that implement IERC20Meta(token).decimals(), ensure the system docs and deployment notes reflect that. Revert if the call fails.

4. Graceful Handling

   • Alternatively, maintain an explicit mapping of tokens → decimals to avoid relying on the token contract’s decimals() function. Then you can store known decimals for each supported token.