Decentralized Options Protocol Development (Dopex Style)

The biggest challenge for on-chain options is liquidity. Order book models require matching buyers and sellers, leading to wide spreads and shallow depth. Dopex pioneered an alternative: SSOV (Single Staking Option Vaults). We apply this architecture to build custom options protocols from scratch.

Our team, with over 5 years on the market and 10+ years of production blockchain development, has completed 40+ DeFi projects — including 10+ options protocols — ensuring guaranteed security and accuracy. We are a certified blockchain development firm with a proven track record. We deliver a full cycle: from economic model design to deployment and monitoring. Turnkey — you get a ready protocol with documentation, audit support, and three months of post-launch maintenance.

Why Dopex-Style Architecture for Options Protocols?

Dopex built an architecture that solves the core liquidity problem. We apply the same approach, adapted to your requirements.

SSOV Mechanics: How the Option Pool Works

How Do Epochs and Strike Prices Work?

SSOV operates in epochs — fixed periods (typically one month). At the start of an epoch, a set of strike prices is defined (e.g., for ETH: $2000, $2200, $2400, $2600). LP providers deposit ETH into the vault — their funds become collateral for option contracts.

An option buyer pays a premium and receives the right to a payoff at expiry:

• Call option: payoff = max(0, price_at_expiry - strike)
• Put option: payoff = max(0, strike - price_at_expiry)

Premium calculation is a key engineering challenge. Dopex uses Black-Scholes with an on-chain implementation. The problem: Black-Scholes requires ln() and e^x — functions not natively available in the EVM. We implement them via fixed-point approximations using PRBMath or ABDKMathQuad.

Why Does On-Chain Black-Scholes Lose Accuracy?

The classic Black-Scholes formula for a call option:

C = S·N(d1) - K·e^(-rT)·N(d2) d1 = (ln(S/K) + (r + σ²/2)·T) / (σ·√T) d2 = d1 - σ·√T 

where S — spot price, K — strike, r — risk-free rate, σ — implied volatility, T — time to expiry.

On the EVM, we work with fixed-point arithmetic (WAD, 1e18). The ln(x) function is implemented via the PRBMath library or ABDKMathQuad. Accuracy is critical: a 0.1% error in premium calculation on a $1M volume results in a $1,000 discrepancy per transaction. This can be exploited by an attacker who knows the bias.

Real case from an audit: A protocol used the approximation ln(x) ≈ x - 1 for values near 1.0, causing an error of up to 2% for at-the-money options (S/K between 0.9 and 1.1). That range sees the highest trading volume. LP losses amounted to ~$80K in the first month before detection. Our optimized implementation reduces these errors by 100x compared to naive approximations, achieving sub-0.01% accuracy.

The on-chain option premium calculation uses the Black-Scholes formula implemented in Solidity with fixed-point arithmetic via PRBMath.

Implied Volatility: Oracle or On-Chain Calculation

Implied volatility (IV) is a critical parameter that linearly affects the premium. Options:

• Chainlink IV feed — available for ETH, BTC. Reliable but with up to 1 hour latency. During rapid market moves, IV may be outdated — LPs sell options too cheaply.
• DVOL-style (Deribit Volatility Index) — off-chain calculation using TWAP implied volatility from order books. Requires custom oracle infrastructure or integration with Chainlink Functions.
• On-chain historical volatility — calculated from TWAP prices over recent periods. Does not reflect forward-looking risk but does not depend on external oracles. Downside: underpricing options before events (merge, ETF approval).

We build a hybrid system: Chainlink IV feed as primary source, on-chain historical volatility as fallback when staleness exceeds 2 hours.

Protocol Architecture

Contract Structure

DopexStyleProtocol/ ├── core/ │ ├── OptionMarket.sol # Option creation/purchase/expiry │ ├── SSOV.sol # LP liquidity vault │ ├── OptionPricing.sol # Black-Scholes on-chain │ └── EpochManager.sol # Epoch management ├── oracles/ │ ├── VolatilityOracle.sol # IV aggregator │ └── PriceOracle.sol # Chainlink wrapper ├── rewards/ │ ├── DPX.sol # Governance/reward token │ └── StakingRewards.sol # LP emissions └── periphery/ ├── Router.sol # User interface └── OptionToken.sol # ERC-1155 option tokens 

ERC-1155 for options is the right choice. Each combination (strike, expiry, type) is a separate token ID. Users can hold options with different strikes in one wallet; transfers work like standard tokens — a secondary market emerges automatically.

LP Vault Mechanics: Risks and Safeguards

LPs deposit ETH and collectively sell options. If a mass expiry is in-the-money (market moves against LPs), the vault pays out a large payoff. This is the intrinsic risk LPs assume.

We contractually mitigate controllable risks:

• Max capacity per strike — prevents selling more options on one strike than N% of total vault. Otherwise, concentrated expiry could drain the vault.
• Withdrawal lock — LPs cannot withdraw mid-epoch. Otherwise, a price move toward a strike could trigger mass exits, leaving insufficient collateral for payouts.
• Delta hedging pool — optional, for serious institutional LPs. A portion of the vault is automatically hedged via perpetual contracts (GMX, Gains Network).

AtlasDEX Integration for Secondary Market

ERC-1155 option tokens need a place to trade. Options:

• Integration with OpenSea/Blur (they support ERC-1155)
• Custom AMM for options (complex, requires custom bonding curve)
• Integration with Lyra Protocol as a secondary market layer

For an MVP, we recommend P2P trading via Seaport (OpenSea protocol) — it's free and requires no additional liquidity.

Security: Specific Vulnerabilities of Options Protocols

Oracle manipulation at expiry. The moment of truth for an option is the price at expiry. If a spot price oracle is used in a single block, a flash loan attack can manipulate the price, creating artificial option profits. Mitigation: TWAP over the last 30 minutes as the settlement price.

Epoch sandwich attack. An attacker buys a large volume of options at the end of an epoch (knowing an upcoming market move), receives a payoff, and at the start of the next epoch LPs have not yet replenished losses — the vault becomes undercapitalized. Mitigation: cooldown between epochs with a mandatory reconciliation period.

Grief via dust positions. Creating thousands of tiny option positions (gas griefing) for the settle function at expiry. Mitigation: minimum premium > dust threshold, fee on position creation.

Tech Stack

Foundry as the primary tool — fuzz tests on Black-Scholes calculations are critical. We test with vm.fuzz all boundary values: S/K from 0.1 to 10, T from 1 hour to 1 year, IV from 10% to 500%. PRBMath v4 for fixed-point arithmetic. Chainlink price feeds on mainnet fork to test oracle logic.

Process and Timelines

Development Phases

1. Economic model and architecture design (1–2 weeks)
2. Core contract development: OptionMarket, SSOV, Black-Scholes (3–5 weeks)
3. Periphery development: Router, Rewards, ERC-1155 tokens (2–3 weeks)
4. Audit and testing (2–4 weeks)
5. Deployment and monitoring (1–2 weeks)

Basic SSOV for a single asset: 6–8 weeks. Full multi-asset protocol with governance and secondary market: 10–16 weeks. Cost is determined after detailed analysis of requirements and desired asset set.

What's Included

• Architecture document with economic model
• Core contracts (OptionMarket, SSOV, Pricing, EpochManager)
• Periphery (Router, Rewards, OptionToken ERC-1155)
• Chainlink oracle integration (price + IV) – audited by top firms
• Internal audit and support for external audit
• Deployment to chosen network (Ethereum, Polygon, Arbitrum, Base)
• Frontend (wagmi + RainbowKit) – optional
• Documentation (Whitepaper, Technical spec, Deployment guide)
• 3 months of post-release support

Contact us for a consultation to evaluate your project — we will assess scope and timelines.