The XRPL Options Sidechain: Every Detail

XRPL Canada – March 10, 2026

Who Built This

Denis Angell is a software engineer at XRPL-Labs and the founder of Transia R&D, an independent research and development organization operating within the XRPL ecosystem. He publishes through the XRPLF Standards repository under the handle dangell7.

His protocol-level track record:

• Co-launched Xahau — the live smart contract sidechain for the XRPL ecosystem
• Wrote Token Escrow (XLS-85), which activated on XRPL mainnet in 2025 with 88%+ validator support and extended escrow functionality to trustline-based tokens and Multi-Purpose Tokens for the first time
• Wrote the Batch amendment (XLS-56)
• Built AlphaNet — a live XRPL developer network running CRYSTALS-Dilithium quantum-resistant signatures, the NIST-standardized post-quantum algorithm, alongside native Layer-1 smart contracts
• Co-authored the formal quantum-resistant signatures XLS proposal with a researcher from Trinity College Dublin
• Built Driip, a live XRPL DEX trading application
• Working on XRPL Firewall, a customizable account security system

The XRPL Options Sidechain is not an application built on top of the XRP Ledger. It is a proposal to extend the rippled C++ codebase — the same software that has run the XRP Ledger since 2012 — into a purpose-built derivatives chain. The person proposing this has shipped two live mainnet amendments in a single release and launched a live sidechain.

Why This Exists: The Gap

The XRP Ledger has been operational since 2012. It has processed billions of transactions, maintained 99.999% uptime, settles in 3–5 seconds, handles over 1,500 transactions per second, and charges fees that are fractions of a cent. It has a native decentralized exchange built into the protocol — not a smart contract sitting on top of it, but an order book baked into the ledger itself. It has been battle-tested for nearly fifteen years.

What it has never had is a derivatives layer.

The global crypto derivatives market is measured in trillions of dollars of daily volume. On-chain, it is dominated by a small number of chains and, for options specifically, by Deribit — a centralized exchange. On-chain options are technically difficult to build correctly, and almost no one has done it at the protocol level. Lyra and Hegic exist on Ethereum but are application-layer, AMM-based, and lack native order books. Hyperliquid built a purpose-built L1 for perpetual futures with a native order book and captured billions in daily volume and a $9 billion token valuation without venture capital funding.

Hyperliquid did not build on Ethereum. It did not deploy a smart contract. It built a chain specifically designed for the performance characteristics derivatives trading requires. The XRPL Options Sidechain applies the same logic to options.

XRPL has the performance characteristics — speed, finality, fees, validator network, native order book — that a derivatives chain needs. It has never had the financial instruments. This proposal adds them, not by modifying XRPL mainnet, but by building a dedicated sidechain that inherits XRPL's validator trust model and connects to it via a cryptographic bridge.

How XRPL Actually Works: The Foundation

To understand why this proposal is structured the way it is, it is necessary to understand how the XRP Ledger functions at the protocol level.

XRPL is not an EVM chain. There is no general-purpose virtual machine. There are no smart contracts in the Ethereum sense — arbitrary code that executes on-chain. Instead, the XRP Ledger is a purpose-built financial protocol. Every operation on the ledger — creating an offer, establishing a trust line, opening an escrow, minting an NFT — is a defined transaction type implemented directly in the rippled C++ codebase. To add a new capability to XRPL, you do not deploy a contract. You write a new transaction type and ledger object type, implement the validation logic in C++, and submit it as a proposed amendment. That amendment then requires 80% of Unique Node List validators to vote in favor over a two-week period before it activates on mainnet.

This design makes XRPL extremely fast and predictable — every transaction type is native, not interpreted — but it makes it harder to add new financial primitives. The amendment process is deliberate. It is a governance mechanism, not a bottleneck.

XRPL's existing financial primitives include a native decentralized exchange with an on-chain order book, trust lines for issued currencies, escrows with time and cryptographic conditions, payment channels for high-frequency off-chain payments, an automated market maker added in 2024, and multi-purpose tokens (MPTokens) for tokenized assets. Project Samara — Canada's first tokenized bond, a $100 million CAD bond settled on a distributed ledger — was completed March 5, 2026, involving the Bank of Canada, RBC, TD, and Export Development Canada. The infrastructure that made that possible is the same infrastructure the Options Sidechain builds on.

The validator network that secures all of this is a federated model. The Unique Node List is a set of trusted validators that each node operator configures. Consensus is reached when 80% of those validators agree. Ripple publishes a recommended UNL, but the model is not dependent on Ripple — node operators can configure their own. This matters for the Options Sidechain because the same validators that secure XRPL mainnet are the ones being asked to extend their infrastructure to the sidechain and serve as the trust layer for the bridge.

The Three Systems

The XRPL Options Sidechain is composed of three interlocking systems, each defined by a draft XLS specification. None of these require amendments to XRPL mainnet.

System 1: The XPop Bridge (Import/Export)

The bridge is how XRP moves between XRPL mainnet and the sidechain. It uses XPop — a cryptographic proof mechanism that verifies a transaction was validated and included in a specific XRPL mainnet ledger.

The bridge operates as follows:

A user sends XRP to a vault on XRPL mainnet. That vault is a standard multisig account — no mainnet amendments required. When the transaction is validated and closed into a ledger, an XPop proof is generated from that ledger. The XPop is a cryptographic blob that proves the transaction occurred, signed by the validator set. The user then submits an Import transaction to the sidechain, including the XPop blob. The sidechain validates the proof — requiring 80% or more of the validator quorum to have signed it — and mints XRP 1:1 on the sidechain. The total supply on the sidechain never exceeds the balance locked in the mainnet vault.

The full six-step sequence:

Key properties of the bridge: 1:1 lock-and-mint model with total sidechain supply never exceeding the vault balance. No XRPL mainnet amendments required. 80%+ validator quorum required for every import proof. Full replay protection at both account and validator list level. New accounts are bootstrapped automatically on first import — a user does not need to pre-create an account on the sidechain.

The witness model is structurally identical to how Hyperliquid's ETH bridge works, where two-thirds of staking power must approve withdrawals. Here, the signers are the same validators who already secure XRPL mainnet. Their validator keys become signers in the bridge trust model.

System 2: Native Options and Margin Engine

This is the core financial infrastructure. American-style option contracts, implemented natively at the protocol level. Not AMM-based. Not synthetic. Real matched counterparty positions settled at the protocol level via a Central Limit Order Book native to the sidechain.

Option types: Calls and Puts, American-style. American-style means exercise can occur at any time before expiration — not only at expiration as with European-style options. The specification notes that European-style options can be added later via a flag on the listing object.

Settlement: Cash settlement on exercise.

Position types:

• Covered options: Collateral locked at contract creation. The seller's underlying asset is held in the OptionOffer ledger object.
• Naked options: Uncollateralized sell-side positions. Unlimited risk and reward. This is the same structure professional options desks operate on in traditional finance.

Leverage: 2x to 200x via a margin system.

Margin modes:

• Isolated margin: Risk contained per position.
• Cross-margin: Shared collateral pool across positions.

Liquidation: Open to any account on the sidechain, incentivized with a liquidation bonus. The liquidation condition is: Position Equity must be greater than or equal to Maintenance Margin (Health = Position Equity ≥ Maintenance Margin).

Insurance vaults: LP-backed insurance vaults per market, designed to absorb losses when liquidations are insufficient to cover position deficits.

Funding rates: Periodic long/short rebalancing mechanism to prevent sustained imbalances between long and short open interest.

The margin mathematics are identical to what institutional perpetual exchanges use:

The ledger objects that implement this system:

• ltOPTION_PAIR (0x0083): Represents an option listing for a specific asset/strike asset pair — for example, GME/USD. Created via OptionPairCreate. Each option listing is a pseudo account, identical in structure to how XRPL's AMM is implemented. The master key is disabled and the regular key is set to account zero, making it impossible for the account to originate transactions. The OptionPairID is the AccountID of this pseudo account.
• ltOPTION (0x0084): Represents a specific option contract with a defined strike price and expiration. Fields include StrikePrice (Amount), Expiration (UInt32, UNIX timestamp), and OptionType (UInt8: 0 for Call, 1 for Put).
• ltOPTION_OFFER (0x0085): Represents an offer to buy or sell an option contract. Fields include Owner, OptionID, Premium, Quantity (must be divisible by 100), OpenInterest (unsealed amount), Amount (locked collateral for sellers), BookDirectory, BookNode, and SealedOptions — an array of matched counterparty positions.

The transaction types:

• OptionPairCreate (ttOPTION_PAIR_CREATE, code 64): Creates a new pseudo account for an option listing with a specified asset/asset2 pair. Fails if an identical pair already exists.
• OptionCreate (ttOPTION_CREATE, code 64): Creates a new option offer for an existing option contract identified by OptionID. Quantity must be divisible by 100. Flags: tfMarket (market order), tfSell (sell offer; default is buy). For sellers, collateral is locked immediately. For matched offers, premiums are transferred between counterparties and SealedOptions arrays are updated.
• OptionSettle (ttOPTION_SETTLE, code 65): Settles an option contract. Exactly one flag must be set: tfExpire (expire the option and return any locked collateral to the seller), tfClose (close the position, potentially replacing sealed option relationships with new counterparties), or tfExercise (exercise the option). For a Call exercise: the holder pays the strike price to the writer, the writer transfers the underlying asset to the holder. For a Put exercise: the holder transfers the underlying asset to the writer, the writer pays the strike price to the holder.

The serialized fields added to the protocol:

sfStrikePrice (Amount, code 32), sfExpiration (UInt32), sfOptionPairID (Hash256, code 35), sfOptionID (Hash256, code 36), sfOptionOfferID (Hash256, code 37), sfQuantity (UInt32, code 53), sfOpenInterest (UInt32, code 52), sfPremium (Amount, code 33), sfSealedOption (Object, code 34), sfSealedOptions (Array, code 29).

The order book is implemented natively, indexing OptionOffer objects by OptionID and sorting by Premium via OptionQuality — the same pattern XRPL uses for its existing currency offer order book. When an OptionCreate is processed, the ledger attempts to match the new offer with existing offers. Matched offers update the SealedOptions arrays of both counterparties.

New RPC method: option_book_offers — queries the current state of the option order book for a specific option. Supports pagination via limit and marker parameters. Returns ledger_hash, ledger_index, option details, and an array of offers sorted by quality (premium).

Comparison to the existing landscape:

System 3: WebAuthn/FIDO2 Passkey Authentication

The sidechain introduces P256 (secp256r1) as a native key type — a new addition to the rippled key type system, which currently uses secp256k1 and Ed25519. P256 is the elliptic curve underpinning the WebAuthn/FIDO2 standard, which is the authentication protocol used by major banks, Google, and Apple for passwordless login.

What this means in practice: users sign sidechain transactions with Face ID on iPhone or Mac, Touch ID, Windows Hello, YubiKey, or any other FIDO2 hardware security key. No seed phrase. No private key management. Signing is handled by the device's secure enclave or hardware key, which never exposes the underlying key material.

Accounts on the sidechain can register up to 10 passkey credentials. This enables hardware key backup and enterprise multi-device setups — a trader can register a YubiKey as a backup to their Face ID, for example.

The security audit scope for this system covers P256 implementation correctness, WebAuthn flow validation, passkey list tampering, and key derivation security.

A question was raised in the XLS-62d discussion thread about whether DID/Credential infrastructure — introduced to XRPL after this proposal was initially written — could be used to gate options access to accredited participants at the protocol level. Denis confirmed that this is now architecturally possible and could be implemented.

Current Status

This proposal is pre-testnet. No audit has been completed. No testnet has launched. No validator set has been confirmed. The specifications are published and open for community review. Denis is actively seeking established XRPL UNL validators to extend their infrastructure to the sidechain and is seeking a security audit funded through the XRPL Grants program.

When Denis published the GitHub link on X with the message "Something big," the post drew 46,600 views. Responses came from Hodor and multiple active UNL validators expressing interest in participation.

Three parallel community review tracks are open:

Track 1 — XLS Specification Review: Design-level issues, ambiguities, edge cases. Key open questions include whether the XPop validation steps in the Import flow are complete and correctly ordered, whether the 80% quorum threshold adequately protects against validator set manipulation, whether the sealed option matching semantics are correct for all exercise, close, and expiry combinations, and whether the cross-margin liquidation condition is sufficient to prevent cascading insolvency.

Track 2 — C++ Code Review: Protocol-level implementation in the options-sidechain branch of the rippled repository. Focus areas include correctness of XPop Merkle proof verification and ledger hash computation, margin math implementation for integer overflow and rounding errors in fixed-point arithmetic, invariant check coverage in MarginInvariant.h, object lifecycle management for ExportRecord, MarginPosition, and SealedOptions, error handling paths in the Import preflight/preclaim/doApply split, and memory safety against malformed XPop blobs.

Track 3 — Economic and Game Theory Review: Financial attack vectors the code review cannot catch. Key questions include whether the insurance vault can be drained through coordinated liquidation timing, whether funding rates are sufficient to prevent structural long/short imbalances, whether a large naked option seller can create systemic risk if liquidated simultaneously with volatile price movement, whether the 1:1 lock-and-mint model creates reflexivity risks if XRP price moves sharply during bridge transit, whether the liquidation bonus is sized correctly, and whether the option book can be manipulated via wash trading to influence mark price for liquidation purposes.

The audit will be scoped across three systems with the following risk classifications: the XPop Import/Export bridge (Critical — replay attacks, validator collusion, quorum manipulation, vault security, XPop proof forgery, cross-chain double-spend), the Options and Margin Engine (Critical — liquidation math correctness, margin invariant enforcement, oracle manipulation, insurance vault solvency, naked option settlement edge cases), and Passkey/P256 authentication (High — P256 implementation correctness, WebAuthn flow validation, passkey list tampering, key derivation security).

The audit requires a rare combination of skills: deep C++ and consensus protocol expertise, understanding of XRPL's ledger object model and transaction processing pipeline, financial derivatives knowledge, cryptographic review capability for P256/WebAuthn/Merkle proof verification, and cross-chain bridge security specific to XPop proof validation and multisig vault trust models. It is not a Solidity smart contract audit.

Why a Sidechain and Not a Mainnet Amendment

The amendment process exists for good reason. Activating a new capability on XRPL mainnet requires 80% of UNL validators to vote in favor over a two-week period. For financial infrastructure as complex as a full options and margin engine, the prudent path is to build, test, and prove the system on a sidechain first. The sidechain inherits XRPL's validator trust model without requiring mainnet to absorb the risk of unproven protocol-level financial logic.

This is the same path Xahau took. Xahau is a sidechain — not a mainnet amendment — that introduced Hooks (smart contract functionality) to the XRPL ecosystem. It runs the same rippled codebase extended with additional capabilities, secured by the same validator community. Denis was part of the team that built and launched it.

What This Means

XRPL has operated as payments infrastructure for nearly fifteen years. It is fast, reliable, and cheap. It has institutional relationships through Ripple, a growing tokenized asset ecosystem through MPTokens, and regulatory credibility in Canada and other jurisdictions.

What it has not had is derivatives infrastructure. The institutions that use XRPL for cross-border settlement, the tokenized asset holders, the XRP liquidity pool — none of them have had access to on-chain options, hedging instruments, or leveraged exposure, natively within the XRPL ecosystem.

If this proposal reaches testnet, completes its audit, and builds a functioning validator set, it would be the first native on-chain options market on one of the oldest and most liquid blockchains in crypto. The validators who participate at genesis are founding stakeholders, in the same position as Hyperliquid's original sixteen validators.

The specifications are open. The code is on GitHub. Community review is active now.