DIP: Launch Derive V3

General
1

Simple Summary

Deploy and launch Derive V3 (zkVM program settling on Ethereum mainnet), migrate all V2 positions and balances into V3’s genesis state, move bridge funds to L1, and wind down Derive Chain.

Abstract

This proposal describes the process of deploying and migrating to V3, which is as follows:

  • Build a V3 genesis state from a pinned V2 snapshot: accounts, balances, positions, wallet-held ERC20s (including stDRV), unclaimed lyra migration, pending rewards, native ETH
  • Initialise V3 protocol
  • Move bridge balances either to the V3 L1 contracts, directly to owner wallets or LZ OFTAdapter contracts where applicable
  • Deploy stDRV to Ethereum mainnet and connect the DRV OFT to Robinhood Chain
  • Wind down Derive Chain after successful migration and launch of Derive V3

This proposal also sets out the trust model V3 is built around: what “self-custodial”, “trustless” and “private” mean in this design, how each is enforced, and where the remaining trust assumptions sit. Most of V3’s technical complexity comes from the trade-offs between these three goals.

Approval of this proposal authorizes the deployment and launch of V3, the migration of V2 state and assets, the wind-down of Derive Chain, and the related token, Security Module and migration actions described below.

Motivation

From the start, contributors to Lyra and Derive have built at the technical frontier in order to bring the best options trading experience on-chain. Early Lyra contributors built the first options AMM and were among the first teams to deploy to Optimism Mainnet in 2020, as options margin on L1 was economically impractical. In 2023, the protocol was re-architected from an AMM-centric design to an orderbook with on-chain portfolio margin competitive with traditional finance. This institutional-grade portfolio margin required gas throughput not possible on Optimism Mainnet, leading to the launch of Derive Chain using the OP Stack with Conduit. Over the following two years, Derive introduced RFQ options, sub-ms matching engine latencies, significant TVL through partner custodians, and HYPE, ZEC and XAUT options markets.

These major architecture changes have brought Derive to where it is today. As of 7 September 2026, Derive represented approximately 95% of on-chain options premium volume over the preceding 30 days, based on DeFiLlama data. Derive also represents approximately $2 billion of open options interest against an estimated global total of roughly $40 billion.

However, as Derive has grown - so too has the number and types of users on the exchange. In particular, Derive is increasingly onboarding more sophisticated users and institutions. This presents a new set of growth opportunities and challenges around which we must once again re-architect the system.

V3 enables these major improvements:

  • Order of magnitude increase in throughput - comfortably handling hundreds of billions daily notional volumes with ability to support new, increasingly complex products and features.
  • Thousands of positions cross-margined in a single portfolio
  • Significantly faster development of new products and features
  • Improved retail and institutional user experience across EOA, Multi-sig, and MPC wallets.
  • A simplified integration experience for builders and institutional partners
  • Allow integrators to choose their own bridge infrastructure
  • A clear path to e2e privacy

In addition to the above architecture upgrades, several major protocol improvements will also ship in this initial release, with more planned for upgrades soon after launch:

  • Risk isolation/risk universes, enabling faster deployment of RWAs and diverse markets
  • Borrowing of non-cash assets (e.g. borrow ETH, WBTC, HYPE)
  • Cross currency margin for PM subaccounts (e.g. ETH + BTC PM)
  • Native 1-click vault deployments
  • Institutional-grade session key controls

As well strengthening the liveness and security of the protocol

  • Ethereum-native custody
  • No “Trusted Risk Assessors”: all protocol actions are always fully margined
  • Validity-proven state
  • Censorship resistant escape hatch, with forced inclusion of L1 actions
  • Minimal to no trade reverts

Terminology

V3 has three layers with very different trust properties. Much of this proposal turns on which layer is responsible for what.

  • Derive Exchange API: a fully centralized backend operated by Lyra Technologies Corp. Counterparty matching, the orderbook / RFQ, and KYC / compliance live here. Users interact with it over REST / WS.
  • Sequencer: operated by a Derive group entity designated by the Derive Foundation, but unopinionated: it must follow the rules imposed by the L1 Contracts. Its job is to compress transactions into batches that can be proven and processed on L1. It does not find counterparties, and it cannot forge orders or extend margin beyond the contract parameters.
  • L1 Contracts: the decentralized protocol layer, modifiable only through governance and the Owner powers described below. The protocol logic is written in Rust and executed inside the zkVM; a hash of the compiled program (the verifying key) is committed on-chain, which is what forces the sequencer to follow the protocol. Any actor can deposit, withdraw or trade against these contracts by bringing their own proofs.

The Derive Exchange API and Application will continue not to be available to US persons. These restrictions apply to access through the centralized Application and API and do not alter the permissionless nature of the L1 Contracts.

Specification

What is V3

Derive v3 is a zero-knowledge exchange: a high-performance matching engine paired with a sequencer whose every state transition is executed inside a zkVM and verified on the Ethereum L1.

Custody, proof verification, and withdrawals live in a small set of Solidity contracts. All compute-heavy logic, including margin, pricing and settlement, is executed inside the zkVM and proven off-chain. The Ethereum L1 only verifies the resulting proof: a flat ~400–500k gas, whether the batch holds one trade or a million. Every batch’s state diff is posted to Celestia for data availability, allowing for other providers to enable withdrawals in the case of the sequencer and api going offline. This provides users centralized-exchange latency on cross-margined spot, options and perpetuals, while maintaining user self custody, subject to the governance and emergency powers described below, and the ability to verify and exit against Ethereum.

Ultimately, the goal of the setup is to maximise efficiency and user experience, while at the same time achieving L2Beat Stage 1 classification.

Hybrid offchain matching but ZK-proven risk and settlement.

As in V2, matching happens off-chain. The engine crosses orders at sub-ms latencies and hands resulting fills to the protocol as an ordered stream. Nothing is final until the zkVM executes the stream and proves it, which is a requirement of any withdrawals. Complex portfolio margin and position settlement happens within the protocol written on top of the zkVM.

Custody and censorship resistance

User funds are escrowed in the L1 protocol smart contracts, that can only be redeemed given a proof-committed withdrawal digest. No operator, sequencer or prover key can move a token.

Because every state diff is posted to Celestia, anyone can rebuild state and prove a batch, and if the designated sequencer stops draining the Ethereum L1 action queue, submission reopens permissionlessly: a third party can take over settlement and keep withdrawals flowing without Derive’s cooperation.

The remaining trust assumptions are the owner, which can replace the committed state root or verifying key and upgrade the contracts, as well as the guardian powers described below.

A key feature enabling self-custody is the “escape hatch”. The L1 contracts enforce this with two mechanisms:

  • The sequencer is forced to process public actions in the Ethereum L1 action queue in order of submission. Thus, a sequencer cannot process any deposits unless requested withdrawals are first processed.
  • A minimum time period during which the sequencer must process a withdrawal (in the beginning set to 2 weeks). Once this time period elapses, anyone can permissionlessly “take over” the sequencer and propose new batches. Shortly after launch, the binary for the exchange will be posted publicly, which combined with Celestia DA, can be used to propose new batches.

Protocol Ownership Model

There are three roles on the protocol:

  • Sequencer: orders operations into batches and submits proofs and withdrawal digest outputs from the zkVM. Can be replaced permissionlessly if censors txs.
  • Guardian: refresh withdrawal throttles, to allow withdrawals to be processed more promptly, as well as a one way switch to block withdrawals
  • Owner: grants the powers to update the state root, setVKey, update proxies and unpause withdrawals

On launch, the protocol will be owned by a multisig controlled by Derive Subsidiary (BVI) Ltd, a wholly owned subsidiary of the Derive Foundation, with timelock protections and a 6-of-8 bypass.

Eventually, V3 ownership can be transferred from the Derive Subsidiary multisig to a fully autonomous on-chain governance system managed by stDRV holders. This will be covered in a follow-up proposal.

Migration Process

Migration of V2 → V3 will not be a redeposit. Derive Chain will be snapshot and scraped, and fully wound down promptly. Balances will be automatically seeded into the V3 genesis state, with the resulting root being written on-chain at launch. Users arrive in V3 with their balances, positions, ownership and session keys already in place.

DRV deploy

DRV staking (stDRV) and delegation will be deployed to Ethereum L1.

Similarly to DIP: Strategic Mint for Institutional Expansion, for technical reasons, the DRV token will be connected to Robinhood chain, minting new supply equaling the snapshot amount of DRV on Derive Chain (including stDRV balances). This token will be connected to the existing DRV token bridge network via the LayerZero liquidity layer, making it part of the existing supply. The supply remaining on Derive Chain will be orphaned. This orphaned supply will no longer form part of the canonical DRV supply.

This new supply then is bridged to L1, and sent as DRV or stDRV to the appropriate owners. Existing stDRV holders will have stDRV issued on ethereum mainnet directly. Voting delegations will be cleared.

Risk universe (RU) splitting

The V3 protocol allows for isolated risk universes. The one current V2 risk universe will initially be split into 4 categories for derivatives:

  • Prime: ETH, BTC
  • Mid cap: HYPE
  • Alt: SOL, ADA, XRP, ZEC, CC, LINK, DOGE, BNB, VVV, LIT, PUMP
  • RWA: XAUT

As well as a “fallback” universe, which doesn’t allow for derivatives or negative positions.

Collaterals will also be split as follows:

  • All: USDC, USDT, USDe, sUSDe, FXUSDC, wBTC, ETH, wstETH, DRV, SFP, spUSDC, spUSDT, AUSD, cbBTC
  • Prime: LBTC, WEETH
  • Mid cap: HYPE, kHYPE
  • Alt: SOL, jitoSOL, fXRP
  • RWA: XAUT

Any derivatives or collaterals not mentioned here are considered deprecated

Note, the v2 “BTC” currency will be split into “BTC” for perp and option, and “WBTC” for the collateral

Migration Timeline

  • Pending approval of this proposal, at least 14 days before the migration a migration notice will be published and announced on X, Discord and in-app. The notice will specify the expected migration timing, snapshot process and provide a link to a view only application that will show account state before and after the migration..
  • With 4 hours to go, bridges will be frozen, preventing funds moving, and allowing in-flight bridge transactions to be settled.
  • With 5 min to go, all trading will be halted, and then all uPnLs will be settled (perps, cash interest).
  • A target block will then be chosen as the final state of the chain, as well as blocks on all chains with vault tokens. Any transfers of vault shares or assets on Derive chain after this block will be ignored
  • V3 genesis state will be generated as per the next section
  • Once the V3 genesis state is generated, it will be added as the state root on the V3 L1 contracts.
  • Backend systems will be spun up with this genesis state, allowing trading to resume. Withdrawals will be blocked at this stage.
  • Over the course of the next few hours to two days, bridge balances that can be migrated easily will be sent to the V3 Spot Vaults, enabling most withdrawals. Some balances will require L2 native bridges to be used to migrate, taking up to an additional week.
  • Over the course of the week after launch;
    • stDRV balances, any Lyra migration balances over 10 DRV, and loose token balances will be sent directly to owners on L1
    • Any pending trading/staking rewards will be made claimable from a contract on Optimism until 1st Feb 2027, after which they will be reclaimed by the Derive Foundation.
    • V2 vault token holders will have underlying value paid out directly to them.

V3 genesis state

V3 parameters will be migrated to match the current V2 state, excluding any collaterals that have been deprecated. “BTC” will be split into “BTC” the derivative and “wBTC” the collateral.

Any deprecated derivative positions are force-closed at the mark price, and realised as USDC in the subaccount.

Any deprecated collaterals are removed from subaccounts, and any worth more than $1 will be distributed directly to the relevant owners as per the timeline above.

Any subaccounts with a total value less than $1 at this stage will be cleared.

PM subaccounts are already split per currency. They will be migrated 1:1 with any already deprecated collaterals removed.

SRM subaccounts will have to be split to fit into the risk universe model above. Algorithm is as follows:

  1. Realise any outstanding perp pnl and funding, as well as any outstanding cash interest
  2. Move all perps/options into new subaccounts, split as per RUs above
  3. Move any risk universe specific collateral into the new subaccounts, as per RUs
    1. Collateral supported by exactly one of the subaccount’s RUs moves there in full
    2. Collateral supported by several is split pro-rata by each RU’s maintenance margin requirement
    3. Collateral supported by none of them, but supported elsewhere, moves to the most senior RU that accepts it (Prime > Mid cap > Alt > RWA).
      1. E.g. accounts with BTC-PERP and HYPE collateral will be split into two.
    4. Collateral supported by no RU will be distributed to owners directly
  4. Drop dust. Any new subaccount that would hold only collateral, with an |MtM| less than $1 is not created, and its holdings are dropped and reported.
  5. Distribute USDC across the new subaccounts.
    1. Maximally borrow USDC against collaterals to create a pool of cash
    2. Distribute this pool of cash into subaccounts in the following order:
      1. Ensure all subaccounts have MtM >= 0
      2. Ensure all subaccounts have MM >= 0
      3. Ensure all subaccounts have IM >= 0
      4. At any point, if the pool cannot cover a step, distribute it pro-rata based on shortfall
      5. Anything left over after those steps is split equally
    3. Note, accounts should not be liquidatable based on this split if already previously solvent. In the case any non-trivial account are, the genesis will be paused, and V2 will resume operations

Security Module (SM) funds are treated differently:

  1. ~296k is removed from the SM to clear any USDC.e remaining in bridges on optimism/arbitrum. This is earmarked for ongoing runway expenses.
  2. If any risk universe has totalBorrows > totalSupply:
    1. Add SM funds to cover the deficit there first.
    2. In the case this isn’t enough to cover the shortfalls for risk universes, step 5.b.v will prioritise the risk universes that have shortfalls, and the entire genesis re-run (ratio moves 1% from each of the other 3 RUs, e.g. from 0.25:0.25:0.25:0.25 → 0.28:0.24:0.24:0.24, step by step until the shortfall is covered)
    3. If this fails, add new empty subaccounts in the shortfall’d risk universes that wallets did not previously own, and repeat the process from the beginning.
    4. In the case this cannot cover the shortfall, the genesis event will be paused, and V2 will resume operations
  3. Otherwise; or with any remainder after covering deficits, add funds to the security module of each risk universe in the ratio:
    1. Prime: 65%
    2. Hype: 20%
    3. Alt: 10%
    4. RWA: 5%

Note, due to conversion from 18 to 12 decimal places, rounding is applied to balances that have that much precision, while maintaining zero sum between longs and shorts

Subaccount ownership

Subaccounts will be owned by the same owner as in v2.

At the time of the snapshot, the chain of ownership will be confirmed and the ultimate owner will be granted ownership of the subaccount in v3

For a large majority of subaccounts this will follow the chain:

  • Matching.subaccountToOwner() → LightAccount
  • LightAccount.owner() → EOA owner

Gnosis safe owned wallets will be migrated to new wallets specified by the safe owners. If not specified in time, they will be handed to safes deployed to the same address on ethereum mainnet (6 wallets total holding value in subaccounts at time of this proposal)

Session keys

Session keys from V2 will be ported over to V3.

V2 admin keys will be migrated with the following protocol scopes:

  • Trade: All
  • Transfer: ExistingSubaccount
  • Transfer: NewSubaccount
  • Withdraw
  • Liquidate
    “Admin” and “Transfer: DifferentOwnerSubaccount” are deliberately not granted, so these keys cannot transfer to another wallet.

These keys will have their expiry capped to 28 days after the genesis.

Read only/account keys will be migrated with no protocol scopes, as read only keys, keeping their current expiry.

Order Reset

All trigger and TWAP orders in the v2 protocol will no longer be valid in the new v3 deployment. Users must make sure to re-submit their trigger and TWAP orders after the launch of v3.