Derive
DeFi+1 · Layer-1+1Token Transparency Filing
Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Derive is built to bring options and more advanced derivatives trading onchain in a way that is
more usable, capital efficient, and institutionally relevant than earlier onchain models. It addresses limitations such as wide spreads, fragmented liquidity, and poor support for larger or more sophisticated trades.
(b) Operational priorities
Derive’s operational priority is to support ongoing protocol development, liquidity quality,
integrations, and market expansion through continued work on infrastructure, execution, and governance-led treasury deployment.
(c) High-level project overview
At a high level, Derive combines onchain settlement, collateral management, and risk controls
with a higher-performance execution layer, including an orderbook and RFQ system, to support options and related trading products.
(d) Primary token functions
DRV is the governance token of the ecosystem. Its primary functions are governance
participation, staking into stDRV for proposal and voting rights, and alignment with protocol-level economic mechanisms such as treasury and fee-related decisions.
(e) Control surface reliance
Derive currently relies on tokenholder governance implemented through the existing governance framework and associated administrative controls. That control surface may continue to evolve over time through governance as the protocol matures.
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
Nick Forster | Labs | CEO, Co-Founder | ex-Susquehanna, Professional options trader |
Hitesh Donga | Labs | Head of Product | ex-Paradigm |
Josh Kim | Labs | Head of Engineering | ex-Apple |
Sean Dawson | Labs | Head of Research | PhD qualified Quant |
Andras Caron | Labs | Head of Marketing | ex-Deribit |
Dominic Romanowski | Foundation | Co-Founder | Blockchain engineering expert |
Ian Randle | Foundation | Head of Operations | ex-Consultancy and entrepreneur |
Blockworks note: Labs/DevCo |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The DAO is the governance body for the Derive ecosystem. The Derive Foundation serves as
the legal-world steward for IP and DAO implementation. The Foundation, rather than the DAO as an unincorporated body, is the practical holder and steward of protocol-related intellectual property, including the brand and broader protocol stack.
(b) Contract/admin powers
Governance is exercised through DAO Vote under the Governance Protocols. stDRV holders can participate in proposals and voting, and approved proposals are implemented through the protocol’s execution framework. The Foundation represents the DAO in legal and operational matters, and certain protocol parameters and treasury assets are administered through the BVI subsidiary in accordance with DAO-approved outcomes and the Foundation bylaws.
(c) Locked-token rights (conditional)
Staking DRV into stDRV gives holders governance rights, including proposal and voting rights. Tokenholders with stDRV can participate in governance, but governance powers remain subject to the governance framework, execution delays, and any administrative safeguards currently in place.
(d) Value accrual & holder rights
DRV holders govern current fee-related parameters and broader treasury decisions through governance. 35% of protocol revenue is currently allocated to DRV buybacks. The balance of current net-fee allocation is directed to the onchain insurance fund.
(e) Dissolution authority
The DAO is an onchain governance system and is not itself a separate legal entity capable of
being wound up in the same manner as a company. As a practical matter, any deactivation, migration, or replacement of the DAO’s governance powers would occur through DAO Vote under the governance protocols. The Derive Foundation, as the primary legal wrapper, may be wound up by Special Resolution of the Foundation, meaning a resolution passed by not less than a two-thirds majority of the votes cast by persons entitled to vote at a general meeting. The person designated in that Special Resolution acts as liquidator, or if none is designated, the directors or such person as they appoint act as liquidator. Any surplus assets left after paying its debts must be used for the Foundation’s stated purposes, and if it is not used that way, it goes to charitable purposes instead.
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The primary foundation is the Derive Foundation, a Cayman Islands foundation company. This
entity serves as the legal-world steward for the Derive ecosystem.
(b) IP ownership & control
The Foundation is the steward of the protocol’s intellectual property stack and broader legal-world rights associated with the ecosystem, rather than those assets sitting in a contributor-owned operating company. The Foundation may also interface with subsidiary or affiliated entities used for ecosystem operations, token administration, or strategic activities.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Foundation does not have free-standing discretion to direct DAO governance or DAO Treasury assets. Governance is exercised through DAO Vote under the Governance Protocols, which set proposal eligibility, voting thresholds, quorums, and implementation mechanics. The Foundation and its subsidiaries act as the legal and operational wrapper that implements those DAO Votes, subject to fiduciary duties, applicable law, and the Foundation’s constitutional documents. In practice, protocol parameters and the relevant DAO treasury assets approved for transfer are operated through the BVI subsidiary’s 3 of 5 multisig wallet. Those assets are held and administered solely for DAO approved purposes. The Foundation may maintain a reasonable operating budget from general funds, but token reserves designated for issuance and certain treasury limits require DAO Vote.
(d) Powers over DevCo
The Foundation can exert influence over the DevCo only to the extent provided by contractual
relationships, governance-approved service arrangements, or shared operational coordination. The Foundation does not own the DevCo.
(e) Contract/admin powers
The Foundation’s corporate powers are managed by or under the control of the directors, subject to the Memorandum, Articles, and Bylaws. The directors may delegate powers to committees, agents, attorneys, or authorised signatories under the Articles. The Foundation also acts within the DAO governance framework set out in the Bylaws, under which the directors are required to observe, implement, carry out, action, and execute DAO Votes with best efforts, subject to fiduciary duties, applicable law, and the Foundation’s constitutional documents. Operationally, certain Foundation-controlled actions are implemented through a 3/5 multisig.
(f) Current economic arrangements and distribution policies
The Foundation may receive or administer protocol-controlled resources, treasury assets, or strategic allocations where governance-approved or programmatically defined. However, Derive Labs equityholders do not have a direct claim on protocol revenue, treasury assets, or protocol IP by virtue of their equity. Current governance-approved or programmatic allocations include protocol-fee-directed buybacks and treasury / incentive programs as adopted by governance.
Blockworks note: Derive has a primary foundation, Derive Foundation.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The primary DevCo is Derive Labs Corporation, a Delaware C-Corporation in the United States
It serves as the contributor-owned development company that supports the Derive ecosystem.
(b) IP ownership & control
Derive Labs does not own the protocol IP, treasury, or brand IP by virtue of being the contributor operating company. It is a service provider and coordination entity for ongoing protocol support and development.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Derive Labs does not have an equity-based claim on protocol revenue, treasury assets, or protocol IP. To the extent it has any operational role, that comes from contributor work, service-provider relationships, or governance-approved implementation roles rather than inherent rights over DAO governance or treasury.
(d) Powers over Foundation
Derive Labs does not have formal ownership-based power over the Foundation. Any influence
would arise from shared contributors, service arrangements, or practical coordination rather than from the DevCo controlling the Foundation.
(e) Contract/admin powers
Derive Labs is not the legal owner of protocol IP and does not hold unilateral formal pause, upgrade, or governance-executor powers by virtue of being the DevCo.
(f) Current economic arrangements and distribution policies
Derive Labs is a contributor-owned service company. It may receive payment for services rendered under contractual or operational arrangements, but it does not have a separate contractual claim on protocol revenue, treasury assets, or protocol IP by virtue of its equity. It is not intended to receive protocol economic upside through dividends or similar equityholder distributions sourced from protocol economics.
Blockworks note: Derive has a primary DevCo, Derive Labs.
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
LYRA launched with a total supply of 1,000,000,000. DRV later migrated LYRA and stkLYRA
holders on a 1:1 basis and current total DRV supply is 1,500,000,000 following the October 2025 strategic mint. At DRV launch, the token had the same total supply as LYRA, with an additional launch airdrop / migration framework applied on top of that transition.
(b) Recipient categories & use of funds
At LYRA launch, allocation was as follows:
- DAO, 20%: ecosystem development and DAO-controlled growth
- Core Team, 20%: contributor alignment and retention
- Investors, 10%: early backers and strategic support
- Liquidity Rewards, 15%: incentivizing LP participation
- Trading Rewards, 15%: incentivizing protocol trading activity
- Security Module, 10%: backstop / protocol risk support
- Token Liquidity, 5%: initial token market liquidity
- Community Incentives, 3%: community growth and ecosystem programs
- SNX Stakers, 2%: incentives tied to early ecosystem alignment. At DRV launch, the launch process included:
- 7.71% of new DRV supply airdropped to protocol users and partners
- 56.38% of existing LYRA supply migrated 1:1 to DRV, including migration bonuses.
(c) Initial price per token (if applicable)
No fixed TGE token offering price was set in the DRV migration / launch process in the manner of a priced public sale.
(d) Ticker / market symbol
DRV
(e) Total supply & supply regime
DRV currently has a total supply of 1,500,000,000. The supply is governance-adjustable rather
than fixed, as governance previously approved an increase from 1,000,000,000 to 1,500,000,000 in October 2025. DRV does not currently have an automatic inflation or deflation schedule, so any future supply change would require further governance approval.
(f) Initial vesting / release schedules
Under LEAP-7, core team tokens were, in almost all cases, locked for six months from
contributor start date and then vested linearly over two years. Investor tokens were locked until 2022-01-01 and then vested linearly over two years, with final unlock on 2024-01-01. Separately, the October 2025 strategic mint allocated 260 million DRV to continuing and future contributors, subject to a six-month cliff and vesting over four years and subject to market cap and liquidity gating conditions.
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
- Executed airdrop: Derive has already conducted an airdrop process associated with the DRV launch. Covered user segments included Derive protocol users and partners. The allocation method was based on an eight-month points program running from 2024-05-08 to 2025-01-13, with users rewarded based on protocol actions and participation.7.71% of new DRV supply was airdropped to Derive users and the launch process also included a 1:1 migration of LYRA supply into DRV with migration bonuses. Users could also stake DRV for a one-time 25% airdrop bonus. Derive has publicly described the eligibility mechanics and participation framework.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
- Market Maker Name: Auros
- Token Allocation Committed: 20,000,000
- Term Duration: Expires July 2026
- Structure Name: Loan
- Market Maker Name: Skynet
- Token Allocation Committed: 6,000,000
- Term Duration: Rolling
- Structure Name: Loan
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
- Exchange Name: Gate.io
- Token Allocation Committed: 1,000,000
- Term Duration: None
- Native Token Listing Fees: None
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (c) Date of sale (at least month & year)
- (d) Number of tokens sold (or % of total supply)
- (e) Vesting schedule
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
- Series Name: Seed
- Date Of Sale: July 2021
- Number of tokens sold: 6.6%
- Vesting Schedule: Fully vested
- Series Name: Investment - Ethena
- Date Of Sale: December 2024
- Number of tokens sold: 5%
- Vesting Schedule: Fully vested
- Series Name: Variant
- Date Of Sale: March 2026
- Number of tokens sold: Private
- Vesting Schedule: Private
Blockworks note: Lyra publicly announced a $3.3 million raise in July 2021, co-led by Framework Ventures and ParaFi Capital, with support from additional named participants. Derive later publicly disclosed the Ethena-related strategic transaction and the Variant-related transaction described above. Derive does not publicly disclose confidential commercial terms of historical private token sales, OTC transactions, or similar arrangements beyond what is already public.
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(f) References (optional)
Blockworks note: No exploits affecting tokenholders or protocol funds have occurred as of April 2026.
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
Derive operates in a legal and regulatory environment that may change over time. Evolving laws, regulations, enforcement priorities, or tax interpretations in key jurisdictions could affect token availability, user access, exchange support, entity operations, or the practical implementation of governance decisions. Users and tokenholders are responsible for understanding their own legal and tax obligations. Derive may also restrict or limit access in certain jurisdictions or for certain user categories, and such restrictions may change over time.
(b) Protocol, Technology & Security Risks
Derive depends on smart contracts, onchain settlement logic, risk engines, administrative safeguards, and external dependencies such as infrastructure, oracles, and execution components. Bugs, design flaws, implementation errors, or failures in these components could lead to disruption, degraded execution, or loss of funds. Audits, internal review, and security processes reduce risk but cannot eliminate all possible failures, particularly those arising from novel interactions, market stress, or external dependencies.
(c) Token Economics, Unlocks & Incentive Risks
DRV’s utility and governance role depend in part on assumptions around protocol activity, fee generation, incentive effectiveness, and governance participation. Governance can change parameters such as fee allocations, emissions, unstake periods, and incentive programs, and these changes may adversely affect tokenholders. Changes in token supply, unlocks, treasury deployment, or incentive design may also affect market dynamics, liquidity, and perceived value. Current governance materials already show that governance may revise buyback percentages, staking emissions, and unstake periods over time.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Derive is solely responsible for the content, accuracy, and legality of its disclosures.
