Options Protocol Development (Hegic Style)

Development of Options Protocol (Hegic-style)

Hegic changed the approach to on-chain options in 2020: instead of an order book — liquidity pools. An options buyer pays a premium to the pool, LPs bear the risk (and earn yield). No counterparty, no matching. This made options accessible to regular users, but added LP risk that needs to be properly modeled and hedged.

How Pool-Based Options Work and Where the Risks for LPs Are

Options Pricing: Black-Scholes On-Chain

Hegic uses a simplified version of the Black-Scholes model to calculate the premium. Five parameters are needed: asset price, strike, time to expiration, risk-free rate (can be considered 0 for crypto), and implied volatility (IV).

The problem — IV cannot be computed purely on-chain from first principles. Hegic v888 used fixed IV, which gave incorrect pricing during high/low volatility periods. Hegic v8888 moved to an IV oracle (IVOracle), updated through governance or decentralized mechanism.

For our implementation, IV is submitted via Chainlink Custom Data Feed or its own oracle, which aggregates IV from Deribit via API → off-chain keeper → on-chain update with signature.

Vega (Greek sensitivity to IV) — the main LP risk. As IV increases, all options become more expensive, LPs lose (they sold the option at old premium). A proper protocol dynamically adjusts the pricing coefficient when IV changes.

Utilization Ratio and Payoff Risk

Hegic limits the maximum notional of options that a pool can sell through utilization limit:

maxOpenNotional = poolBalance * maxUtilizationRate

If the pool is $1M with maxUtilizationRate = 0.8, the maximum total notional of open options is $800K. When the limit is reached, new options are not sold. This protects against a scenario where the pool cannot pay all exercised options.

For a custom protocol, we calibrate maxUtilizationRate based on asset volatility and desired risk profile for LPs. 80% — for stablecoin options, 40-50% — for highly volatile assets.

Separated Pools vs. Combined Liquidity

Hegic v888: one pool for all ETH options (call + put). This means natural hedging: LP in put pool lose when ETH falls, but LP in call pool win. Hegic v8888 kept separation by underlying asset, but combined call and put in one pool — LPs get a more diversified position.

For a custom protocol, the choice depends on expected skew (tilt toward puts or calls). If users mostly buy puts as a hedging tool, a combined pool will bear asymmetric risk.

Contract Architecture

Core Modules

OptionsProtocol.sol
├── HegicPool.sol           — liquidity pool + tracking LP positions
├── OptionsManager.sol      — create, exercise, expire options
├── PriceCalculator.sol     — Black-Scholes + IV oracle
├── PayoffCalculator.sol    — calculate payoff on exercise
└── StakingPool.sol         — yield for HEGIC/governance token

HegicPool holds ETH or ERC-20, tracking each LP position as shares. Upon exercise payout LPs proportionally lose pool share. Upon premium receipt — pool grows, shares appreciate.

Exercise Logic: American vs. European

Hegic supports American style — options can be exercised anytime before expiration. This is technically more complex: need to constantly check if option isn't in-the-money. For on-chain this is done permissionlessly: anyone can call exercise() for an expired or ITM option.

European style is simpler for LPs: payout happens only at expiration, LPs can better plan liquidity. For an initial protocol we recommend European — smaller attack surface, simpler reasoning about pool state.

function exercise(uint256 optionId) external {
    Option storage option = options[optionId];
    require(option.state == OptionState.Active, "Not active");
    require(block.timestamp <= option.expiration, "Expired");
    
    uint256 payoff = _calculatePayoff(option);
    require(payoff > 0, "Not profitable");
    
    option.state = OptionState.Exercised;
    pool.sendPayoff(option.holder, payoff);
    
    emit Exercise(optionId, payoff);
}

Greeks Tracking for LP Dashboard

LPs should see aggregated pool delta, gamma, and vega — this is their P&L with market movement. Storing Greeks on-chain is expensive (gas), so we use The Graph subgraph: index all option creation/exercise/expiry events, calculate Greeks off-chain and display in UI.

Typical Vulnerabilities of Options Protocols

Oracle frontrunning. If oracle price updates are predictable (e.g., Chainlink heartbeat every 3600 seconds), an attacker can buy an option right before the update, knowing price will move in the option's favor. Protection: use TWAP instead of spot price for exercise conditions, or introduce minimum hold period.

LP griefing via tiny options. Creating thousands of tiny options fills utilization limit without real value (no profitable exercise). Attacker just holds options and prevents LPs from entering with large liquidity. Protection: minimum premium threshold and maximum open interest per address.

Stale IV on oracle gap. If IV oracle hasn't updated for 24 hours and market sharply moved — protocol sells options at old prices. Circuit breaker: if lastIVUpdate > maxStaleness, block new option creation.

Stack and Tools

Development Process

Analytics (3-5 days). Asset selection, options style (American/European), IV oracle parameters, LP pool tokenomics.

Development (3-5 weeks). Build PriceCalculator first — everything else depends on it. Fuzz-test math on boundary values (very low/high IV, short time to expiration).

Testing (1 week). Simulation: what happens to the pool during flash crash -50% in 1 hour? How much do LPs lose? Does it match expected risk profile?

Audit and deploy. External audit is mandatory — options math contains non-trivial edge cases.

Timeline Reference

Basic protocol for European options on one asset — 4 to 6 weeks. Full protocol with American options, multiple assets, and governance — 8 to 14 weeks.