Skip to main content

Roadmap

Development Cycle​

Flying Tulip's releases adhere to the following development cycle:

  1. Internal Development: the codebase is rapidly changed with ongoing audits.
  2. Code Freeze: the codebase is finalized.
  3. Independent Comprehensive Review: codebase passes through at least 3 independent audits.
  4. Go-to-market Preparation: the codebase is shaped as a product.
  5. Release: product reaches users.

An advance to a downstream item occurs only when upstream dependencies are stable and audited. This creates a waterfall path rather than hard calendar promises. Detailed breakdown and sequencing reflect those dependencies in the next sections.

Milestones​

Milestones execution and dependencies can be described by the following diagram:

Note: Each block is a fully-working product released independently. FT starts working as soon as the first product block is released, and each block adds more services to the FT offering.

dark-image light-image

Roadmap: release dependencies and milestones.

Right‑side items have a hard dependency on the left‑side items, e.g., CLOBAn exchange mechanism that matches bids and asks; integrated with Flying Tulip’s permissioned lending for cross‑collateralized trading while deposits continue to accrue.View glossary entry depends on ftUSDA delta‑neutral, yield‑bearing stable asset designed to target $1 while minimizing liquidation risk by balancing long/short exposures (e.g., supply/stake/borrow loops).View glossary entry.

Top items are executed first. Bottom items start only after the complete cycle for the item above it is finished. The numbers next to product names indicate delivery order, so 1 comes before 2.

Note: In the following sections, product mentions match their planned delivery order.

1. Public Sale​

An on‑chain raise where FT is minted as capital gets allocated. Capital Allocation comes together with on‑chain Perpetual PUTThe on-chain right attached to primary-issued FT that lets a holder: Hold (keep the FT NFT attached), Exit (Exit at par; return collateral), or Withdraw (unlock FT; invalidate the PUT; released backing capital can fund market buyback-and-burn of FT).View glossary entry. This step lays a foundation for a token‑first model and funds future development while preserving capital in conservative, liquid strategies.

2. Core Permissioned Trading Stack​

Permissioned release of core Flying Tulip products. This step demonstrates protocol mechanics under tighter controls and completes the audit cycle before expanding the surface area. "Permissioned" in this case refers to capped deposits, guarded launches, and approved asset lists.

  • Lend: Cross‑collateralUsing one deposit as collateral across multiple markets or products simultaneously (e.g., lending, CLOB, futures).View glossary entry pool that backs CLOBAn exchange mechanism that matches bids and asks; integrated with Flying Tulip’s permissioned lending for cross‑collateralized trading while deposits continue to accrue.View glossary entry orders and Futures while deposits continue to accrue.
  • ftUSD: Dollar‑target settlement railThe ftUSD settlement layer used to clear trades and transfers across products.View glossary entry that enables Futures, trading, and collateralAssets allowed as collateral and the maximum per‑asset size configured to manage concentration and risk.View glossary entry.
  • Leveraged Spot: Comes with dependency on Lend.
  • Spot: Price source and execution venue that feeds time and reserve‑weighted windows to downstream systems.
  • Perpetual Futures: Oracleless perpetual futuresFutures without expiration; Flying Tulip uses on‑chain trading as the primary price source with sub‑second settlement and funding tied to real borrowing costs.View glossary entry engine that settles to internal trading.
  • Futures and Options: Sequenced after perpetual futuresFutures without expiration; Flying Tulip uses on‑chain trading as the primary price source with sub‑second settlement and funding tied to real borrowing costs.View glossary entry once the stack is stable.

3. Core Permissionless Trading Stack​

Open access to the Flying Tulip core, which is mature and audited. Lift of "permissions" introduced in the previous step. Core Stack surfaces the same mechanics with market‑driven discovery and broader listings.

  • Volatility‑adaptive AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry: An adaptive curve shifts between constant‑sum and constant‑product based on implied volatility and emits depth‑aware windows used across Lend and Futures. See the Spot page.
  • Dynamic Lend: Every AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry pair exposes a lending market automatically. LTVs and liquidations remain depth‑aware.
  • Permissionless Futures and Options: Depth‑aware internal pricing extends to a wider set of markets. Futures settle in ftUSD.

4. Oracles & Applications Layer​

Proven pricing and settlement stack powers ecosystem apps and integrations.

  • WitnessnetA framework that lets smart contracts verify facts about HTTPS responses without a trusted oracle. Contracts receive (url, response data, proof) where the proof shows: AEAD‑authenticated TLS records under correctly derived traffic keys; Finished messages verified; and a valid server certificate matching the hostname with proven key possession (CertificateVerify). Any party can submit proofs, making "any HTTPS endpoint an implicit oracle."View glossary entry: Brings oracleless proofs for on‑chain verification of HTTPS data without third‑party oracles.
  • Binary prediction marketsYes/No markets that resolve based on verifiable facts. In Flying Tulip, resolution is permissionless via Witnessnet proofs of HTTPS pages from accepted sources (e.g., news sites). Any third party can submit proof to settle the market.View glossary entry: Resolve to facts proven via WitnessnetA framework that lets smart contracts verify facts about HTTPS responses without a trusted oracle. Contracts receive (url, response data, proof) where the proof shows: AEAD‑authenticated TLS records under correctly derived traffic keys; Finished messages verified; and a valid server certificate matching the hostname with proven key possession (CertificateVerify). Any party can submit proofs, making "any HTTPS endpoint an implicit oracle."View glossary entry from accepted domains such as CoinDesk and CoinTelegraph. Anyone can submit proof to resolve a Yes or No question.
  • LaunchpadThe token‑launch workflow. Teams create a token with thresholded deposits; when thresholds are met, the Spot + money market is deployed automatically. Anti‑MEV protections may apply initially. Leverage/futures unlock after an RWAP warm‑up period.View glossary entry: Token creation flow with threshold‑based launches and auto‑deployed AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entryAMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry plus a money marketA lending/borrowing venue where deposits accrue interest and loans are collateralized.View glossary entry. The initial launch window has anti‑MEVValue extracted by transaction ordering, inclusion, or exclusion within a block.View glossary entry protections. LeverageTrading with exposure greater than posted collateral; in FT futures, leverage constraints are set using depth‑aware metrics.View glossary entry and futures unlock after an RWAPA price metric that weights observations by available reserves near the path of execution, providing a depth‑aware benchmark for swaps.View glossary entry warm‑up.
  • Insurance: Provides pay‑as‑you‑go protection that behaves like a lending market, integrates with Lend for cross‑collateralUsing one deposit as collateral across multiple markets or products simultaneously (e.g., lending, CLOB, futures).View glossary entry, and uses AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry and CLOBAn exchange mechanism that matches bids and asks; integrated with Flying Tulip’s permissioned lending for cross‑collateralized trading while deposits continue to accrue.View glossary entry context for risk.

With the whole product vertical set, protocol revenue flows into FT buyback-and-burnA mechanism that buys FT on the open market and sends it to an irrecoverable address, permanently reducing supply. May be funded by backing capital yield surplus, protocol revenue/fees, or released backing capital from withdrawals.View glossary entry, reinforcing the token‑first model.

Timeline Expectations​

Note: Each block is a fully-working product released independently. FT starts working as soon as the first product block is released, and each block adds more services to the FT offering.

Assuming each stage, including development, freeze, audit, and launch preparation, averages 2 to 3 months, the full roadmap spans roughly 36 to 54 months (3 to 4.5 years), with downstream items beginning only after upstream milestones pass audits.

Brief Summaries​

The following products/features either lack their own documentation pages or include additional context here. Brief summaries are provided for clarity:

  • WitnessnetA framework that lets smart contracts verify facts about HTTPS responses without a trusted oracle. Contracts receive (url, response data, proof) where the proof shows: AEAD‑authenticated TLS records under correctly derived traffic keys; Finished messages verified; and a valid server certificate matching the hostname with proven key possession (CertificateVerify). Any party can submit proofs, making "any HTTPS endpoint an implicit oracle."View glossary entry accepts (url, response, proof) and validates AEADThe cryptographic mode used by the TLS record layer to provide confidentiality and integrity. In Witnessnet proofs, successful AEAD decryption/authentication under the derived traffic keys demonstrates that the response data is authentic for that session.View glossary entry‑authenticated TLS records, key derivation to traffic keys, finished verification, and certificate and hostname binding through CertificateVerifyA handshake step where the server proves possession of the private key corresponding to its certificate by signing the transcript. Witnessnet includes checks that the certificate is valid for the hostname and that CertificateVerify was verified.View glossary entry. Any HTTPS endpoint becomes an implicit oracleExternal feed of asset prices. Flying Tulip futures derive pricing/settlement from in‑house trading activity to avoid oracle lag/manipulation.View glossary entry.
  • LaunchpadThe token‑launch workflow. Teams create a token with thresholded deposits; when thresholds are met, the Spot + money market is deployed automatically. Anti‑MEV protections may apply initially. Leverage/futures unlock after an RWAP warm‑up period.View glossary entry is a simple token‑launch workflow with liquidity thresholding and staged unlocks for leverageTrading with exposure greater than posted collateral; in FT futures, leverage constraints are set using depth‑aware metrics.View glossary entryleverageTrading with exposure greater than posted collateral; in FT futures, leverage constraints are set using depth‑aware metrics.View glossary entry and futures after an RWAPA price metric that weights observations by available reserves near the path of execution, providing a depth‑aware benchmark for swaps.View glossary entry warm‑up.
  • Binary Prediction MarketsYes/No markets that resolve based on verifiable facts. In Flying Tulip, resolution is permissionless via Witnessnet proofs of HTTPS pages from accepted sources (e.g., news sites). Any third party can submit proof to settle the market.View glossary entry are "Yes" or "No" markets resolved permissionlessly via WitnessnetA framework that lets smart contracts verify facts about HTTPS responses without a trusted oracle. Contracts receive (url, response data, proof) where the proof shows: AEAD‑authenticated TLS records under correctly derived traffic keys; Finished messages verified; and a valid server certificate matching the hostname with proven key possession (CertificateVerify). Any party can submit proofs, making "any HTTPS endpoint an implicit oracle."View glossary entry proofs from approved domains. Accepted sources are configured per market.
  • Volatility‑Adaptive AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entryAMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry provides an adaptive curve that transitions between constant‑sum and constant‑product based on implied volatility with smoothing through EMAs and bounded shifts. It emits TWAPA time‑only averaging of price used in oracles and analytics; complements depth‑aware measures.View glossary entry, RWAPA price metric that weights observations by available reserves near the path of execution, providing a depth‑aware benchmark for swaps.View glossary entry, TWARA depth‑aware measure used in futures that considers how much of X can be sold for Y over time, enabling safer leverage and funding calculations.View glossary entry, and RVOLObserved volatility over a window, used to characterize market regimes.View glossary entry windows and supports concentrated and leveraged liquidityLP mode that behaves like full‑range coverage but concentrates more capital near the current price to improve fee capture without constant re‑ranges.View glossary entry. See the AMM page.
  • Options run on on‑chain Black–ScholesA widely used options pricing model for valuing calls and puts based on inputs such as underlying price, volatility, time to expiry, and interest rates. In Flying Tulip, on‑chain Black–Scholes uses implied volatility from AMM windows to quote premiums for covered calls and puts.View glossary entry model with implied volatility from AMMOn‑chain market using formulas instead of a central order book to quote prices and execute swaps.View glossary entry windows. They support covered call and put writing and later IV‑informed pricing.
  • The Cross‑CollateralUsing one deposit as collateral across multiple markets or products simultaneously (e.g., lending, CLOB, futures).View glossary entry permissioned venue is an institution‑oriented stack with reporting and OFACThe U.S. Office of Foreign Assets Control; referenced for compliance and sanctions constraints.View glossary entry controls. Deposits can back CLOBAn exchange mechanism that matches bids and asks; integrated with Flying Tulip’s permissioned lending for cross‑collateralized trading while deposits continue to accrue.View glossary entry orders, futures, and options under one risk engine.
  • Session KeysShort‑lived keys authorized by a user’s wallet to approve a bounded set of actions (e.g., trading). Enable smooth UX (no constant pop‑ups) while preserving withdrawal controls.View glossary entry and Wallet AbstractionUsing smart‑contract accounts and delegated keys to simplify wallet UX while preserving on‑chain security.View glossary entry provide Passkey and WebAuthn sign‑in and delegated session keysShort‑lived keys authorized by a user’s wallet to approve a bounded set of actions (e.g., trading). Enable smooth UX (no constant pop‑ups) while preserving withdrawal controls.View glossary entry for seamless UXThe overall experience of using a product, including ease, clarity, and flow.View glossary entry. State channelsOff‑chain execution channels that update balances with periodic on‑chain commitments. Used to enable continuous trading; channels cannot withdraw funds, which requires native signing.View glossary entry enable continuous trading while withdrawals remain on‑chain gated.