Missing slippage protection in strike price calculation for options
The protocol's option creation process lacks protection against price slippage between the time a user submits a transaction and when it's executed.
The protocol's option creation process lacks protection against price slippage between the time a user submits a transaction and when it's executed. Here's the problematic flow:
// In OperationalTreasury.solfunction buy(IStrategy strategy,address holder,uint256 amount,uint256 period,uint256 relativeStrike, // User inputs relative strikeuint256 iv,IvSignerRecovery.SplitSig memory sig) external virtual override nonReentrant whenNotPaused {_checksOnBuy(strategy, period, relativeStrike, iv, sig);_buy(holder, strategy, amount, period, relativeStrike, iv);}// In Call.solfunction _calculateStrike(uint256 preciseCurrentPrice, uint256 relativeStrike)internalviewoverridereturns (uint256){uint256 calculatedStrike = preciseCurrentPrice + ((preciseCurrentPrice * relativeStrike) / 100);return _roundPrice(calculatedStrike);}// In Put.solfunction _calculateStrike(uint256 preciseCurrentPrice, uint256 relativeStrike)internalviewoverridereturns (uint256){uint256 calculatedStrike = preciseCurrentPrice - ((preciseCurrentPrice * relativeStrike) / 100);return _roundPrice(calculatedStrike);}
The issue arises because:
- Users specify a
relativeStrikepercentage for their desired strike price. - The actual strike price is calculated using the
currentPriceat execution time. - Between transaction submission and execution:
- The underlying asset price may change significantly.
- This leads to a different strike price than what the user intended and users have no control over the final strike price.
For example:
- User wants a 10% call when ETH is $2000.
- Expected strike: $2200.
- If the price moves to $2100 before execution.
- Actual strike: $2310 (10% above $2100).
This could make the option much more expensive or less profitable, and this could lead to a bad user experience.
Recommendations:
Implement slippage protection for strike price calculation.
Report provenance
Published by Pashov Audit Group, with Carlos (Bloqarl) participating as a contractor. The source report states that its fixes review was not fully completed; no final remediation disposition is recorded for this finding. Read the full report.