Decentralized Options Protocols

WHY OPTIONS LIQUIDITY IS HARD:

FRAGMENTATION:
├── Each underlying has multiple expirations
├── Each expiration has multiple strikes
├── Calls AND puts at each strike
├── Example: 4 expirations × 20 strikes × 2 = 160 contracts
├── Liquidity spread across all contracts
└── Each contract needs two-sided market

TRADITIONAL MARKET MAKERS:
├── Provide liquidity across strikes
├── Dynamically hedge with underlying
├── Manage Greeks portfolio-wide
├── Adjust continuously as prices move
├── Requires: Capital, sophistication, technology
└── Few can do this well

DEFI CHALLENGE:
├── Can't run complex algorithms on-chain (too expensive)
├── Can't hedge dynamically (would need oracle + many transactions)
├── Passive LPs don't know options pricing
├── LPs face adverse selection (informed traders pick them off)
└── How to provide options liquidity without professional MMs?

APPROACHES:

1. AMM-Based (Passive):

2. Order Book (Active):

3. Hybrid:

OPTIONS PRICING CHALLENGE:

BLACK-SCHOLES REQUIREMENTS:
├── Current spot price (need oracle)
├── Strike price (known)
├── Time to expiration (known)
├── Risk-free rate (estimate)
├── Implied volatility (critical, unknown)
└── Volatility is the hard part

VOLATILITY PROBLEM:
├── IV is forward-looking market expectation
├── Can't observe directly, must infer from prices
├── But: On-chain, protocol SETS prices
├── Circular problem: Need IV to price, need prices to get IV
└── Must estimate or import IV

APPROACHES:

Oracle-Based IV:
├── Import IV from off-chain (CME, Deribit)
├── Reliable but centralized dependency
├── What if oracle fails/manipulated?
└── Hybrid centralization

Historical Volatility:
├── Calculate realized vol from spot prices
├── Use as IV estimate
├── But: HV ≠ IV (often significantly different)
├── Mispricing likely
└── Simple but inaccurate

Market-Derived:
├── Let supply/demand determine prices
├── Derive implied IV from trades
├── But: Needs initial liquidity somehow
├── Bootstrap problem
└── Circular but potentially accurate

Model-Free:
├── Don't use Black-Scholes
├── Use simpler pricing (linear, piecewise)
├── Accept deviation from theoretical
├── Simpler but less sophisticated
└── Trade-off complexity for feasibility
```

OPTIONS SETTLEMENT ON-CHAIN:

SETTLEMENT REQUIREMENTS:
├── Know spot price at expiration (oracle)
├── Determine which options are ITM
├── Calculate settlement amount
├── Transfer funds automatically
├── Handle edge cases (exactly ATM, etc.)
└── All must be trustless

ORACLE DEPENDENCY:
├── Settlement price MUST come from somewhere
├── If oracle is wrong, settlement is wrong
├── Oracle manipulation = free money for attackers
├── Critical infrastructure
└── Single point of failure

SETTLEMENT STYLES:

European (At Expiration Only):
├── Simpler to implement
├── Single oracle call needed
├── Less attack surface
├── Most DeFi options use this
└── Preferred for on-chain

American (Any Time):
├── Complex to implement
├── Must monitor continuously
├── Higher oracle costs
├── Harder to price
└── Rarely implemented on-chain

Cash vs. Physical:

Cash Settlement:
├── Pay difference in stablecoin or base asset
├── Simpler logistics
├── Most common in DeFi
└── Preferred approach

Physical Settlement:
├── Actually deliver underlying
├── More complex
├── Liquidity requirements
├── Less common in DeFi
└── Used by some protocols

---

OPYN OVERVIEW:

HISTORY:
├── Early DeFi options protocol
├── Pivoted from vanilla options to Squeeth
├── Squeeth = "Squared ETH" (ETH²)
├── Power perpetual, not traditional option
└── Novel approach to options exposure

SQUEETH MECHANISM:
├── Tracks ETH² (squared price)
├── Provides convex payoff (like options)
├── No strikes, no expiration
├── Perpetual product
├── Funding rate mechanism (like perp)
└── Simplified options-like exposure

WHY SQUEETH:
├── Traditional options had liquidity fragmentation
├── Squeeth consolidates liquidity
├── Single product, options-like payoff
├── Easier to understand than Greeks
└── Innovative solution to fragmentation

HOW IT WORKS:
├── Long Squeeth: Pay funding, get convex upside
├── Short Squeeth: Collect funding, linear downside
├── Funding rate based on mark vs index
├── No liquidations for longs (just funding)
└── Shorts need collateral (liquidation risk)

TRADE-OFFS:
├── ✓ Solves fragmentation
├── ✓ Perpetual (no rollovers)
├── ✓ Simpler than options
├── ✗ Not traditional options (can't target strikes)
├── ✗ Funding can be expensive
├── ✗ Different risk profile than vanilla options
└── Innovation but different product

LYRA OVERVIEW:

DESIGN:
├── AMM-based options protocol
├── Liquidity pools provide options
├── Greeks-aware pricing
├── Automated delta hedging
└── Most sophisticated on-chain options AMM

HOW LIQUIDITY WORKS:
├── LPs deposit to liquidity pool
├── Pool sells options to traders
├── Protocol automatically hedges delta
├── LPs earn premiums minus hedging costs
├── Exposure is to volatility, not direction
└── Professional-grade mechanism

PRICING MECHANISM:
├── Black-Scholes based
├── IV from oracle + adjustments
├── Skew and term structure modeled
├── Dynamic spread based on utilization
└── Attempts accurate pricing

DELTA HEDGING:
├── Protocol trades perps to hedge delta
├── Keeps pool delta-neutral-ish
├── Reduces directional risk for LPs
├── But: Hedging has costs (slippage, funding)
└── Critical innovation

LP RETURNS:
├── Earn: Options premiums
├── Pay: Hedging costs, adverse selection
├── Net: Depends on realized vs implied vol
├── If RV < IV: LPs profit
├── If RV > IV: LPs lose
└── Volatility risk, not directional

TRADE-OFFS:
├── ✓ Full options chain
├── ✓ Greeks-aware
├── ✓ Automated hedging
├── ✗ Complex (harder to audit/understand)
├── ✗ Hedging costs can eat profits
├── ✗ Oracle dependent
└── Most traditional-like on-chain options

DOPEX OVERVIEW:

DESIGN:
├── Options liquidity via "Single Staking Option Vaults" (SSOVs)
├── LPs deposit to specific strike vaults
├── Structured products focus
├── Atlantic options (partial collateral release)
└── Different approach than AMM

SSOV MECHANISM:
├── LP deposits to specific strike + expiration vault
├── Deposited funds are option collateral
├── Buyers purchase options from vault
├── At expiration, ITM options settle from vault
└── LPs take the other side of specific options

ATLANTIC OPTIONS:
├── Novel product type
├── Allow collateral release before expiry
├── For use in leveraged positions
├── Funding based
└── DeFi-native innovation

TRADE-OFFS:
├── ✓ Clear risk for LPs (specific strikes)
├── ✓ Innovative products (Atlantics)
├── ✓ Structured product focus
├── ✗ Fragmented liquidity (per vault)
├── ✗ Less flexible than AMM
├── ✗ Still oracle dependent
└── Different niche than Lyra

PREMIA OVERVIEW:

DESIGN:
├── Order book + AMM hybrid
├── Market makers can post orders
├── AMM provides baseline liquidity
├── Range orders (concentrated liquidity style)
└── Attempts best of both worlds

VERSION 3 MECHANICS:
├── Concentrated liquidity model
├── LPs provide liquidity at price ranges
├── More capital efficient
├── Market makers can be more active
└── Uniswap v3-inspired for options

PRICING:
├── Order book price discovery
├── AMM as fallback
├── C-level (Dutch auction style) for volatility
└── More market-driven than pure formula

TRADE-OFFS:
├── ✓ More capital efficient
├── ✓ Market maker participation
├── ✓ Hybrid flexibility
├── ✗ More complex
├── ✗ Requires active LPs for best pricing
├── ✗ Still developing
└── Interesting hybrid approach

COMPARISON MATRIX:

Opyn      Lyra      Dopex     Premia
──────────────────────────────────────────────────────────
Product Type       Power Perp Options   Options   Options
Liquidity Model    Pool      AMM+Hedge  Vaults    Hybrid
Strike Selection   N/A       Full chain Per vault Full chain
Expiration         Perpetual Fixed      Fixed     Fixed
LP Complexity      Medium    High       Low       Medium
Hedging            Manual    Automated  None      Manual
Capital Efficiency Medium    Medium     Low       High
Oracle Dependency  High      High       High      High
Innovation Level   High      High       Medium    Medium
──────────────────────────────────────────────────────────

BEST FOR:

Opyn/Squeeth:
├── Want convex exposure without strike selection
├── Don't want to manage expirations
└── Accept funding cost for perpetual

Lyra:
├── Want traditional options experience
├── Want protocol-managed hedging
└── Accept complexity and hedging drag

Dopex:
├── Want structured products
├── Clear risk/reward preferences
└── Willing to commit to specific strikes

Premia:
├── Want capital efficiency
├── Can provide active liquidity
└── Want order book-style trading

---

OPTIONS LP FUNDAMENTALS:

WHAT YOU'RE DOING:
├── Selling options to traders
├── Receiving premium
├── Taking on risk (short options position)
├── Hoping options expire worthless or hedge covers
└── Essentially: Insurance provider

RISK PROFILE:

Without Hedging:
├── Short call: Unlimited loss if price rallies
├── Short put: Large loss if price crashes
├── Premium received vs. potential payout
├── Asymmetric risk
└── Dangerous without management

With Hedging (Like Lyra):
├── Delta hedged = directional neutral
├── Remaining risk: Volatility (gamma/vega)
├── If realized vol > implied vol: Lose
├── If realized vol < implied vol: Win
└── Volatility bet, not directional bet

RETURN DRIVERS:

Positive:
├── Premium collection
├── Time decay (theta)
├── IV > RV spread
└── Systematic insurance premium

Negative:
├── Large moves (gamma losses)
├── RV > IV periods
├── Hedging costs (slippage, funding)
├── Adverse selection
└── Jump risk (sudden crashes)
```

HISTORICAL LP RETURNS:

GENERAL PATTERN:
├── Options LPs often profitable in calm markets
├── Large losses in volatile markets
├── Vol selling = picking up pennies in front of steamroller
├── Long-term return depends on premium vs. blowup frequency
└── Not guaranteed positive

FACTORS AFFECTING RETURNS:

Implied vs Realized Spread:
├── Crypto IV historically > RV on average
├── "Volatility risk premium" exists
├── But: Tail events can overwhelm
├── Average positive, high variance
└── Insurance model

Hedging Efficiency:
├── Perfect hedging impossible (discrete, costly)
├── Slippage costs compound
├── Funding costs for perp hedges
├── Gap risk (can't hedge through gaps)
└── Hedging drag is real

Adverse Selection:
├── Informed traders know when options are cheap
├── They buy underpriced options
├── LPs systematically sold at wrong times
├── AMM can't discriminate
└── Information asymmetry cost

REALISTIC EXPECTATIONS:
├── Long-term: Maybe 5-15% annualized premium
├── Variance: High (can have large drawdowns)
├── Correlation: Loses in market stress (wrong time)
├── Suitable for: Sophisticated capital, not savings
└── Not passive income
```

IF YOU LP TO OPTIONS PROTOCOL:

POSITION SIZING:
├── Do not put significant portfolio %
├── Treat as high-risk allocation
├── Assume total loss possible
├── 5-10% of portfolio maximum
└── Probably less

DIVERSIFICATION:
├── If LP'ing, diversify across protocols
├── Different risk profiles
├── Different failure modes
├── But: All correlated in market stress
└── Limited diversification benefit

MONITORING:
├── Check positions regularly
├── Understand current exposure
├── Know protocol health (TVL, volume)
├── Watch for exploits/issues
└── Active, not passive

EXIT PLANNING:
├── Know how to withdraw
├── Understand any lockups
├── Watch for liquidity crunches
├── Have exit triggers
└── Don't wait for crisis

SMART CONTRACT RISK:
├── All protocols have smart contract risk
├── Hacks have happened (Cream, etc.)
├── Audits reduce but don't eliminate risk
├── Bug bounties help
└── Factor into sizing

---

BUILDING OPTIONS ON XRPL:

CORE REQUIREMENTS:

1. Smart Contract Capability:

2. Price Oracles:

3. Collateral Management:

4. Settlement Logic:

5. Liquidity Mechanism:

MISSING PIECES TODAY:
├── Smart contracts (Hooks/EVM not mainnet)
├── Oracle infrastructure
├── Developer tooling
├── Audit ecosystem
└── All must be solved
```

XRPL OPTIONS PROTOCOL DESIGN:

APPROACH OPTIONS:

Simple (First Generation):
├── European options only
├── Limited strikes (ATM, 10% OTM each side)
├── Weekly/monthly expirations only
├── Cash settled in XRP
├── Single collateral type (XRP)
└── Minimally viable product

Sophisticated (Later):
├── Full strike chain
├── Multiple expirations
├── American options possible
├── Greeks management
├── Delta hedging integration
└── Competitive with Lyra

LIQUIDITY MODEL CHOICE:

AMM (Lyra-style):
├── Pros: Passive LP possible, always liquid
├── Cons: LP adverse selection, hedging complexity
└── Better for: Bootstrap phase

Vault (Dopex-style):
├── Pros: Clear LP risk, simpler
├── Cons: Fragmented liquidity
└── Better for: Structured products

Hybrid (Premia-style):
├── Pros: Capital efficient, flexible
├── Cons: Complex, needs active MMs
└── Better for: Mature market

RECOMMENDATION FOR XRPL:
├── Start simple (limited strikes, European, AMM)
├── Prove concept works
├── Add sophistication over time
├── Don't over-engineer first version
└── Iterate based on actual usage
```

ORACLE OPTIONS FOR XRPL:

OPTION 1: Centralized Oracle
├── Single trusted party provides prices
├── Simple implementation
├── But: Centralization risk
├── Acceptable for early stage?
└── Many DeFi protocols started here

OPTION 2: Multi-sig Oracle
├── Multiple parties must agree on price
├── Reduces single point of failure
├── Still trust-based
├── Better than single party
└── Intermediate solution

OPTION 3: Chainlink-style
├── Decentralized oracle network
├── Multiple data sources
├── Economic incentives for accuracy
├── Best long-term solution
├── But: Doesn't exist on XRPL yet
└── Would need to be built or ported

OPTION 4: On-Chain Price
├── Use XRPL DEX prices
├── Fully decentralized
├── But: DEX liquidity may be thin
├── Manipulation risk
└── TWAP can help

OPTION 5: CME Reference Rate
├── Import CME CF XRP-Dollar Rate
├── Battle-tested, manipulation-resistant
├── But: Off-chain source
├── Daily settlement only
└── Good for daily-settled options

PRACTICAL PATH:
├── Start with trusted oracle (centralized)
├── Move to multi-sig
├── Eventually decentralized network
├── Accept trade-offs for progress
└── Perfect shouldn't block good

---

HYPOTHETICAL XRPL OPTIONS PROTOCOL:

VISION (2027+):

Product:
├── XRP call and put options
├── Strikes: $0.50 intervals around spot
├── Expirations: Weekly, monthly, quarterly
├── Settlement: Cash in XRP or RLUSD
└── European style

Liquidity:
├── AMM pools for each expiration
├── LPs deposit XRP + RLUSD
├── Protocol manages positions
├── Automated delta hedging via XRPL DEX
└── Passive LP experience

Pricing:
├── Black-Scholes with adjustments
├── IV from oracle + market feedback
├── Dynamic spreads based on utilization
└── Competitive with Deribit

Settlement:
├── Automatic at expiration
├── Oracle provides settlement price
├── ITM options auto-exercised
├── Funds distributed to holders
└── Trustless execution

USER EXPERIENCE:

Traders:
├── Connect wallet
├── Browse options chain
├── Select strike/expiration
├── Buy/sell with one click
├── Positions managed automatically
└── Similar to Deribit UX

LPs:
├── Deposit to liquidity pool
├── Earn premiums automatically
├── Hedging handled by protocol
├── Withdraw anytime (subject to utilization)
└── Passive income attempt
```

XRPL OPTIONS VS. ALTERNATIVES:

VS. CME XRP OPTIONS:
├── XRPL: Permissionless, 24/7, smaller size
├── CME: Regulated, US-accessible, liquid
├── XRPL advantage: Accessibility, composability
├── CME advantage: Institutional trust, liquidity
└── Different markets

VS. DERIBIT:
├── XRPL: Native XRP, potentially cheaper
├── Deribit: Established, liquid, proven
├── XRPL advantage: Decentralized, no counterparty
├── Deribit advantage: Liquidity, track record
└── Trust vs. established

VS. ETHEREUM OPTIONS (Lyra, etc.):
├── XRPL: Faster, cheaper transactions
├── Ethereum: More liquidity, more LPs
├── XRPL advantage: Cost, speed
├── Ethereum advantage: Ecosystem, tooling
└── Niche vs. general

REALISTIC POSITIONING:
├── XRPL options won't replace CME/Deribit
├── Will serve: XRP-focused traders
├── Will serve: DeFi-native users
├── Will serve: Smaller traders
├── Niche but valuable
└── Don't expect dominance

XRPL OPTIONS DEVELOPMENT TIMELINE:

PHASE 1: INFRASTRUCTURE (2025-2026)
├── Hooks or EVM sidechain mainnet
├── Basic oracle solutions
├── Developer tooling
└── Foundation laid

PHASE 2: FIRST PROTOCOL (2026-2027)
├── MVP options protocol launches
├── Limited strikes/expirations
├── Initial liquidity ($1-10M TVL)
├── Bug bounties, audits
└── Proof of concept

PHASE 3: ITERATION (2027-2028)
├── Multiple protocols compete
├── Features expand
├── Liquidity grows
├── Tooling matures
└── Ecosystem develops

PHASE 4: MATURITY (2028+)
├── Deep liquidity
├── Full options chains
├── Institutional interest
├── Interoperability
└── Competitive market

MILESTONES TO WATCH:
├── First options protocol announcement
├── TVL reaching $10M, $100M
├── Daily volume reaching $1M, $10M
├── Institutional LP participation
├── CME/Deribit integration possibilities
└── Each signals maturation

---

✅ Decentralized options are possible — Lyra, Opyn, Dopex, Premia demonstrate viable designs.

✅ Multiple approaches work — AMM, vaults, hybrids all have trade-offs but function.

✅ Oracle infrastructure is critical — All protocols depend on reliable price feeds.

⚠️ Long-term LP profitability — Returns depend on vol premium persistence.

⚠️ Optimal design for XRPL — Which model works best is unknown until tried.

⚠️ Adoption trajectory — Whether XRP community will use on-chain options uncertain.

🔴 Underestimating smart contract risk — All protocols can be hacked.

🔴 LP-ing without understanding risks — Selling volatility has tail risk.

🔴 Assuming Ethereum models will work directly — XRPL has different characteristics.

Decentralized options are complex but achievable. Existing Ethereum protocols provide blueprints. XRPL could support options once Hooks/EVM and oracle infrastructure exist. However, this is 2-3+ years away from mature implementation. First-generation XRPL options will likely be simple and limited. LP-ing will carry significant risk. For current options needs, CME and Deribit remain superior choices. XRPL options are a future opportunity to monitor, not a present reality to plan around.

---

Assignment: Design a hypothetical XRP options protocol for XRPL.

Requirements:

Part 1: Protocol Overview (1 page)

• Product specifications (strike structure, expirations, settlement type)
• Target users (retail, institutional, DeFi protocols)
• Unique value proposition vs. CME/Deribit
• Key differentiators

Part 2: Liquidity Mechanism (1.5 pages)

• AMM, vault, hybrid, or other?
• How do LPs participate?
• How is pricing determined?
• How is delta hedging handled (if at all)?
• What are LP returns and risks?

Include diagram of fund flows.

Part 3: Technical Architecture (1 page)

• Hooks vs. EVM sidechain?
• Oracle solution?
• Settlement mechanism?
• Collateral management?
• Key smart contract functions

Part 4: Risk Analysis (1 page)

• Smart contract risk mitigation
• Oracle failure handling
• LP loss scenarios
• Market manipulation prevention
• Liquidity crisis management

Part 5: Launch Plan (0.5 page)

• MVP scope

• Liquidity bootstrap strategy

• Initial parameter settings

• Iteration plan

• Design coherence (25%)

• Technical feasibility (25%)

• Risk awareness (25%)

• Innovation/value proposition (25%)

Time Investment: 3 hours

---

For Next Lesson:
Lesson 17 examines decentralized perpetual futures—how dYdX, GMX, and others work, and what perpetuals might look like on XRPL.

---

End of Lesson 16

Total words: ~5,800
Estimated completion time: 60 minutes reading + 3 hours deliverable