Flying Tulip
What is Flying Tulip?
Flying Tulip is an on‑chain financial system that standardizes pricing, credit, and risk across a suite of products, spot trading (AMM + CLOB), lending, perpetual futures, insurance, and a settlement rail (ftUSD). The design goal is straightforward: reuse the same unit of collateral across multiple functions, price risk from real executable liquidity rather than static tables or delayed oracles, and route system cashflows back to the token in a transparent, programmatic way.
“Better Yield” means capital efficiency, the same deposit can earn base yield while also securing lending, resting CLOB orders, or perp margin, plus a token‑first model that converts protocol revenues into buybacks (and, where specified, user distributions). “Better UX” means the mechanics are encoded in contracts and unified across products: the same depth‑aware prices feed trading, LTVs, funding, and liquidations; the same guardrails and change‑management apply everywhere.
The problems we address
Capital isolation. In most DeFi systems, each product silos collateral. You supply to a lending market, and that capital cannot simultaneously back orders or margin. Flying Tulip’s permissioned credit layer supports cross‑collateral so one deposit can secure multiple activities at once while still earning its base yield.
Fragmented liquidity and static pricing. Traditional AMMs (e.g., x·y=k
) are robust but static; they deliver wide spreads in calm markets and expose LPs to heavy divergence when volatility rises. Flying Tulip’s AMM uses a hybrid curve that leans constant‑sum in stable regimes (tight effective spreads) and leans constant‑product in stress (more curvature to protect LPs). Price and risk are computed from what the market can actually absorb, not just last prints.
USD‑only debt assumptions. Many lending markets implicitly force USD‑denominated views of risk. We support asset‑consistent borrowing and portfolio‑level cross‑margining in the permissioned pool, while permissionless markets remain pair‑scoped for simplicity.
Centralized dependencies. Perpetual futures often rely on external oracles with multi‑second ticks and governance bottlenecks. FT Perps settle to internal trading (AMM + CLOB) with sub‑second updates and depth‑aware limits, removing a class of oracle lag/manipulation risk.
System design
Trading engine: AMM + CLOB as the pricing spine
The AMM blends constant‑sum and constant‑product via regime signals (e.g., EMAs over price/dispersion). Pre‑trade simulation and guardrails enforce bounded impact and minimum reserves. A CLOB runs alongside for price‑time‑priority limit orders. The router sweeps CLOB liquidity first, then crosses residual flow against the AMM’s adaptive curve. The engine maintains both TWAP (time‑weighted average price) and RWAP (reserve‑weighted average price) windows; downstream systems consume these windows as the source of executable price and depth.
Lending: permissionless pairs and a permissioned cross‑collateral pool
- Permissionless Lend: every AMM pair exposes a lending market automatically. Borrowing power is size‑ and depth‑aware (from AMM/CLOB windows) rather than fixed tables; snapshot LTV is taken at open/adjust so rules don’t shift under live positions; liquidations are soft (time‑sliced, depth‑aware, CLOB‑aware).
- Permissioned Lend: curated assets share a single pool with cross‑collateral across Lend/CLOB/Perps. A debt‑netting mechanism enables delta‑neutral constructions (e.g., ftUSD) with near‑zero conventional liquidation paths under configured bounds. One deposit can earn money‑market yield while backing orders and perp margin simultaneously.
Perpetual futures: oracleless, depth‑aware
FT Perps use internal trading as the oracle. Leverage limits, liquidation sizing, and slippage guards are driven by TWAR‑family windows that ask, “how much of X could clear for Y over this interval without breaching reserves?” Funding links to actual borrowing costs in the Lend markets. Settlement is in ftUSD; opt‑in settlement LPs supply ftUSD and earn per‑settlement fees, with exposure balanced by pool policy.
Settlement rail: ftUSD / sftUSD
ftUSD is the dollar‑target settlement currency used across the system. It is non‑yielding by default (proceeds on unstaked ftUSD accrue to the protocol). Users who want yield stake to sftUSD and receive distributions via the pool’s accounting (variable; not guaranteed). The portfolio construction underpinning ftUSD targets dollar stability with delta‑neutral positioning and conservative sizing.
Risk & operations
The platform emphasizes unwind‑friendly positions and defense‑in‑depth controls:
- Policy: conservative allocations (no leverage, no bridging for treasury backing), per‑asset/venue caps, circuit breakers, and staged parameter changes.
- Execution: pre‑trade simulation, bounded fee schedules (lower in calm regimes, higher in stress), and soft liquidations that route through CLOB/AMM with time‑sliced clips.
- Transparency: addresses, parameters, windows (TWAP/RWAP/TWAR), utilization, and fee schedules are published; audits and incident processes are documented separately.
Programmatic value flow
Protocol cashflows (trading, lending, perps, insurance, settlement rails) feed a buyback pipeline for the FT token. Where policy specifies, bought FT is distributed to users via product programs; burns reduce supply directly. Revenue‑funded burns govern unlocks (Foundation/Team/Ecosystem/Incentives 40:20:20:20, one‑for‑one); interest‑only (backing carry) burns do not unlock; those simply reduce supply.
Why this architecture
By centering everything on executable liquidity and a shared risk model, Flying Tulip removes the guesswork between products: the AMM’s depth informs LTVs and liquidations; the same windows govern perp leverage and funding; the same deposit backs multiple activities; and the same cashflow rules route value back to the token. The outcome is a system that behaves consistently across markets and makes capital work once for several jobs, with the safety properties you need when conditions change quickly.