====
docs/index.md

---
id: welcome
title: Welcome
slug: /
description: Better Yield, Better UX
image: docs-og.png
layout:
  width: wide
  title:
    visible: true
  description:
    visible: false
  tableOfContents:
    visible: true
  outline:
    visible: true
  pagination:
    visible: false
  metadata:
    visible: true
sidebar_position: 1
---

This hub connects you to everything you need to understand, use, and build with Flying Tulip's DeFi ecosystem. Whether you're a curious newcomer, an active user, or a developer looking to integrate with our protocols, you'll find the resources you need right here.

Our documentation is designed to make advanced DeFi concepts accessible to everyone while providing the technical depth that builders require. Explore product explanations written in plain language, step-by-step guides for using our platforms, comprehensive technical references for developers, and everything in between.

## What You'll Find Here

- **Product Overviews**: Clear, straightforward explanations of Flying Tulip's financial products
- **User Guides**: Practical tutorials on how to use our platforms to maximize capital efficiency
- **Developer Resources**: SDK references, API documentation, and integration guides to build with and integrate Flying Tulip
- **Community & Support**: Links to our websites, blogs, social channels, and support resources
- **Design & Branding**: Guidelines and assets for partners and content creators

We've designed this documentation site to grow with you. Start with the basics and progress to advanced topics as you become more familiar with our ecosystem. Our mission is to make DeFi accessible to everyone, and that begins right here with education.

Choose a section from the navigation to begin your journey with Flying Tulip.

<div className="product-grid product-grid--welcome glossary-tooltips-disabled">
  <a href="product-suite/" className="product-card">
    <img src="/img/FlyingTulip_Product.webp" alt="Flying Tulip product overview" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Product Overview</strong>
      <p>Get to know the Flying Tulip ecosystem and how it operates.</p>
    </div>
  </a>
  <a href="capital-allocation/" className="product-card">
    <img src="/img/FlyingTulip_App.webp" alt="Flying Tulip capital allocation" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Capital Allocation</strong>
      <p>Learn more about the Capital Allocation event</p>
    </div>
  </a>
</div>
====
docs/brand/index.mdx

---
title: Brand Kit
image: docs-og.png
description: Brand assets for Flying Tulip partners
---

import {useEffect, useRef, useState} from 'react';
import useBaseUrl from '@docusaurus/useBaseUrl';

export function CopyHex({ value }) {
  const [copied, setCopied] = useState(false);
  const timeoutRef = useRef(null);

  const handleClick = (event) => {
    event.preventDefault();

    const canCopy =
      typeof navigator !== 'undefined' &&
      navigator.clipboard &&
      typeof navigator.clipboard.writeText === 'function';

    const showCopied = () => {
      setCopied(true);
      if (timeoutRef.current) {
        clearTimeout(timeoutRef.current);
      }
      timeoutRef.current = setTimeout(() => setCopied(false), 2000);
    };

    if (canCopy) {
      navigator.clipboard
        .writeText(value)
        .then(showCopied)
        .catch(() => {
          if (typeof window !== 'undefined') {
            window.prompt('Copy this colour value:', value);
          }
          showCopied();
        });
      return;
    }

    if (typeof window !== 'undefined') {
      window.prompt('Copy this colour value:', value);
    }
    showCopied();
  };

  useEffect(() => () => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current);
    }
  }, []);

  return (
    <span
      style={{
        display: 'inline-flex',
        alignItems: 'center',
        justifyContent: 'flex-start',
        gap: '0.5rem',
      }}
    >
      <button
        type="button"
        onClick={handleClick}
        style={{
          border: '1px solid var(--ifm-color-emphasis-200)',
          background: 'var(--ifm-background-color)',
          borderRadius: '0.375rem',
          color: 'var(--ifm-color-primary)',
          cursor: 'pointer',
          fontFamily: 'var(--ifm-font-family-monospace)',
          fontSize: '0.85rem',
          lineHeight: 1.4,
          padding: '0.15rem 0.5rem',
        }}
      >
        {value}
      </button>
      {copied && (
        <span style={{fontSize: '0.8rem', color: 'var(--ifm-color-success)'}}>
          Copied!
        </span>
      )}
    </span>
  );
}

export const AssetLink = ({href, children}) => {
  const url = useBaseUrl(href);
  return (
    <a className="product-card__link" href={url}>
      {children}
    </a>
  );
};

export function BrandCard(props) {
  const {
    image,
    alt,
    title,
    description,
    footer,
    children,
    footerAlign = 'center',
    cover,
  } = props;

  const hasCover = Boolean(image) || Boolean(cover);

  const cardClasses = ['product-card', 'brand-card'];
  if (!hasCover) {
    cardClasses.push('brand-card--no-image');
  }

  const footerClasses = ['product-card__footer'];
  if (footerAlign === 'start') {
    footerClasses.push('product-card__footer--start');
  }

  const coverNode = cover
    ? cover
    : image
    ? <img src={image} alt={alt || title} loading="lazy" />
    : null;

  return (
    <div className={cardClasses.join(' ')}>
      {coverNode ? (
        <div
          className={
            image ? 'brand-card__preview' : 'brand-card__preview brand-card__preview--custom'
          }
        >
          {coverNode}
        </div>
      ) : null}
      <div className="product-card__content">
        <strong>{title}</strong>
        {description ? <p>{description}</p> : null}
        {children}
      </div>
      {footer && (
        <div className={footerClasses.join(' ')}>
          {footer}
        </div>
      )}
    </div>
  );
}

## Logo

Our core identifier, in three colour modes.

<div className="product-grid product-grid--suite">
  <BrandCard
    title="Logo: Dark"
    description="Primary Logo for use on light backgrounds."
    image="/img/FlyingTulip_Logo_Dark.webp"
    alt="Flying Tulip Logo Dark"
    footer={
      <>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Dark.svg">SVG</AssetLink>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Dark.png">PNG</AssetLink>
      </>
    }
  />
  <BrandCard
    title="Logo: Purple"
    description="Primary Logo for use on light and dark backgrounds."
    image="/img/FlyingTulip_Logo_Purple.webp"
    alt="Flying Tulip Logo Purple"
    footer={
      <>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Purple.svg">SVG</AssetLink>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Purple.png">PNG</AssetLink>
      </>
    }
  />
  <BrandCard
    title="Logo: Light"
    description="Primary Logo for use on dark backgrounds."
    image="/img/FlyingTulip_Logo_Light.webp"
    alt="Flying Tulip Logo Light"
    footer={
      <>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Light.svg">SVG</AssetLink>
        <AssetLink href="/assets/Logo/FlyingTulip_Logo_Light.png">PNG</AssetLink>
      </>
    }
  />
</div>

## Symbol: The Tulip

The Tulip symbol, in three colour modes.

<div className="product-grid product-grid--suite">
  <BrandCard
    title="Symbol: Dark"
    image="/img/FlyingTulip_Symbol_Dark.webp"
    alt="Flying Tulip Symbol Dark"
    footer={
      <>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Dark.svg">SVG</AssetLink>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Dark.png">PNG</AssetLink>
      </>
    }
  />
  <BrandCard
    title="Symbol: Purple"
    image="/img/FlyingTulip_Symbol_Purple.webp"
    alt="Flying Tulip Symbol Purple"
    footer={
      <>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Purple.svg">SVG</AssetLink>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Purple.png">PNG</AssetLink>
      </>
    }
  />
  <BrandCard
    title="Symbol: Light"
    image="/img/FlyingTulip_Symbol_Light.webp"
    alt="Flying Tulip Symbol Light"
    footer={
      <>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Light.svg">SVG</AssetLink>
        <AssetLink href="/assets/Symbol/FlyingTulip_Symbol_Light.png">PNG</AssetLink>
      </>
    }
  />
</div>

## Typography

Three typefaces, each with a distinct role.

Use of GT Ultra requires a license, for all other fonts visit [fonts.google.com](https://fonts.google.com).

<div className="product-grid product-grid--suite">
  <BrandCard
    title="GT Ultra Fine"
    description="Primary typeface used for headlines."
    image="/img/FlyingTulip_Typography_GTUltra.webp"
    alt="GT Ultra sample"
  />
  <BrandCard
    title="Inter"
    description="Support typeface used for body copy."
    image="/img/FlyingTulip_Typography_Inter.webp"
    alt="Inter sample"
  />
  <BrandCard
    title="Geist Mono"
    description="Technical font used for Code."
    image="/img/FlyingTulip_Typography_GeistMono.webp"
    alt="Geist Mono sample"
  />
</div>

## Colors

Our colour palette, a mono foundation with purple hues.

<div className="product-grid product-grid--suite">
  <BrandCard
    title="Purple"
    description="For use as a pop colour, to highlight and guide."
    footerAlign="start"
    footer={<CopyHex value="#7559FF" />}
    cover={
      <div
        className="brand-card__swatch"
        style={{backgroundColor: '#7559FF'}}
        role="img"
        aria-label="Purple colour swatch"
      />
    }
  />
  <BrandCard
    title="Black"
    description="A black and white foundation for typography and backgrounds."
    footerAlign="start"
    footer={<CopyHex value="#000000" />}
    cover={
      <div
        className="brand-card__swatch"
        style={{backgroundColor: '#000000'}}
        role="img"
        aria-label="Black colour swatch"
      />
    }
  />
  <BrandCard
    title="White"
    description="A black and white foundation for typography and backgrounds."
    footerAlign="start"
    footer={<CopyHex value="#FFFFFF" />}
    cover={
      <div
        className="brand-card__swatch"
        style={{backgroundColor: '#FFFFFF'}}
        role="img"
        aria-label="White colour swatch"
      />
    }
  />
</div>
====
docs/capital-allocation/index.md

---
title: Capital Allocation
sidebar_position: 2
image: docs-og.png
description: Allocation logic in Flying Tulip ecosystem
---

Flying Tulip is opening its raise to the public to broaden participation in the project’s financing. This follows our $200 million private round and sets the stage for a transparent, on-chain program that’s straightforward and fully auditable.

## What You Get to Start

Commit $1 in capital: Receive 10 FT[^1]

Fixed Supply, No Inflation

FT has a maximum supply of 10 billion, minted at deployment. Capital Allocation distributes FT at 10 FT per \$1 committed (implied \$0.10) from this fixed supply. If \$500m is committed, 5B FT are allocated, and the remaining 5B FT stay in the Investment Contract (Perpetual PUT reserve) as non-circulating supply. `totalSupply` stays at 10B, only the split between circulating and non-circulating supply changes. There is no vesting, no future inflation, and no additional minting.

Contributions are made through [flyingtulip.com](https://flyingtulip.com) and settle to the Investment Contract.

> **Note:** The address for the Investment Contract will be finalized in‑app. Always verify the address shown in the Invest UI before sending funds.

When your contribution settles, your FT is issued as a Perpetual PUT that grants a standing on-chain Exit at par right to your primary-issued FT. You can **Hold**, **Exit**, or **Withdraw**, whichever best fits your plan or reaction to market conditions.

## Your Perpetual PUT Position - How Does it Work?

![dark-image](/img/PUT_Option_Mechanisms_Dark.webp#dark-mode-only)
![light-image](/img/PUT_Option_Mechanisms_Light.webp#light-mode-only)

<p className="image-caption">Perpetual PUT lifecycle.</p>

**Market buyers:** FT purchased on the open market does not include a Perpetual PUT. The Perpetual PUT is attached only to FT issued to primary contributors during the Private and Public Sale.

> **Note:** You can trade Perpetual PUT Options on the [ftPUT Marketplace](/product-suite/ftput-marketplace).

When your contribution mints FT, that FT is locked into your Perpetual PUT. From there, you always have three choices (and you can mix them over time in any proportions you like):

### 1. **Hold**: Keep your position and capital protection active

Do nothing and keep your Exit right. You participate in all FT appreciation while maintaining the ability to Exit at par whenever you choose. There are no trigger dates, no cliffs, the right is evergreen.

### 2. **Exit**: Exit at par for your original asset

Exit some or all of the exact asset and amount you originally committed. Exits can be partial and repeated.

Par asset return. Exit at par returns the same asset and the same amount you originally contributed.

So if you contributed 1,000 USDC and received a Perpetual PUT with 10,000 FT, then you can Exit at par for 1,000 USDC.

Or, if you contributed 2 ETH (1 ETH = \$3,840) and received a Perpetual PUT with 76,800 FT, then you can Exit at par for 2 ETH.

> **Note:** You get back the exact asset and amount you originally put in.

### 3. **Withdraw**: Access your FT and destroy your Perpetual PUT

If you want to directly hold, trade, or use your FT, you can withdraw it.

> **Note:** Withdraw invalidates the Perpetual PUT on that portion forever.

The original backing capital reserved for your Exit at par is released and used by the protocol for market buyback-and-burn, benefiting everyone who remains.

### Exit vs. Withdraw

> **Note:** FT bought on the open market does not include a Perpetual PUT.

**Exit (Exit at par)**: You get back the exact asset and amount you originally put in. Your Perpetual PUT is used on that portion, and the backing capital is returned to you (no buyback).

**Withdraw (Unlock FT)**: You take a portion or all of your FT out of the Perpetual PUT but your Perpetual PUT on that portion is invalidated. The reserved backing capital is released and used by the protocol to fund market buyback-and-burn of FT.

> **Note:** Withdraw triggers buyback-and-burn funded by the released backing capital.

**USDC Example:** Exit at par: Contribute 1,000 USDC → receive 10,000 FT. Later Exit at par with 10,000 FT → receive 1,000 USDC.

**USDC Example:** Withdraw & sell above par: Contribute 1,000 USDC → receive 10,000 FT. Withdraw 10,000 FT (PUT invalidated), then sell on the market at, say, \$0.15; the released backing capital is used by the protocol to fund market buyback-and-burn of FT over time.

**ETH Example:** Exit at par: Contribute 2 ETH → receive 76,800 FT (1 ETH = \$3,840). Later Exit at par with 76,800 FT → receive 2 ETH.

**ETH Example:** Withdraw & sell above par: Contribute 2 ETH → receive 76,800 FT (1 ETH = \$3,840). Withdraw 76,800 FT (PUT invalidated), then sell on the market at, say, \$0.15; the released backing capital is used by the protocol to fund market buyback-and-burn of FT over time.

> **Note:** You get back the exact asset and amount you originally invested.

**Illustrative scale effects.** If a meaningful share of holders withdraw, released backing capital can retire large amounts of FT via buyback-and-burn. For example, at a \$0.10 average buyback price, \$100m of released backing capital can retire roughly 1.0 billion FT; \$250m can retire \~2.5 billion FT; $500m can retire \~5.0 billion FT.

### Selling or transferring FT

To sell or transfer FT you first withdraw it from your Perpetual PUT. Withdraw permanently invalidates the Perpetual PUT on that portion. The backing capital that had been reserved for your Exit at par is released to fund market buyback-and-burn of FT. The buyer on the market does not receive a Perpetual PUT.

### Distributions to users

A portion of protocol revenue/fees is used to buy FT on the market and distribute those tokens to users as defined by product‑level programs (separate from burns). Exact shares and schedules are shown in each product’s UI and on the Token page. Revenue‑funded burns still govern Foundation/Team/Incentives unlocks (40:40:20).

## Where Your Capital Goes

![dark-image](/img/Raise_Capital_Allocation_Dark.webp#dark-mode-only)
![light-image](/img/Raise_Capital_Allocation_Light.webp#light-mode-only)

<p className="image-caption">Contributed capital allocation flow.</p>

Less Risk. More Transparency.

Backing capital itself is never spent. While your Perpetual PUT is open, contributed assets are kept liquid and deployed to low‑risk on-chain yield with no leverage and no bridging (e.g., Aave v3 for major stables, stETH for ETH, jupSOL for SOL, AVAX staking for AVAX, sUSDe for USDe). This keeps the program conservative and unwind‑friendly. Prioritizing safety and liquidity may result in lower yields than riskier strategies, by design, so that Exits at par can be honored quickly in all conditions.

**Priority of backing capital yield:**

1. **Ecosystem development first.** The first call on the backing capital yield is to fund the ongoing development of the ecosystem, infrastructure and operations.
2. **All surplus to buyback-and-burn.** Any remaining backing capital yield after the ecosystem budget is met is used for continuous buyback-and-burn of FT.

**Protocol revenue and fees** from Flying Tulip’s entire suite of products (ftUSD, settlement rails, lending, derivatives, spot, permissionless markets, insurance) are also routed to buyback-and-burn; and govern the unlocking of Foundation/Team/Incentives allocations using a 40:40:20 split.

* Buyback-and-burn funded by revenue unlock.
* Buyback-and-burn funded solely by backing capital yield does not trigger unlocks.

For the full backtests, formulas, and sensitivity math, see the Technical Appendix.

**Safety first (and the trade‑off):**

Backing capital is kept in safe, liquid positions (no leverage, no bridging) so Exits at par can be honored quickly. This may result in a lower yield than riskier strategies, by design. In synchronized Exit waves, some positions (e.g., LST withdrawals) can introduce timing delays; we size and diversify to minimize this.

## Unlock Mechanics

Unlocks are revenue‑linked. Buyback-and-burn funded by project revenue unlocks Foundation/Team/Incentives 1:1 (40:40:20). Buyback-and-burn funded only by backing capital yield does not unlock anything; they just reduce supply.

## How to Participate

1. Visit [flyingtulip.com](https://flyingtulip.com) and connect a supported wallet.
2. Choose an accepted asset (addresses below) and contribute to the Investment Contract.
3. Receive FT at 10 FT per $1 contributed, issued into your Perpetual PUT.
4. Manage your position over time: **Hold**, **Exit**, or **Withdraw**, all on-chain and reflected in the public buyback-and-burn ledger.

## Why This Structure Works

100% Capital Protection.

The structure is designed to reduce investor risk, preserve capital, and align incentives:

* The Perpetual PUT or evergreen Exit at par right provides a floor at par, with no cliffs or lockups
* Backing capital works continuously in conservative strategies rather than being spent, so that yield accrues immediately
* Revenue-linked operations and costs ensure team and foundation liquidity expands only when real cash flow is buying back FT, not up front
* Withdrawals create path‑dependent scarcity: released backing capital funds additional buyback-and-burn for the benefit of remaining holders.

## Risks to understand

* **Liquidity timing during stress.** Some backing capital positions (e.g., stETH, jupSOL, AVAX) may require exit queues or unbonding. Exposures are sized for timely unwinds, but synchronized exits can still slow settlement.
* **Peg/basis and yield variability.** Components like sUSDe (basis/funding dependent) and newer stables can experience yield compression or adverse basis moves.
* **Protocol/validator risk.** Smart‑contract, validator, and MEV‑economics risks exist in all integrated systems (Aave, LSTs, staking).
* **Regulatory risk.** Policy changes around stablecoins and staking can affect the backing capital mix or operations.
* **Investor trade‑offs.** Secondary buyers do not receive a Perpetual PUT. Primary buyers who hold near-par for long periods may incur opportunity costs relative to higher‑risk strategies.
* **Exit timing.** In heavy Exit windows, some backing capital components (e.g., LST exits, validator unbonding) can introduce delays. Allocations are sized for fast unwinds, but synchronized exits can still slow settlement

> **Note:** This page is informational and not investment advice. Yields are variable and not guaranteed.

## Accepted Assets & Chains

> **Note:** Always confirm these addresses in the Invest UI at the time of contribution.

### Ethereum

| Token     | Address                                      |
| --------- | -------------------------------------------- |
| **USDT**  | `0xdAC17F958D2ee523a2206206994597C13D831ec7` |
| **USDC**  | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` |
| **USDS**  | `0xdC035D45d973E3EC169d2276DDab16f1e407384F` |
| **USDtb** | `0xC139190F447e929f090Edeb554D95AbB8b18aC1C` |
| **USDe**  | `0x4c9EDD5852cd905f086C759E8383e09bff1E68B3` |
| **WETH**  | `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2` |
<!-- | **WBTC**  | `0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599` |
| **cbBTC** | `0xcbB7C0000aB88B473b1f5aFd9ef808440eed33Bf` | -->

### Avalanche

| Token     | Address                                      |
| --------- | -------------------------------------------- |
| **wAVAX** | `0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7` |
| **USDC**  | `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E` |
| **USDT**  | `0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7` |

### Sonic

| Token    | Address                                      |
| -------- | -------------------------------------------- |
| **wS**   | `0x039e2fB66102314Ce7b64Ce5Ce3E5183bc94aD38` |
| **USDC** | `0x29219dd400f2Bf60E5a23d13Be72B486D4038894` |

### Base

| Token    | Address                                      |
| -------- | -------------------------------------------- |
| **USDC** | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` |
| **WETH** | `0x4200000000000000000000000000000000000006` |

### BNB Chain

| Token    | Address                                      |
| -------- | -------------------------------------------- |
| **WBNB** | `0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c` |

### Solana

| Token    | Address                                        |
| -------- | ---------------------------------------------- |
| **USDC** | `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` |
| **wSOL** | `So11111111111111111111111111111111111111112`  |

## FAQ

**Do I have a lockup?**\
No. There is no vesting and no cliff. Your FT is issued into your Perpetual PUT; you can **Hold**, **Exit**, or **Withdraw** at any time.

**What’s the difference between Exit and Withdraw?**\
Exit at par returns your original asset. Withdraw unlocks your FT (Perpetual PUT invalidated) and uses the released backing capital to buy back and burn FT on the market.

**Do buybacks always unlock tokens for the team/foundation?**\
No. Only revenue‑funded buybacks unlock Foundation/Team/Incentives (40:40:20) one‑for‑one. Backing capital yield‑only buybacks do not trigger unlocks.

**Where can I see the math?**\
See the Technical Appendix (link below) for full backtests, formulas, and scenario tables.

**Do I need a vote to Exit?** \
No. The Perpetual PUT is an on-chain, programmatic right. Exercising it requires no governance vote, and a vote cannot revoke the right on existing primary-issued FT.

**What is the difference between Exit vs. Withdraw?** \
**Exit** returns the exact asset and amount you originally committed at par. \
**Withdraw** invalidates the Perpetual PUT; the reserved backing capital is then used by the protocol to fund market buyback-and-burn of FT. Buyers of FT on the market do not receive a Perpetual PUT

**Do secondary buyers receive the Perpetual PUT?** \
FT purchased on the open market does not include a Perpetual PUT. Only primary FT issued in the Capital Allocation has the Perpetual PUT

**Why withdraw instead of Exit?** \
If FT trades above your original price, withdrawing and then selling can yield more than par, but you lose the Perpetual PUT on the amount you withdraw. Exiting always returns exactly par, regardless of market price.

[^1]: You exchange accepted on-chain assets for FT at a fixed rate of 10 FT per \$1\
    (implied price: \$0.10)
====
docs/capital-allocation/technical-appendix.md

---
title: Technical Appendix
sidebar_position: 3
image: docs-og.png
description: Technical details of Flying Tulip ecosystem
---

This appendix makes the PCA program fully evaluable from the docs. It explains the model inputs, allocation logic, yield math, revenue baselines, and how everything translates into buyback-and-burn, unlocks, and potential supply outcomes. All figures are illustrative and subject to market conditions.

> **Note:** Nothing here is investment advice. Backing capital allocations and rates are variable. Yields are not guaranteed.

## A) Methodology & Assumptions

**Objective.** Estimate the annual dollars available to retire FT from (i) backing capital yield and (ii) protocol revenue & fees, then translate those dollars into FT retired under different average buyback prices. Also show Exit/Withdraw scenarios and their supply effects.

**Allocation approach (illustrative, conservative, liquid, no leverage):**

- Major stables (Aave v3 supply)
- stETH (ETH staking)
- jupSOL (SOL LST)
- AVAX staking
- sUSDe (for USDe)

Approximate mix: \~½ in stables, balance across staked ETH/SOL/AVAX and sUSDe exposure. Policy weights may evolve with liquidity, rates, and risk.

**Cadence & accounting.**

- Backing capital yield accrues continuously on‑chain.
- First, it funds the ecosystem development budget (salaries/marketing/infra/ops).
- Remainder flows to buyback‑and‑burn.
- Protocol revenue & fees from the product suite are routed to buyback-and-burn and also govern unlocks (see Section E).
- Exits at par return collateral; Withdrawals invalidate Perpetual PUTs and release backing capital for buyback-and-burn.

## B) Backtested Yield (12‑Month Illustrative; \$1.0B PCA)

**Estimated annual carry by component (USD):**

| Component              | Annual carry (USD) |
| ---------------------- | -----------------: |
| Aave v3 – USDC         |             \$6.58m |
| Aave v3 – USDT         |             \$6.04m |
| Aave v3 – USDS (proxy) |             \$4.38m |
| sUSDe                  |             \$9.43m |
| stETH                  |             \$9.00m |
| jupSOL                 |             \$6.70m |
| AVAX staking           |             \$2.15m |
| **Total**              |        **\$44.27m** |

### Yield → Burn Conversion

If annual backing capital carry surplus available for buyback-and-burn is $$Y$$ dollars and the average buyback price is $$P$$ dollars per FT, then:

$$
FT_{\text{retired\_from\_yield}} \approx Y / P
$$

The surplus $$Y$$ is after funding the ecosystem development budget $$E$$. With total carry $$B$$, we have $$Y = \max(B − E, 0)$$.

Sensitivity for $$P = \$0.10$$ (illustrative):

| Ecosystem budget E | Surplus Y = max(44.27 − E, 0) | FT retired (Y / \$0.10) |
| -----------------: | ----------------------------: | ---------------------: |
|             \$0.00m |                       \$44.27m |              442.7m FT |
|            \$10.00m |                       \$34.27m |              342.7m FT |
|            \$20.00m |                       \$24.27m |              242.7m FT |
|            \$30.00m |                       \$14.27m |              142.7m FT |
|            \$40.00m |                        \$4.27m |               42.7m FT |
|           ≥\$44.27m |                        \$0.00m |                   0 FT |

Other average prices (same $$Y$$):

- $$P = \$0.05 \rightarrow FT \approx 2 × (Y / 0.10)$$
- $$P = \$0.20 \rightarrow FT \approx 0.5 × (Y / 0.10)$$

## C) Protocol Revenue & Fee Capture (Illustrative Baselines)

These baselines allocate a conservative market share across product verticals near \~\$1B Total Value Locked (TVL) / activity.

### Revenue Baseline (illustrative)

- Futures/CLOB analog: **\$57.00m**
- Lending analog: **\$2.87m**
- Delta‑neutral stable/hedging analog: **\$3.16m**
- AMM fee‑switch analog: **\$18.38m**

**Total ≈ \$81.41m** → at **P = \$0.10**, **\~0.814b FT** retired annually.

### Fee Distribution (token‑first integration; alternative lens)

- Futures/CLOB analog: **\$58.00m**
- Lending analog: **\$17.53m**
- Delta‑neutral/hedging analog: **\$31.63m**
- AMM fee‑switch analog: **\$18.38m**

**Total ≈ \$125.54m** → at **P = \$0.10**, **\~1.255b FT** purchased annually.

> **Note:** Depending on product mechanics, users can still receive the same yield %, with distributions delivered in FT while buyback-and-burn is executed in the background.

## D) Exit / Withdraw Scenarios: Supply Effects

- **Exit** (Exit at par): returns the same asset and amount contributed.

- **Withdraw** (invalidate PUT; keep FT): releases backing capital equal to the original contribution for that portion. At the average buyback price P:

  $$FT_{\text{retired\_from\_withdrawals}} \approx \text{Released\_backing\_capital} / P$$

  Illustrations at **P = \$0.10**:

  - **\$100m** released → **\~1.0b FT**
  - **\$250m** released → **\~2.5b FT**
  - **\$500m** released → **\~5.0b FT**

## E) Unlock Logic: Alignment

- Only revenue‑funded buyback-and-burn unlocks Foundation/Team/Incentives one‑for‑one, at 40:40:20.
- Backing capital yield‑funded buyback-and-burn does not trigger unlocks.
- There is no inflation beyond PCA minting; unlocks are releases from pre‑allocated buckets tied to real revenue performance.

## F) One‑Year Combined Illustration (for Intuition)

Assume a **\$1.0B PCA**:

1. **Backing capital carry total:** $$B \approx \$44.27m$$. After funding ecosystem development $$E$$, suppose $$Y = \max(B − E, 0)$$ remains for buyback-and-burn → retires $$Y/P$$ FT at average price $$P$$.
2. **Revenue baseline:** `≈ $81.41m` → **\~0.814b FT** retired at **P = \$0.10**.
3. **Withdrawals:** if **25%** of original capital is Withdrawn, **\~\$250m** of backing capital is released → **\~2.5b FT** retired at **P = \$0.10**.

These forces combine: yield surplus + revenue + withdrawals can retire a substantial share of supply in year one. Outcomes are path‑dependent and sensitive to prices, volumes, budgets, and adoption.

## G) Quick Reference: Key Formulas

PCA minting: $$FT_{\text{minted}} = 10 \times USD_{\text{equivalent\_contributed}}$$

Yield surplus after ecosystem budget: $$Y = \max(B − E, 0)$$

Yield → burn: $$FT_{\text{retired\_from\_yield}} ≈ Y / P$$

Withdrawals → burn: $$FT_{\text{retired\_from\_withdrawals}} ≈ \text{Released\_backing\_capital} / P$$

Revenue → burn: $$FT_{\text{retired\_from\_revenue}} ≈ \text{Revenue\_allocated\_to\_buyback\_and\_burn} / P$$
====
docs/contract-addresses.md

---
id: contract-addresses
title: Contract Addresses
description: "Flying Tulip contract addresses"
---

## Overview

List of all Flying Tulip contracts and their public addresses.

## ftPUT

### ftPUT (Proxy)

Cash-secured PUT product where collateral (e.g., USDC) is deployed to yield strategies via a wrapper. Principal is protected; yield accrues to treasury.

| Address | Network |
| --- | --- |
| [`0xa4215Daaf3745E14E96E169E0E7706c479Ce04F2`](https://etherscan.io/address/0xa4215Daaf3745E14E96E169E0E7706c479Ce04F2) | Ethereum |

### ftPUT (Implementation)

Cash-secured PUT product where collateral (e.g., USDC) is deployed to yield strategies via a wrapper. Principal is protected; yield accrues to treasury.

| Address | Network |
| --- | --- |
| [`0xc55253Ea84050700E1EfA8878D4A5053b6Bf7c5E`](https://etherscan.io/address/0xc55253Ea84050700E1EfA8878D4A5053b6Bf7c5E) | Ethereum |

### Put Manager (Proxy)

Entry point for ftPUT. Orchestrates the sale, accounting, collateral registry, and user flows.

| Address | Network |
| --- | --- |
| [`0xbA49d0AC42f4fBA4e24A8677a22218a4dF75ebaA`](https://etherscan.io/address/0xbA49d0AC42f4fBA4e24A8677a22218a4dF75ebaA) | Ethereum |

### Put Manager (Implementation)

Entry point for ftPUT. Orchestrates the sale, accounting, collateral registry, and user flows.

| Address | Network |
| --- | --- |
| [`0x90AE2Cac15F8d58A258f7B4a243657754469922a`](https://etherscan.io/address/0x90AE2Cac15F8d58A258f7B4a243657754469922a) | Ethereum |

### ACL

| Address | Network |
| --- | --- |
| [`0xA09d08E5A850B26d39Ea2a69f8f99Fd8AA1359EB`](https://etherscan.io/address/0xA09d08E5A850B26d39Ea2a69f8f99Fd8AA1359EB) | Ethereum |

### FT Oracle

Oracle exposes assets prices and FT price per USD.

| Address | Network |
| --- | --- |
| [`0xC8C895E2be9511006287Ce02E51B5B198AB36793`](https://etherscan.io/address/0xC8C895E2be9511006287Ce02E51B5B198AB36793) | Ethereum |

### ftPUT USDC Wrapper

| Address | Network |
| --- | --- |
| [`0x095d8B8D4503D590F647343F7cD880Fa2abbbf59`](https://etherscan.io/address/0x095d8B8D4503D590F647343F7cD880Fa2abbbf59) | Ethereum |

### ftPUT wETH Wrapper

| Address | Network |
| --- | --- |
| [`0x9d96bac8a4E9A5b51b5b262F316C4e648E44E305`](https://etherscan.io/address/0x9d96bac8a4E9A5b51b5b262F316C4e648E44E305) | Ethereum |

### ftPUT USDT Wrapper

| Address | Network |
| --- | --- |
| [`0x267dF6b637DdCaa7763d94b64eBe09F01b07cB36`](https://etherscan.io/address/0x267dF6b637DdCaa7763d94b64eBe09F01b07cB36) | Ethereum |
| [`0x267dF6b637DdCaa7763d94b64eBe09F01b07cB36`](https://snowscan.xyz/address/0x267dF6b637DdCaa7763d94b64eBe09F01b07cB36) | Avalanche |

### ftPUT USDS Wrapper

| Address | Network |
| --- | --- |
| [`0xA143a9C486a1A4aaf54FAEFF7252CECe2d337573`](https://etherscan.io/address/0xA143a9C486a1A4aaf54FAEFF7252CECe2d337573) | Ethereum |

### ftPUT USDTb Wrapper

| Address | Network |
| --- | --- |
| [`0xE5270E0458f58b83dB3d90Aa6A616173c98C97b6`](https://etherscan.io/address/0xE5270E0458f58b83dB3d90Aa6A616173c98C97b6) | Ethereum |

### ftPUT USDe Wrapper

| Address | Network |
| --- | --- |
| [`0xe6880Fc961b1235c46552E391358A270281b5625`](https://etherscan.io/address/0xe6880Fc961b1235c46552E391358A270281b5625) | Ethereum |

### ftPUT USDC AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x0987fb9Ae6CDc6E71DeFcf710833ACfc36e3ba7D`](https://etherscan.io/address/0x0987fb9Ae6CDc6E71DeFcf710833ACfc36e3ba7D) | Ethereum |

### ftPUT wETH AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x2e43F825FBA9018D6303E9CF978cAd9Ac54B04AE`](https://etherscan.io/address/0x2e43F825FBA9018D6303E9CF978cAd9Ac54B04AE) | Ethereum |

### ftPUT wETH Spark Strategy

| Address | Network |
| --- | --- |
| [`0x3f537EF4313297b53BB827C02f3CC381Ad080AEb`](https://etherscan.io/address/0x3f537EF4313297b53BB827C02f3CC381Ad080AEb) | Ethereum |

### ftPUT USDT AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x51e85E0820a508B0a1034aB1fa4F260372F3DB03`](https://etherscan.io/address/0x51e85E0820a508B0a1034aB1fa4F260372F3DB03) | Ethereum |

### ftPUT USDS AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x061d7D04682a6C060cBc4B6Fd65adCC724AFEadB`](https://etherscan.io/address/0x061d7D04682a6C060cBc4B6Fd65adCC724AFEadB) | Ethereum |

### ftPUT USDTb AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x3e607766aDcece773eBc69ad9F2e79fFbBE81F4B`](https://etherscan.io/address/0x3e607766aDcece773eBc69ad9F2e79fFbBE81F4B) | Ethereum |

### ftPUT USDe AAVE Strategy

| Address | Network |
| --- | --- |
| [`0x638a51E61400E228f4300076d95708B5D8962307`](https://etherscan.io/address/0x638a51E61400E228f4300076d95708B5D8962307) | Ethereum |

### ftPUT USDC Spark Strategy

| Address | Network |
| --- | --- |
| [`0xCFb9D82C426335C458ED78625B29B013c632FF2C`](https://etherscan.io/address/0xCFb9D82C426335C458ED78625B29B013c632FF2C) | Ethereum |

### ftPUT USDT Spark Strategy

| Address | Network |
| --- | --- |
| [`0xF20119F84b7D54B6B1d6392EFEf19658515f99a8`](https://etherscan.io/address/0xF20119F84b7D54B6B1d6392EFEf19658515f99a8) | Ethereum |

### ftPUT Circuit Breaker

Rate limiter implementing dual buffer system (ERC-7265 inspired) for protecting against flash loan attacks and excessive withdrawals.

| Address | Network |
| --- | --- |
| [`0xCb170bc873b3a1F69F433C25a4b6d0fd4D4D90De`](https://etherscan.io/address/0xCb170bc873b3a1F69F433C25a4b6d0fd4D4D90De) | Ethereum |

### ftPUT Timelock

| Address | Network |
| --- | --- |
| [`0x3518DB98Cb1fcB19e0c430B3E7f7F74B2A354707`](https://etherscan.io/address/0x3518DB98Cb1fcB19e0c430B3E7f7F74B2A354707) | Ethereum |

## ftUSD

### ftUSD (Proxy)

ftUSD token proxy contract.

| Address | Network |
| --- | --- |
| [`0xF7D85EC4E7710f71992752eac2111312e73E9C9C`](https://etherscan.io/address/0xF7D85EC4E7710f71992752eac2111312e73E9C9C) | Ethereum |
| [`0xF7D85EC4E7710f71992752eac2111312e73E9C9C`](https://sonicscan.org/address/0xF7D85EC4E7710f71992752eac2111312e73E9C9C) | Sonic |

### ftUSD (Implementation)

ftUSD token implementation contract.

| Address | Network |
| --- | --- |
| [`0xf47bb65Fb0886Be183dB541AfCE555345e3e1885`](https://etherscan.io/address/0xf47bb65Fb0886Be183dB541AfCE555345e3e1885) | Ethereum |
| [`0xf47bb65Fb0886Be183dB541AfCE555345e3e1885`](https://sonicscan.org/address/0xf47bb65Fb0886Be183dB541AfCE555345e3e1885) | Sonic |

### ftUSD Core (Proxy)

ftUSD core proxy contract.

| Address | Network |
| --- | --- |
| [`0x56c5892B0cF41B792217CCDD208f0FA85B178ca9`](https://etherscan.io/address/0x56c5892B0cF41B792217CCDD208f0FA85B178ca9) | Ethereum |
| [`0x56c5892B0cF41B792217CCDD208f0FA85B178ca9`](https://sonicscan.org/address/0x56c5892B0cF41B792217CCDD208f0FA85B178ca9) | Sonic |

### ftUSD Core (Implementation)

ftUSD core implementation contract.

| Address | Network |
| --- | --- |
| [`0x986841b77f3aA934D315D48121842E3C622E5440`](https://etherscan.io/address/0x986841b77f3aA934D315D48121842E3C622E5440) | Ethereum |
| [`0x986841b77f3aA934D315D48121842E3C622E5440`](https://sonicscan.org/address/0x986841b77f3aA934D315D48121842E3C622E5440) | Sonic |

### Mint and Redeem (Proxy)

Mint and redeem proxy contract for ftUSD flows.

| Address | Network |
| --- | --- |
| [`0xAa48EcBC843cF7E9A29155D112b8Cb27902bD23C`](https://etherscan.io/address/0xAa48EcBC843cF7E9A29155D112b8Cb27902bD23C) | Ethereum |
| [`0x0C6f8eC81c3eA5BFf06F6CD0791780f9f050eE31`](https://sonicscan.org/address/0x0C6f8eC81c3eA5BFf06F6CD0791780f9f050eE31) | Sonic |

### Mint and Redeem (Implementation)

Mint and redeem implementation contract for ftUSD flows.

| Address | Network |
| --- | --- |
| [`0x8852B132B72613a16f1E3960978a3d45c0A7c3C6`](https://etherscan.io/address/0x8852B132B72613a16f1E3960978a3d45c0A7c3C6) | Ethereum |
| [`0x8852B132B72613a16f1E3960978a3d45c0A7c3C6`](https://sonicscan.org/address/0x8852B132B72613a16f1E3960978a3d45c0A7c3C6) | Sonic |

### Epoch Rewards Vault (Proxy)

Rewards vault proxy for epoch distributions.

| Address | Network |
| --- | --- |
| [`0xeb48218a4c35C814C7678cBcae88C6Ee037F7625`](https://etherscan.io/address/0xeb48218a4c35C814C7678cBcae88C6Ee037F7625) | Ethereum |
| [`0xD1E5A86f1005F6356Bd022C587dE0f430CD2aeb1`](https://sonicscan.org/address/0xD1E5A86f1005F6356Bd022C587dE0f430CD2aeb1) | Sonic |

### Epoch Rewards Vault (Implementation)

Rewards vault implementation for epoch distributions.

| Address | Network |
| --- | --- |
| [`0xEa95e4636BaDc00881f8f73A0623B0fe8627B6da`](https://etherscan.io/address/0xEa95e4636BaDc00881f8f73A0623B0fe8627B6da) | Ethereum |
| [`0x5AEe4b34Df62790581e2f2C31468DDFd7020e841`](https://sonicscan.org/address/0x5AEe4b34Df62790581e2f2C31468DDFd7020e841) | Sonic |

### ftUSD Circuit Breaker V2 (Proxy)

Circuit breaker v2 proxy contract.

| Address | Network |
| --- | --- |
| [`0xCB210509F5AE2b3843B7Fb8Bb90bAFF9cE4f7355`](https://etherscan.io/address/0xCB210509F5AE2b3843B7Fb8Bb90bAFF9cE4f7355) | Ethereum |
| [`0xCB2C0168Bf3440f5f342eD685dFdFd06a4607Edc`](https://sonicscan.org/address/0xCB2C0168Bf3440f5f342eD685dFdFd06a4607Edc) | Sonic |

### ftUSD Circuit Breaker V2 (Implementation)

Circuit breaker v2 implementation contract.

| Address | Network |
| --- | --- |
| [`0x70312a3E8B94A8023B2e0aFe193B1939978cdE3d`](https://etherscan.io/address/0x70312a3E8B94A8023B2e0aFe193B1939978cdE3d) | Ethereum |
| [`0x8e0FA0076e67b105Ad4645522D73eCD801bEFf12`](https://sonicscan.org/address/0x8e0FA0076e67b105Ad4645522D73eCD801bEFf12) | Sonic |

### ftUSD Circuit Breaker Operator

| Address | Network |
| --- | --- |
| [`0x765224780AD888285B03af221f528D0a6824994d`](https://etherscan.io/address/0x765224780AD888285B03af221f528D0a6824994d) | Ethereum |
| [`0x765224780AD888285B03af221f528D0a6824994d`](https://sonicscan.org/address/0x765224780AD888285B03af221f528D0a6824994d) | Sonic |

### ftUSD Circuit Breaker Guardian

| Address | Network |
| --- | --- |
| [`0xdc86aD63Ca7dB1d8b703598b0735c08d5374c7eA`](https://etherscan.io/address/0xdc86aD63Ca7dB1d8b703598b0735c08d5374c7eA) | Ethereum |
| [`0xdc86aD63Ca7dB1d8b703598b0735c08d5374c7eA`](https://sonicscan.org/address/0xdc86aD63Ca7dB1d8b703598b0735c08d5374c7eA) | Sonic |

### ftUSD ftUSD Wrapper

| Address | Network |
| --- | --- |
| [`0xB44a9C40EFc05Eb014EfFEac3CBed6A31F8cB87f`](https://etherscan.io/address/0xB44a9C40EFc05Eb014EfFEac3CBed6A31F8cB87f) | Ethereum |
| [`0x9acdCE593888E52EC7CF70e3D22F0CF50682CD0b`](https://sonicscan.org/address/0x9acdCE593888E52EC7CF70e3D22F0CF50682CD0b) | Sonic |

### ftUSD USDC Wrapper

| Address | Network |
| --- | --- |
| [`0x6aaf84563Cdb03a22Cd92EE2553698beE87E837D`](https://etherscan.io/address/0x6aaf84563Cdb03a22Cd92EE2553698beE87E837D) | Ethereum |
| [`0x0237A67db9D55b2e0f2B25a137EA15e4C497ab6a`](https://sonicscan.org/address/0x0237A67db9D55b2e0f2B25a137EA15e4C497ab6a) | Sonic |

### ftUSD USDC Aave Strategy

| Address | Network |
| --- | --- |
| [`0xb804919a6fD9Ee6AC90Ad3a12BEc902c0b29CB4E`](https://etherscan.io/address/0xb804919a6fD9Ee6AC90Ad3a12BEc902c0b29CB4E) | Ethereum |
| [`0xf09b9d5aBDe8B84d36578f6DA977440332D94DDa`](https://sonicscan.org/address/0xf09b9d5aBDe8B84d36578f6DA977440332D94DDa) | Sonic |

### ftUSD USDC Spark Strategy

| Address | Network |
| --- | --- |
| [`0xEB5Cb93C27A11782D146863a340455E614B10302`](https://etherscan.io/address/0xEB5Cb93C27A11782D146863a340455E614B10302) | Ethereum |

### ftUSD USDT Wrapper

| Address | Network |
| --- | --- |
| [`0x28CCa8eEA2cD0498cE91A9da15772A1ce42347D6`](https://etherscan.io/address/0x28CCa8eEA2cD0498cE91A9da15772A1ce42347D6) | Ethereum |

### ftUSD USDT Aave Strategy

| Address | Network |
| --- | --- |
| [`0xbe968499626B8f027F93Ba7A9b9C686C949dd2Da`](https://etherscan.io/address/0xbe968499626B8f027F93Ba7A9b9C686C949dd2Da) | Ethereum |

### ftUSD USDT Spark Strategy

| Address | Network |
| --- | --- |
| [`0x4f47c4aDC71E1d33fdA433FadDA596a529307af5`](https://etherscan.io/address/0x4f47c4aDC71E1d33fdA433FadDA596a529307af5) | Ethereum |

### ftUSD Oracle

| Address | Network |
| --- | --- |
| [`0xA69f7a38B6c91a4bc2477f097DC8a1F16DAADFf8`](https://etherscan.io/address/0xA69f7a38B6c91a4bc2477f097DC8a1F16DAADFf8) | Ethereum |
| [`0x2c64f618f8ce7Ea31E9ff1F9022cB1B21A9b8Aae`](https://sonicscan.org/address/0x2c64f618f8ce7Ea31E9ff1F9022cB1B21A9b8Aae) | Sonic |

### ftUSD Base Feed

| Address | Network |
| --- | --- |
| [`0x8fFfFfd4AfB6115b954Bd326cbe7B4BA576818f6`](https://etherscan.io/address/0x8fFfFfd4AfB6115b954Bd326cbe7B4BA576818f6) | Ethereum |
| [`0x02e9baE63509FF46248dADDd4041E67ed851f95C`](https://sonicscan.org/address/0x02e9baE63509FF46248dADDd4041E67ed851f95C) | Sonic |

### USD Oracle

| Address | Network |
| --- | --- |
| [`0xe4372dB43D2814750a19b93950157AD81D93674A`](https://etherscan.io/address/0xe4372dB43D2814750a19b93950157AD81D93674A) | Ethereum |
| [`0xe4372dB43D2814750a19b93950157AD81D93674A`](https://sonicscan.org/address/0xe4372dB43D2814750a19b93950157AD81D93674A) | Sonic |

### WrapperUSDC Delta Neutral Strategy wS-stS

| Address | Network |
| --- | --- |
| [`0x6EC218FC45aC0C7B83D16557befABB62ed7455Ae`](https://sonicscan.org/address/0x6EC218FC45aC0C7B83D16557befABB62ed7455Ae) | Sonic |

## Lend (ftDNMM)

### OracleRouterChainlink (Proxy)

| Address | Network |
| --- | --- |
| [`0xe4372dB43D2814750a19b93950157AD81D93674A`](https://etherscan.io/address/0xe4372dB43D2814750a19b93950157AD81D93674A) | Ethereum |
| [`0xe4372dB43D2814750a19b93950157AD81D93674A`](https://sonicscan.org/address/0xe4372dB43D2814750a19b93950157AD81D93674A) | Sonic |

### OracleRouterChainlink (Implementation)

| Address | Network |
| --- | --- |
| [`0xefd7d5471839e8cf1ee4cd6078de720262b705e9`](https://sonicscan.org/address/0xefd7d5471839e8cf1ee4cd6078de720262b705e9) | Sonic |

### ConfigRegistry (Proxy)

| Address | Network |
| --- | --- |
| [`0xA8777c3D446fa7F0b0FC97a80C1Ea1d37F1ca33E`](https://etherscan.io/address/0xA8777c3D446fa7F0b0FC97a80C1Ea1d37F1ca33E) | Ethereum |
| [`0xA8777c3D446fa7F0b0FC97a80C1Ea1d37F1ca33E`](https://sonicscan.org/address/0xA8777c3D446fa7F0b0FC97a80C1Ea1d37F1ca33E) | Sonic |

### ConfigRegistry (Implementation)

| Address | Network |
| --- | --- |
| [`0xD25f964eAD7bfBf07858b5BFeDE58f11a5a947e5`](https://etherscan.io/address/0xD25f964eAD7bfBf07858b5BFeDE58f11a5a947e5) | Ethereum |
| [`0xd25f964ead7bfbf07858b5bfede58f11a5a947e5`](https://sonicscan.org/address/0xd25f964ead7bfbf07858b5bfede58f11a5a947e5) | Sonic |

### PositionsManager (Proxy)

| Address | Network |
| --- | --- |
| [`0xbe4050a73a7Fb384c65E885a15C33461A4B20055`](https://etherscan.io/address/0xbe4050a73a7Fb384c65E885a15C33461A4B20055) | Ethereum |
| [`0xbe4050a73a7Fb384c65E885a15C33461A4B20055`](https://sonicscan.org/address/0xbe4050a73a7Fb384c65E885a15C33461A4B20055) | Sonic |

### PositionsManager (Implementation)

| Address | Network |
| --- | --- |
| [`0xaA3d5fc84b43219391539714Be5f0681AeFCa23b`](https://etherscan.io/address/0xaA3d5fc84b43219391539714Be5f0681AeFCa23b) | Ethereum |
| [`0xaa3d5fc84b43219391539714be5f0681aefca23b`](https://sonicscan.org/address/0xaa3d5fc84b43219391539714be5f0681aefca23b) | Sonic |

### AccountValuesRouter (Proxy)

| Address | Network |
| --- | --- |
| [`0x7aD77FddEf64Ec8325E8d2d02c2708AA2a412eF7`](https://etherscan.io/address/0x7aD77FddEf64Ec8325E8d2d02c2708AA2a412eF7) | Ethereum |
| [`0x7aD77FddEf64Ec8325E8d2d02c2708AA2a412eF7`](https://sonicscan.org/address/0x7aD77FddEf64Ec8325E8d2d02c2708AA2a412eF7) | Sonic |

### AccountValuesRouter (Implementation)

| Address | Network |
| --- | --- |
| [`0x5a5E77f566079168706A9887172Dda37d7B7a4FB`](https://etherscan.io/address/0x5a5E77f566079168706A9887172Dda37d7B7a4FB) | Ethereum |
| [`0x5a5e77f566079168706a9887172dda37d7b7a4fb`](https://sonicscan.org/address/0x5a5e77f566079168706a9887172dda37d7b7a4fb) | Sonic |

### LendingLens (Proxy)

| Address | Network |
| --- | --- |
| [`0x3682168023E6bA8D1F995FdA1D920827C5A8A43E`](https://etherscan.io/address/0x3682168023E6bA8D1F995FdA1D920827C5A8A43E) | Ethereum |
| [`0x3682168023E6bA8D1F995FdA1D920827C5A8A43E`](https://sonicscan.org/address/0x3682168023E6bA8D1F995FdA1D920827C5A8A43E) | Sonic |

### LendingLens (Implementation)

| Address | Network |
| --- | --- |
| [`0x054c80b91B39fC4f84EF0ecd53bbb53163229795`](https://etherscan.io/address/0x054c80b91B39fC4f84EF0ecd53bbb53163229795) | Ethereum |
| [`0x054c80b91b39fc4f84ef0ecd53bbb53163229795`](https://sonicscan.org/address/0x054c80b91b39fc4f84ef0ecd53bbb53163229795) | Sonic |

### StableIRM

| Address | Network |
| --- | --- |
| [`0x3253739A68640E308c8209384bb44E4ADA38710d`](https://etherscan.io/address/0x3253739A68640E308c8209384bb44E4ADA38710d) | Ethereum |
| [`0x3253739A68640E308c8209384bb44E4ADA38710d`](https://sonicscan.org/address/0x3253739A68640E308c8209384bb44E4ADA38710d) | Sonic |

### MajorIRM

| Address | Network |
| --- | --- |
| [`0x07eC8583B1bC7D97646409a2b51DdBed6725D12F`](https://etherscan.io/address/0x07eC8583B1bC7D97646409a2b51DdBed6725D12F) | Ethereum |
| [`0x07eC8583B1bC7D97646409a2b51DdBed6725D12F`](https://sonicscan.org/address/0x07eC8583B1bC7D97646409a2b51DdBed6725D12F) | Sonic |

### LongTailIRM

| Address | Network |
| --- | --- |
| [`0x09cd852f47aCa224eE6B4AccC29BD2694F29Ef69`](https://etherscan.io/address/0x09cd852f47aCa224eE6B4AccC29BD2694F29Ef69) | Ethereum |
| [`0x09cd852f47aCa224eE6B4AccC29BD2694F29Ef69`](https://sonicscan.org/address/0x09cd852f47aCa224eE6B4AccC29BD2694F29Ef69) | Sonic |

### MetaActions

| Address | Network |
| --- | --- |
| [`0x3633EB60D08756674472e2D34d6fFb5f4c1c29f2`](https://etherscan.io/address/0x3633EB60D08756674472e2D34d6fFb5f4c1c29f2) | Ethereum |
| [`0x3633EB60D08756674472e2D34d6fFb5f4c1c29f2`](https://sonicscan.org/address/0x3633EB60D08756674472e2D34d6fFb5f4c1c29f2) | Sonic |

### MetaSessionActions

| Address | Network |
| --- | --- |
| [`0x4f83aC5c8A79986D0916a8849730d9CEF63a3497`](https://etherscan.io/address/0x4f83aC5c8A79986D0916a8849730d9CEF63a3497) | Ethereum |
| [`0x4f83aC5c8A79986D0916a8849730d9CEF63a3497`](https://sonicscan.org/address/0x4f83aC5c8A79986D0916a8849730d9CEF63a3497) | Sonic |

### RfqEngine

| Address | Network |
| --- | --- |
| [`0xEB00B335Ca52216Fb60fdFFA361397367C39Dc32`](https://etherscan.io/address/0xEB00B335Ca52216Fb60fdFFA361397367C39Dc32) | Ethereum |
| [`0xEB00B335Ca52216Fb60fdFFA361397367C39Dc32`](https://sonicscan.org/address/0xEB00B335Ca52216Fb60fdFFA361397367C39Dc32) | Sonic |

### LeverageRfqEngine

| Address | Network |
| --- | --- |
| [`0x8263a07504d93cB95e0a74f3627bb15faaf140e2`](https://etherscan.io/address/0x8263a07504d93cB95e0a74f3627bb15faaf140e2) | Ethereum |
| [`0x8263a07504d93cB95e0a74f3627bb15faaf140e2`](https://sonicscan.org/address/0x8263a07504d93cB95e0a74f3627bb15faaf140e2) | Sonic |

### Lend CircuitBreaker

| Address | Network |
| --- | --- |
| [`0x9676E697399581AB288844cDE5F73d0887eC18e0`](https://etherscan.io/address/0x9676E697399581AB288844cDE5F73d0887eC18e0) | Ethereum |
| [`0x9676E697399581AB288844cDE5F73d0887eC18e0`](https://sonicscan.org/address/0x9676E697399581AB288844cDE5F73d0887eC18e0) | Sonic |

### PMWrapper (Proxy)

| Address | Network |
| --- | --- |
| [`0xBDD80028c9e4b9A2D268D2cF62Fb54Ec8697C68B`](https://etherscan.io/address/0xBDD80028c9e4b9A2D268D2cF62Fb54Ec8697C68B) | Ethereum |
| [`0xBDD80028c9e4b9A2D268D2cF62Fb54Ec8697C68B`](https://sonicscan.org/address/0xBDD80028c9e4b9A2D268D2cF62Fb54Ec8697C68B#writeProxyContract) | Sonic |

### PMWrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0x5c5Ab8FD8F40aD624e531FEDF227fF60c5164D32`](https://etherscan.io/address/0x5c5Ab8FD8F40aD624e531FEDF227fF60c5164D32) | Ethereum |
| [`0x5c5Ab8FD8F40aD624e531FEDF227fF60c5164D32`](https://sonicscan.org/address/0x5c5Ab8FD8F40aD624e531FEDF227fF60c5164D32) | Sonic |

### Lend USDC Wrapper

| Address | Network |
| --- | --- |
| [`0xD2e4A5ac4B4Da102317cF7C9A1289aDF082639E2`](https://etherscan.io/address/0xD2e4A5ac4B4Da102317cF7C9A1289aDF082639E2) | Ethereum |
| [`0x7a2FD34E4Cc4C8B1023576a3f3D1f7aA36CF8b47`](https://sonicscan.org/address/0x7a2FD34E4Cc4C8B1023576a3f3D1f7aA36CF8b47) | Sonic |

### Lend USDC Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0xFAeD20B307A6789481eE383ADC10b9b0090b1157`](https://etherscan.io/address/0xFAeD20B307A6789481eE383ADC10b9b0090b1157) | Ethereum |
| [`0x9b4aa6ba7ab3a08980a68244d5c5c1c46756b66d`](https://sonicscan.org/address/0x9b4aa6ba7ab3a08980a68244d5c5c1c46756b66d) | Sonic |

### Lend USDC Aave Strategy

| Address | Network |
| --- | --- |
| [`0x974ba6Aa224f6f3515170F963FBD256dF214F8eE`](https://sonicscan.org/address/0x974ba6Aa224f6f3515170F963FBD256dF214F8eE) | Sonic |

### Lend USDC Spark Strategy

| Address | Network |
| --- | --- |
| [`0xfBE0736eBF5668A604D73BA93a5DdBEe9c10b0e5`](https://etherscan.io/address/0xfBE0736eBF5668A604D73BA93a5DdBEe9c10b0e5) | Ethereum |

### Lend wNative Wrapper

| Address | Network |
| --- | --- |
| [`0x460494aF61BcB92B59797B4e09C26A5ADecb2da2`](https://etherscan.io/address/0x460494aF61BcB92B59797B4e09C26A5ADecb2da2) | Ethereum |
| [`0xbB155F15D8452139D1A9C3a664847D2f8314C18E`](https://sonicscan.org/address/0xbB155F15D8452139D1A9C3a664847D2f8314C18E) | Sonic |

### Lend wNative Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0x40693Bc9F8D986e6ed1291293E620B71f63b06E7`](https://etherscan.io/address/0x40693Bc9F8D986e6ed1291293E620B71f63b06E7) | Ethereum |
| [`0x38b9717cf28d8bfde7b40fe2c0a703ed457555d0`](https://sonicscan.org/address/0x38b9717cf28d8bfde7b40fe2c0a703ed457555d0) | Sonic |

### Lend wS Aave Strategy

| Address | Network |
| --- | --- |
| [`0x216e588e4D726c691679C7eB4944c033e0d3DF28`](https://sonicscan.org/address/0x216e588e4D726c691679C7eB4944c033e0d3DF28) | Sonic |

### Lend WETH Spark Strategy

| Address | Network |
| --- | --- |
| [`0x4df6f4f8CDA409550A5d8A89aD66DE355CF7F2a7`](https://etherscan.io/address/0x4df6f4f8CDA409550A5d8A89aD66DE355CF7F2a7) | Ethereum |

### Lend stakedNative Wrapper

| Address | Network |
| --- | --- |
| [`0x01980BD1B58313bD3767f6adc75Af8b6464f3db7`](https://etherscan.io/address/0x01980BD1B58313bD3767f6adc75Af8b6464f3db7) | Ethereum |
| [`0x8B98e46421898437862de44aA63b73B2dA69147B`](https://sonicscan.org/address/0x8B98e46421898437862de44aA63b73B2dA69147B) | Sonic |

### Lend stakedNative Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0x51AFD3Ed66b07dff22B90De0eba20796Cf948E18`](https://etherscan.io/address/0x51AFD3Ed66b07dff22B90De0eba20796Cf948E18) | Ethereum |
| [`0x5d3d9ec8da7857928ea0a00c0241e914f9a816bf`](https://sonicscan.org/address/0x5d3d9ec8da7857928ea0a00c0241e914f9a816bf) | Sonic |

### Lend USDT Wrapper

| Address | Network |
| --- | --- |
| [`0x28b0905d83BCe5FFA6c54651F25858828A38123B`](https://etherscan.io/address/0x28b0905d83BCe5FFA6c54651F25858828A38123B) | Ethereum |

### Lend USDT Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0x6c971ddEF3e910a786472a957108757bF7728c8C`](https://etherscan.io/address/0x6c971ddEF3e910a786472a957108757bF7728c8C) | Ethereum |

### Lend USDT Spark Strategy

| Address | Network |
| --- | --- |
| [`0x852dc7638aD159Ec12526d7E47f53f1307756a42`](https://etherscan.io/address/0x852dc7638aD159Ec12526d7E47f53f1307756a42) | Ethereum |

### Lend FT Wrapper

| Address | Network |
| --- | --- |
| [`0x7127BB9d9ad0f47B8dA9087e634D67F3946F840E`](https://etherscan.io/address/0x7127BB9d9ad0f47B8dA9087e634D67F3946F840E) | Ethereum |
| [`0x7127BB9d9ad0f47B8dA9087e634D67F3946F840E`](https://sonicscan.org/address/0x7127BB9d9ad0f47B8dA9087e634D67F3946F840E) | Sonic |

### Lend FT Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0x051589975909644bEe7C33C037A7d2009c8F1839`](https://etherscan.io/address/0x051589975909644bEe7C33C037A7d2009c8F1839) | Ethereum |
| [`0x051589975909644bee7c33c037a7d2009c8f1839`](https://sonicscan.org/address/0x051589975909644bee7c33c037a7d2009c8f1839) | Sonic |

### Lend ftUSD Wrapper

| Address | Network |
| --- | --- |
| [`0xc67D966f761e8cf13Faa0a1E774425290c8453d9`](https://etherscan.io/address/0xc67D966f761e8cf13Faa0a1E774425290c8453d9) | Ethereum |
| [`0xc67D966f761e8cf13Faa0a1E774425290c8453d9`](https://sonicscan.org/address/0xc67D966f761e8cf13Faa0a1E774425290c8453d9) | Sonic |

### Lend ftUSD Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0xB213e88F680FA41f9a910adA49bA8343F2e92c22`](https://etherscan.io/address/0xB213e88F680FA41f9a910adA49bA8343F2e92c22) | Ethereum |
| [`0xb213e88f680fa41f9a910ada49ba8343f2e92c22`](https://sonicscan.org/address/0xb213e88f680fa41f9a910ada49ba8343f2e92c22) | Sonic |

### Lend wETH Wrapper

| Address | Network |
| --- | --- |
| [`0x727bC187150d5599e7FBA32732c21C6D9F5B1837`](https://sonicscan.org/address/0x727bC187150d5599e7FBA32732c21C6D9F5B1837) | Sonic |

### Lend wETH Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0xb6f498c8212bad07369b87fc0590fe6e2084ae86`](https://sonicscan.org/address/0xb6f498c8212bad07369b87fc0590fe6e2084ae86) | Sonic |

### Lend wBTC Wrapper

| Address | Network |
| --- | --- |
| [`0x1A5730c71576D77048E9FdC79DD40e4B1E8Fe042`](https://etherscan.io/address/0x1A5730c71576D77048E9FdC79DD40e4B1E8Fe042) | Ethereum |
| [`0xd6587e78D252E630d425eCD827017BF81b0ac553`](https://sonicscan.org/address/0xd6587e78D252E630d425eCD827017BF81b0ac553) | Sonic |

### Lend wBTC Wrapper (Implementation)

| Address | Network |
| --- | --- |
| [`0xAee64Ce25059929c92E96D4d0Fd05b958A18B5D6`](https://etherscan.io/address/0xAee64Ce25059929c92E96D4d0Fd05b958A18B5D6) | Ethereum |
| [`0xae65fd1cf583962a104cf7f68a04c7256b5a16eb`](https://sonicscan.org/address/0xae65fd1cf583962a104cf7f68a04c7256b5a16eb) | Sonic |

## Miscellaneous

### FT Token

LayerZero EVM Omnichain Fungible Token.

| Address | Network |
| --- | --- |
| [`0x5DD1A7A369e8273371d2DBf9d83356057088082c`](https://etherscan.io/address/0x5DD1A7A369e8273371d2DBf9d83356057088082c) | Ethereum |
| [`0x5DD1A7A369e8273371d2DBf9d83356057088082c`](https://sonicscan.org/address/0x5DD1A7A369e8273371d2DBf9d83356057088082c) | Sonic |
| [`0x5DD1A7A369e8273371d2DBf9d83356057088082c`](https://basescan.org/address/0x5DD1A7A369e8273371d2DBf9d83356057088082c) | Base |
| [`0x5DD1A7A369e8273371d2DBf9d83356057088082c`](https://bscscan.com/address/0x5DD1A7A369e8273371d2DBf9d83356057088082c) | BNB Chain |
| [`0x5DD1A7A369e8273371d2DBf9d83356057088082c`](https://snowscan.xyz/address/0x5DD1A7A369e8273371d2DBf9d83356057088082c) | Avalanche |

### PUT Options Marketplace

Decentralized marketplace for trading Flying Tulip PUT Options NFTs.

| Address | Network |
| --- | --- |
| [`0x31248663ADccdBCAD155555b7717697B76cf570c`](https://etherscan.io/address/0x31248663ADccdBCAD155555b7717697B76cf570c) | Ethereum |

### Permit2

Helper contract for gasless transactions on PUT Options marketplace

| Address | Network |
| --- | --- |
| [`0xEB450d21ae68D3303Cf5775A54Cc84EE7c3fC8eC`](https://etherscan.io/address/0xEB450d21ae68D3303Cf5775A54Cc84EE7c3fC8eC) | Ethereum |

## Session

### RelayerAuth

| Address | Network |
| --- | --- |
| [`0x823a97a2c32985e0f5457fc8103F36698D1F53F4`](https://etherscan.io/address/0x823a97a2c32985e0f5457fc8103F36698D1F53F4) | Ethereum |
| [`0x823a97a2c32985e0f5457fc8103F36698D1F53F4`](https://sonicscan.org/address/0x823a97a2c32985e0f5457fc8103F36698D1F53F4) | Sonic |

### ftUSD SessionManager

| Address | Network |
| --- | --- |
| [`0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b`](https://etherscan.io/address/0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b) | Ethereum |
| [`0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b`](https://sonicscan.org/address/0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b) | Sonic |

### Lend SessionManager

| Address | Network |
| --- | --- |
| [`0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b`](https://etherscan.io/address/0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b) | Ethereum |
| [`0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b`](https://sonicscan.org/address/0x880A371CE2C5Dbb2EB47EC0023b358e8aE80071b) | Sonic |
====
docs/glossary.md

---
id: glossary
title: Glossary
description: List of terms used across the Flying Tulip documentation
---

This page defines the concepts used across the Flying Tulip documentation.

**Jump to:**\
[A](glossary.md#a) · [B](glossary.md#b) · [C](glossary.md#c) · [D](glossary.md#d) · [E](glossary.md#e) · [F](glossary.md#f) · [H](glossary.md#h) · [I](glossary.md#i) · [J](glossary.md#j) · [K](glossary.md#k) · [L](glossary.md#l) · [M](glossary.md#m) · [N](glossary.md#n) · [O](glossary.md#o) · [P](glossary.md#p) · [Q](glossary.md#q) · [R](glossary.md#r) · [S](glossary.md#s) · [T](glossary.md#t) · [U](glossary.md#u) · [V](glossary.md#v) · [W](glossary.md#w) · [Y](glossary.md#y)

***

## A

**Aave (Aave v3)** — A decentralized lending protocol used for conservative yield and collateralization in several Flying Tulip flows.

**ABI (Application Binary Interface)** — The encoded interface that defines how to call a smart contract’s functions and decode responses.

**Accepted Assets** — Tokens that can be contributed in the Capital Allocation (PCA) or used in products (e.g., USDC, USDT, USDS, USDe, USDtb, WETH, WBTC, cbBTC, SOL/jupSOL, AVAX/wAVAX).

**AEAD (Authenticated Encryption with Associated Data)** — The 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.

**AMM (Automated Market Maker)** — On‑chain market using formulas instead of a central order book to quote prices and execute swaps.

**API (Application Programming Interface)** — A programmatic interface for accessing data or functionality.

**APR (Annual Percentage Rate)** — An annualized rate that does not include compounding.

**Annual Percentage Yield (APY)** — An annualized rate that includes compounding.

**AVAX / wAVAX** — Avalanche’s native token and its wrapped ERC‑20 representation used for staking and liquidity.

***

## B

**Backing Capital** — The contributed assets that back each primary FT position while the Perpetual PUT remains open.

**Backing Capital Yield (carry)** — Yield generated by deploying backing capital into low‑risk venues. Priority is to fund ecosystem development first (salaries/marketing/infra/ops); surplus funds buyback-and-burn of FT.

**Basis / Funding (contextual)** — The long/short spread or periodic payments that keep derivative prices aligned with spot (used in delta‑neutral strategies and futures).

**Beets (staking venue)** — A venue referenced for staking Sonic (S → stS) in certain strategies.

**Buyback-and-Burn** — A 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.

**Binary Prediction Markets** — Yes/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.

**Black–Scholes** — A 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.

***

## C

**Capital Efficiency** — Using the same collateral to support multiple activities (e.g., accrue yield and back trading/borrowing) to increase effective return per unit of capital.

**CLOB (Central Limit Order Book)** — An exchange mechanism that matches bids and asks; integrated with Flying Tulip’s permissioned lending for cross‑collateralized trading while deposits continue to accrue.

**Circuit Breaker** — A rate‑limiting safety mechanism that throttles withdrawals or outflows to reduce exploit blast radius.

**Cliff** — A vesting structure where tokens remain locked until a specific date, then begin unlocking.

**Collateral / Collateral Caps** — Assets allowed as collateral and the maximum per‑asset size configured to manage concentration and risk.

**Configurator (role)** — Admin role used to set or update parameters (e.g., pausing, asset lists, strategy weights).

**Concentrated Liquidity** — Providing AMM liquidity within a chosen price range to accrue higher fees while in range.

**Constant Product / Constant Sum** — AMM curve archetypes: **x·y = k** (constant product) offers LP protection with higher price impact; **x + y = k** (constant sum) offers tight spreads with less protection. Flying Tulip blends them dynamically.

**CertificateVerify (TLS)** — A 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.

**Cross‑Collateral** — Using one deposit as collateral across multiple markets or products simultaneously (e.g., lending, CLOB, futures).

***

## D

**Debt Netting Mechanism** — Pool‑level offsetting of long/short exposures that enables delta‑neutral configurations (e.g., ftUSD) with **zero‑liquidation risk** under defined parameters.

**DeFi (Decentralized Finance)** — Financial services built on public blockchains using smart contracts rather than centralized intermediaries.

**DAO (Decentralized Autonomous Organization)** — An on‑chain organization governed by members via smart‑contract rules.

**Delta‑Neutral** — A portfolio whose net directional exposure is approximately zero, constructed by balancing long and short legs.

***

## E

**Ecosystem Budget (priority)** — The first call on backing capital yield to fund the organization: salaries, marketing, infrastructure, and operations.

**EMA (Exponential Moving Average)** — A smoothing method used to detect calm vs. volatile market regimes.

**ERC‑7265** — A proposed safety standard for rate‑limiting withdrawals/exits to mitigate exploit drains.

**EVM (Ethereum Virtual Machine)** — The execution environment for smart contracts on Ethereum‑compatible chains.

**Exit (exercise)** — Action that exercises the Perpetual PUT at par; the original asset/amount is returned.

***

## F

**Fail‑Open** — A safety design where a mechanism defaults to allowing transactions if it fails, avoiding permanent lockups.

**Fee Switch** — A protocol setting that redirects a portion of AMM fees to the protocol treasury or buyback pipeline.

**Flash Loan** — An uncollateralized loan that must be borrowed and repaid within a single transaction; often used for arbitrage or attacks.

**Front‑Running** — Submitting a transaction to execute before a visible pending transaction in order to capture profit.

**FT** — The native token of Flying Tulip. Minted proportionally during the PCA (10 FT per $1) up to a hard cap of 10B. Supports cross‑chain transfers (OFT) and EIP‑2612 permits.

**FT NFT** — The ERC‑721 token that represents a holder’s Perpetual PUT. Each FT NFT (ftPUT) tracks the collateral, strike asset, and FT amount tied to a primary allocation position.

**ftUSD** — A 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).

**Funding Rate (Futures)** — Periodic payments between long/short positions that keep future prices aligned with spot; can be computed from actual borrowing costs.

***

## H

**Hybrid Curve (AMM)** — A dynamic blend between constant sum (tight spreads in calm markets) and constant product (LP protection in volatility), informed by regime signals (e.g., EMAs) and guardrails.

***

## I

**Impermanent Loss** — The divergence loss LPs can face when an AMM pool’s asset prices shift relative to deposit prices; mitigated by Flying Tulip’s hybrid curve behavior in volatile regimes.

**Invest (PutManager)** — Deposit accepted assets to open a PUT position and withdraw FT issued into that PUT.

**Insurance Pool / FT\_exploit\_insurance** — A capital pool that backs exploit coverage; buyers pay usage‑based premiums, and providers accrue yield from those premiums. Claims depend on event verification.

**Isolated Collateral** — Collateral mode where assets are dedicated to a single position and not shared across markets.

***

## J

**jupSOL** — A liquid‑staking representation of SOL used for staking yield in conservative allocations.

***

## K

**Keepers (Liquidation Keepers)** — External actors incentivized to execute liquidations or complex unwinds. Flying Tulip uses size/time‑sliced execution and rebates to reduce market impact.

**KYC (Know Your Customer)** — Identity verification required by some platforms or jurisdictions.

***

## L

**Lend - Permissionless** — A lending system where each Spot pair automatically gets a lending market. Parameters adapt dynamically to market conditions.

**Lend - Permissioned** — A pre‑configured lending pool enabling cross‑collateral and powering Spot and Futures; includes debt netting for zero‑liquidation strategies.

**Leverage (Futures)** — Trading with exposure greater than posted collateral; in FT futures, leverage constraints are set using depth‑aware metrics.

**Leveraged Liquidity (AMM)** — LP mode that behaves like full‑range coverage but concentrates more capital near the current price to improve fee capture without constant re‑ranges.

**Liquidation / Soft Liquidation** — Forced unwind of risky positions; Flying Tulip emphasizes gradual "soft" liquidations via Spot routing, with size/time‑slicing and keeper incentives.

**Loan‑to‑Value (LTV)** — Borrowing limit as a ratio of collateral value; may be a snapshot at opening to avoid abrupt changes affecting users.

**Launchpad** — The 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.

**LayerZero** — Cross‑chain messaging protocol used to power OFT transfers.

**Lockup** — A period during which tokens cannot be transferred or withdrawn.

**LP / Liquidity Provider** — A user who deposits assets into a pool or AMM to accrue fees or incentives.

**LST (Liquid Staking Token)** — A tokenized claim on staked assets that remains liquid (e.g., stETH).

***

## M

**Maker / Taker** — Trading roles where makers add liquidity with resting orders and takers remove it by trading against them; fee schedules often differ.

**Mark‑to‑Market** — Valuing a position using current market prices rather than entry prices.

**MEV (Maximal Extractable Value)** — Value extracted by transaction ordering, inclusion, or exclusion within a block.

**Money Market** — A lending/borrowing venue where deposits accrue interest and loans are collateralized.

**Multisig** — A multi‑signature wallet with elevated permissions used for safety‑critical admin actions.

***

## N

**NFT (Non‑Fungible Token)** — A unique token (typically ERC‑721) representing ownership of a specific asset or position.

**No Bridging (backing capital)** — Backing capital remains on the source chain and is not bridged as part of the default allocation policy.

***

## O

**OFT (Omnichain Fungible Token)** — Cross‑chain messaging and token standard that allows FT to move natively across chains.

**OFAC** — The U.S. Office of Foreign Assets Control; referenced for compliance and sanctions constraints.

**Oracle (price oracle)** — External feed of asset prices. Flying Tulip futures derive pricing/settlement from in‑house trading activity to avoid oracle lag/manipulation.

**Order Book (CLOB)** — See **CLOB**; orders can rest while deposits continue to accrue in the permissioned lending system.

**Opt‑In Settlement LP (Futures)** — Liquidity providers who supply ftUSD to settlement pools and accrue per‑settlement fees, with exposure managed across providers.

***

## P

**ftPUT (PUT position token)** — The token representing a specific **Perpetual PUT** position (one position per token). Used by contracts to manage **withdrawFT** (invalidate PUT) and Exit at par.

**Pause / Pausing** — Temporarily halting token transfers or protocol operations via admin roles for safety.

**Perpetual Futures (Futures)** — Futures without expiration; Flying Tulip uses on‑chain trading as the primary price source with sub‑second settlement and funding tied to real borrowing costs.

**Perpetual PUT** — The 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).

**P&L (Profit and Loss)** — Net gains or losses on a position after fees and price changes.

**Permit2** — A signature‑based token approval/transfer contract used to enable gasless or one‑time permissions.

**Price Impact** — Slippage caused by trade size relative to available depth; managed by hybrid curves and depth‑aware metrics.

**Pro‑Rata** — Proportional allocation based on each participant’s share of the total.

**Capital Allocation (PCA)** — The on-chain Public Sale event where contributors exchange accepted assets for FT at a fixed rate (10 FT per $1). FT is allocated from a fixed pre-minted total supply of 10B. `totalSupply` stays 10B while the split between circulating and non-circulating supply changes.

**Passkeys (WebAuthn / FIDO2)** — Passwordless authentication bound to a device or security key, used with delegated session keys to enable one‑click, wallet‑less UX while maintaining on‑chain security guarantees.

**PutManager** — The contract that orchestrates PCA participation, FT issuance into PUT positions, and post‑offering actions such as invest, withdraw, exit, and state transitions.

***

## Q

**Queues / Unbonding (staking exits)** — Waiting periods required to withdraw from certain staking positions (e.g., stETH withdrawals, SOL/AVAX unbonding).

***

## R

**Rate Limiter** — A mechanism that caps the rate of withdrawals or actions over time to reduce exploit impact.

**RWAP (Reserve‑Weighted Average Price)** — A price metric that weights observations by available reserves near the path of execution, providing a depth‑aware benchmark for swaps.

**RVOL (Realized Volatility)** — Observed volatility over a window, used to characterize market regimes.

**Revenue & Fees (Protocol)** — Cashflows generated by Flying Tulip products (e.g., ftUSD/settlement rails, Spot, Lend, Futures, Insurance) routed to buyback-and-burn and used to govern unlocks.

**Revenue‑Funded Unlocks (40:40:20)** — When buybacks are funded by **revenue**, Foundation/Team/Incentives unlock **1:1** in a **40:40:20** split. **Yield‑only** buybacks do **not** unlock.

**Risk Controls (Spot & Lend)** — Guardrails and procedures (e.g., regime detection, snapshot LTV, soft liquidation, size/time‑slicing, incentivized keepers) that aim to reduce tail risk and market impact.

***

## S

**sUSDe / USDe** — A yield‑bearing form (sUSDe) and its base asset (USDe) used in certain strategies and as accepted assets in the PCA.

**sftUSD** — Staked ftUSD receipt token that accrues the staking pool’s yield.

**Safe (Gnosis Safe)** — A multisig smart‑contract wallet commonly used for admin or treasury control.

**Settlement Currency / Pools (Futures)** — ftUSD is used as the settlement currency; opt‑in LPs deposit ftUSD to settlement pools and accrue fees.

**Settlement Rail** — The ftUSD settlement layer used to clear trades and transfers across products.

**SDK (Software Development Kit)** — A packaged set of tools/libraries for building integrations.

**Slippage** — The difference between expected and executed price due to trade size and available liquidity.

**Sandwich Attack** — An MEV strategy that places a trade before and after a victim order to capture price impact.

**Snapshot (Eligibility)** — A point‑in‑time capture of on‑chain state used to determine whitelist eligibility.

**Snapshot LTV** — Borrow limits fixed at the time of opening/adjustment to protect users from abrupt parameter changes.

**Soft Liquidation** — Gradual unwind via Spot with size/time‑slicing and incentives to reduce slippage.

**Sonic (S) / wS / stS** — Sonic chain’s token and its wrapped/staked variants referenced in certain strategies and accepted‑assets lists.

**Session Keys (Delegated Keys)** — Short‑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.

**State Channels** — Off‑chain execution channels that update balances with periodic on‑chain commitments. Used to enable continuous trading; channels cannot withdraw funds, which requires native signing.

**stETH** — A liquid‑staking representation of ETH used for conservative staking yield.

**Stablecoin** — A token pegged to a reference value (e.g., USD). ftUSD is a stable, delta‑neutral, yield‑bearing variant.

**Strategy (ftYieldWrapper)** — A yield venue tracked by the wrapper; strategies can be added/removed/reordered and capital moved between them by authorized roles.

**Surplus (Yield Surplus)** — Backing capital yield remaining after the ecosystem budget; the surplus is used for buyback-and-burn.

***

## T

**Timelock** — A delay between a governance/action proposal and its execution.

**Time‑Sliced Execution** — Breaking a large unwind into smaller pieces over time to reduce price impact.

**Tokenomics** — The economics of a token: supply, issuance, incentives, and distribution.

**Token Unlocks** — See **Revenue‑Funded Unlocks (40:40:20)**; unlocks are releases from pre‑allocated buckets, not new token inflation.

**Total Value Locked (TVL)** — The total value of assets deposited in a protocol, market, or strategy.

**TWAP (Time‑Weighted Average Price)** — A time‑only averaging of price used in oracles and analytics; complements depth‑aware measures.

**TWAR (Time‑Weighted Average Reserve)** — A 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.

***

## U

**Utilization** — The share of a pool’s assets that are currently borrowed or in active use.

**UI (User Interface)** — The visual interface through which users interact with an app or product.

**UX (User Experience)** — The overall experience of using a product, including ease, clarity, and flow.

**UMA Oracle (Optimistic Oracle)** — Third‑party verification service used by Insurance to confirm exploit events before claims are paid.

**Unlocks 40:40:20** — See **Revenue‑Funded Unlocks**.

**USDC / USDT / USDS / USDe / USDtb** — Stablecoins accepted in PCA contributions and used across products; each has distinct risk/peg mechanics.

***

## V

**Vesting** — A schedule that releases tokens over time instead of all at once.

***

## W

**Wallet Abstraction** — Using smart‑contract accounts and delegated keys to simplify wallet UX while preserving on‑chain security.

**WBTC / cbBTC** — Bitcoin representations used on EVM chains; accepted assets for PCA and supported in some products.

**Witnessnet** — A 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."

***

## Y

**Yield Surplus (Y)** — The remaining annual backing capital carry after the ecosystem budget (**E**) has been funded: **Y = max(B − E, 0)**. Converted to retired FT by **Y / P**, where **P** is the average buyback price.
====
docs/guides/circuit-breaker-v2.md

# Circuit Breaker v2 — UI, Backend & Infrastructure Guide

## Overview

Circuit Breaker v2 (CBv2) is an on-chain rate limiter with deferred settlement for protocol outflows. It protects against exploits by limiting how much value can leave the protocol within a time window. When an outflow exceeds available capacity, it is **queued** for delayed execution instead of being rejected.

Users normally do not need to interact with the Circuit Breaker contract directly for most withdrawals. They call the same `redeem()` / `withdraw()` functions they always would.

The Circuit Breaker only becomes visible when a withdrawal larger than the available buffer is requested and gets queued for later settlement. Most withdrawals should not be queued as long as they remain within the available buffer.

### Key Concepts

| Term                   | Description                                                                                                                                                                                                  |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Protected contract** | A contract registered with the Circuit Breaker that routes outflows through it (e.g., `MintAndRedeem`, `ftYieldWrapperV2`). Each inherits `ProtectedContract` and calls into the Circuit Breaker internally. |
| **Limiter asset**      | The token used as the rate-limit bucket key. Buffer capacity is sized relative to TVL of this asset.                                                                                                         |
| **Transfer token**     | The token actually transferred. Usually the same as the limiter asset, but can differ (e.g., wrapper withdrawals may use the wrapper token as limiter but transfer strategy position tokens).                |
| **Main buffer**        | Steady-state withdrawal capacity. Replenishes linearly over `mainWindow` toward a cap of `maxDrawRateWad * TVL`.                                                                                             |
| **Elastic buffer**     | Temporary capacity from deposits. Decays proportionally over `elasticWindow`. Prevents deposit-then-withdraw flash loan attacks from consuming the main buffer.                                              |
| **Settlement delay**   | Time a queued outflow must wait before it can be executed. Configurable between 5 minutes and 7 days. Default is 6 hours.                                                                                    |

---

## Architecture

```mermaid
graph LR
    MR["MintAndRedeem (ProtectedContract)"] -->|"attemptOutflow / recordInflow"| CB["CircuitBreakerV2 (scoped limiter per contract)"]
    YW["ftYieldWrapperV2 (ProtectedContract)"] -->|"attemptOutflow / recordInflow"| CB
```

Circuit Breaker logic lives directly in each engine via the `ProtectedContract` mixin. There is no separate router contract — each protected contract calls the Circuit Breaker internally when processing outflows.

---

## How a Withdrawal Works

```mermaid
flowchart TD
    A["User calls withdraw / redeem"] --> B{"CB enabled?"}
    B -- NO --> C["Direct transfer to user (no rate limiting)"]
    B -- YES --> D{"Recipient whitelisted?"}
    D -- YES --> E["Transfer immediately (no buffer consumed)"]
    D -- NO --> F["CB checks capacity: available = min(mainBuffer, elasticBuffer)"]
    F --> G{"amount ≤ available?"}
    G -- YES --> H["IMMEDIATE: Tokens sent to user now"]
    G -- NO --> I["QUEUED: Tokens sent to CB escrow; queue entry created"]
    I --> J["After settlement delay: anyone calls executeQueued(); CB releases tokens to user"]

    style C fill:#d4edda,stroke:#28a745
    style E fill:#d4edda,stroke:#28a745
    style H fill:#d4edda,stroke:#28a745
    style I fill:#fff3cd,stroke:#ffc107
    style J fill:#d4edda,stroke:#28a745
```

**Key points for UI:**

- If the withdrawal is **immediate**, nothing special — the user gets their tokens in the same transaction.
- If the withdrawal is **queued**, the UI should show a pending state with a countdown to `settlesAt`. Once the delay passes, a "Claim" button (or backend keeper) calls `executeQueued(queueId)` to release the funds.
- `executeQueued` is **permissionless** — anyone can call it once the delay has elapsed. The UI can offer a "Claim" button to the user, or a backend keeper can auto-execute on their behalf.

### Step-by-Step

1. **Pre-check capacity** before the user submits:

    ```js
    const [wouldBeImmediate, availableCapacity] = await cb.checkOutflow(
        contract,
        asset,
        amount,
        tvl,
    );
    ```

2. **If queued**, track the queue entry via events:
    - Circuit Breaker emits: `OutflowQueued(queueId, asset, recipient, amount, settlesAt)`

3. **Wait for settlement:**

    ```js
    const remaining = await cb.timeUntilSettled(queueId); // seconds until executable
    const ready = await cb.isSettled(queueId); // true if executable now
    ```

4. **Execute** (anyone can call):

    ```js
    await cb.executeQueued(queueId);
    // or batch:
    await cb.executeQueuedBatch([queueId1, queueId2, queueId3]);
    ```

### Edge Case: Pre-Check Staleness

> **Note:** `checkOutflow` and `withdrawalCapacity` read the buffer state at call time. Between the moment the UI shows "This withdrawal will be instant" and the moment the user's transaction is mined, other transactions may consume buffer capacity. If that happens, the withdrawal that appeared instant will be **queued** instead.

The UI should handle this gracefully:

- **Always listen for both `OutflowImmediate` and `OutflowQueued` events** after a withdrawal transaction, regardless of what the pre-check indicated.
- If a pre-check said "instant" but the transaction emits `OutflowQueued`, transition the UI to the queued/countdown state.

**Recommended: show likelihood based on buffer headroom.** Rather than a binary "instant / queued" label, compare the user's amount against current capacity and convey confidence:

```js
const capacity = await cb.withdrawalCapacity(contract, asset, tvl);
const ratio = amount / capacity; // how much of the buffer this withdrawal would consume

if (ratio <= 0.5) {
    // Plenty of headroom — very unlikely to be front-run
    showMessage("This withdrawal will be processed instantly.");
} else if (ratio <= 0.9) {
    // Moderate headroom — possible but unlikely
    showMessage(
        "This withdrawal is expected to be instant, but may be queued if demand increases before confirmation.",
    );
} else if (ratio <= 1.0) {
    // Tight — high chance another tx consumes remaining capacity first
    showWarning(
        "This withdrawal is close to the instant limit and may be queued if other withdrawals are confirmed first.",
    );
} else {
    // Exceeds capacity — will definitely be queued
    showMessage(
        `This withdrawal exceeds the instant limit (${formatAmount(capacity)} available). It will be queued and claimable in ~6 hours.`,
    );
}
```

This gives users a realistic expectation without false precision. The exact thresholds are up to the UI team — the key insight is that `amount / capacity` near 1.0 means the outcome is sensitive to other pending transactions.

---

## Dual Buffer System

The rate limit is determined by the **minimum** of two independent buffers:

```mermaid
flowchart TB
    subgraph buffers["Two Independent Buffers"]
        direction TB

        subgraph main["Main Buffer"]
            direction TB
            M0["Time-replenishing"]
            M1["Cap = TVL × maxDrawRate (5%)"]
            M2["Replenishes linearly over mainWindow (24h)"]
            M3["Consumed by outflows"]
            M0 --> M1 --> M2 --> M3
        end

        subgraph elastic["Elastic Buffer"]
            direction TB
            E0["Deposit-tracking"]
            E1["Increases with each deposit"]
            E2["Decays linearly over elasticWindow (30 min)"]
            E3["Consumed first on outflows"]
            E0 --> E1 --> E2 --> E3
        end
    end

    M3 --> MIN["available = min(mainBuffer, elasticBuffer)"]
    E3 --> MIN
    MIN --> OUT{"withdrawal ≤ available?"}
    OUT -- YES --> IMM["Instant"]
    OUT -- NO --> Q["Queued"]

    style IMM fill:#d4edda,stroke:#28a745
    style Q fill:#fff3cd,stroke:#ffc107
```

**For the UI health gauge**, use `getAssetHealth()` which returns:

- `mainBuffer` / `mainBufferCap` — show as a percentage bar
- `elasticBuffer` — additional transient capacity from recent deposits
- `utilizationBps` — 0–10000, how much of the main buffer is consumed (0 = full capacity, 10000 = depleted)
- `pendingOutflows` — total value sitting in the queue for this asset
- `isPaused` — if true, all operations for this asset are halted

---

## Queue Entry States

A queued withdrawal moves through these states. The UI should reflect each:

```mermaid
stateDiagram-v2
    [*] --> Pending : Withdrawal exceeds rate limit

    Pending --> Paused : Admin/guardian paused this entry
    Paused --> Pending : Owner resumed this entry

    Pending --> Pending : Operator called speedUp() and settlesAt reduced

    Pending --> Claimable : settlesAt reached

    Claimable --> Executed : executeQueued() called and tokens sent to user
    Claimable --> Invalidated : Emergency recovery occurred and entry no longer valid

    Executed --> [*]
    Invalidated --> [*]
```

### UI State Mapping

| Queue Status          | `status` field | `settlesAt` vs `now`            | What to Show                                                                               |
| --------------------- | -------------- | ------------------------------- | ------------------------------------------------------------------------------------------ |
| **Pending (waiting)** | `Pending`      | `settlesAt > now`               | Countdown timer: "Claimable in X hours Y min"                                              |
| **Pending (sped up)** | `Pending`      | `settlesAt > now` (but reduced) | Updated countdown, maybe "Expedited" badge                                                 |
| **Claimable**         | `Pending`      | `settlesAt ≤ now`               | "Claim" button → calls `executeQueued(queueId)`                                            |
| **Paused**            | `Paused`       | N/A                             | "On hold — contact support". No claim button                                               |
| **Executed**          | Entry deleted  | N/A                             | "Completed" — entry no longer exists in storage                                            |
| **Invalidated**       | `Pending`      | Any                             | `executeQueued` will revert with `QueueInvalidated`. Show "Cancelled — emergency recovery" |

**How to detect invalidated entries:** Compare `queue.recoveryEpoch` with `cb.assetRecoveryEpoch(queue.token)`. If they differ, the entry is invalidated.

---

## Scoped Limiters

By default, all protected contracts share the same limiter state per asset. When **scoped limiter** is enabled for a contract, that contract gets its own isolated buffer state. This prevents one engine's activity from affecting another's capacity.

### Why Scoping Matters

```mermaid
graph TB
    subgraph problem["Shared State (default) — PROBLEM"]
        direction TB
        MR_S["MintAndRedeem (TVL = 100M)"] --> SHARED["shared buffer"]
        YW_S["ftYieldWrapper (TVL = 10M)"] --> SHARED
        SHARED --> OSC["Buffer cap oscillates between 5M and 500K on alternating calls"]
    end

    subgraph solution["Scoped State (opt-in) — SOLUTION"]
        direction TB
        MR_I["MintAndRedeem (TVL = 100M)"] --> BUF_MR["Own buffer cap = 100M × 5% = 5M"]
        YW_I["ftYieldWrapper (TVL = 10M)"] --> BUF_YW["Own buffer cap = 10M × 5% = 500K"]
        GLOBAL["Config (maxDrawRate, windows) and pause state remain GLOBAL"]
    end

    style OSC fill:#f8d7da,stroke:#dc3545
    style BUF_MR fill:#d4edda,stroke:#28a745
    style BUF_YW fill:#d4edda,stroke:#28a745
```

Each protected contract (MintAndRedeem, ftYieldWrapperV2) has its **own isolated rate-limit buffer**. This means:

- A large redemption on MintAndRedeem does **not** reduce capacity for ftYieldWrapperV2 withdrawals (and vice versa).
- When calling view functions, you must pass the correct `contract` address as the first argument to get that contract's buffer state.
- **Always use the 3-arg view overloads** that accept `(contract, asset, tvl)`. The 2-arg versions read shared state that scoped contracts don't use.

```js
// Correct — reads MintAndRedeem's own buffer
cb.withdrawalCapacity(mintAndRedeemAddr, ftUSDAddr, mintAndRedeemTvl);

// Correct — reads wrapper's own buffer
cb.withdrawalCapacity(wrapperAddr, ftUSDAddr, wrapperTvl);

// Wrong for scoped contracts — reads shared state (empty)
cb.withdrawalCapacity(ftUSDAddr, someTvl);
```

Check if a contract is scoped:

```js
const isScoped = await cb.isScopedLimiter(contractAddress);
```

---

## Whitelisted Recipients

The Circuit Breaker owner can whitelist specific recipient addresses. Withdrawals to a whitelisted address **always execute immediately** — they bypass the rate limiter entirely and do not consume any buffer capacity.

This is used for trusted protocol-owned addresses (e.g., treasury, other protocol contracts) that should never be rate-limited.

### How It Affects the UI

- Whitelisted recipients will **never** see a queued withdrawal, regardless of amount or buffer state.
- The flowchart above shows this path: if the recipient is whitelisted, the transfer is immediate with no buffer consumed.
- `checkOutflow` does **not** account for whitelisting — it only checks buffer capacity. A pre-check may report `wouldBeImmediate = false` for a large amount, but if the recipient is whitelisted the on-chain transaction will still execute immediately.

### Checking Whitelist Status

```js
// Check if a specific address is whitelisted
const isWhitelisted = await cb.isWhitelistedRecipient(recipientAddress);

// List all whitelisted addresses
const whitelist = await cb.getWhitelistedRecipients();
```

If your UI pre-checks withdrawal outcome, check whitelist status first to avoid showing a misleading "will be queued" warning:

```js
const isWhitelisted = await cb.isWhitelistedRecipient(userAddress);
if (isWhitelisted) {
    // Always instant — skip buffer capacity check
    showInstantWithdrawalUI();
} else {
    const [wouldBeImmediate, capacity] = await cb.checkOutflow(
        contract,
        asset,
        amount,
        tvl,
    );
    // Show instant or queued UI based on capacity
}
```

### Admin Management

Whitelist changes are owner-only and emit `RecipientWhitelistUpdated(recipient, enabled)`. Index this event to keep whitelist state current.

---

## Contract Calls Reference

All read calls below are `view` functions (no gas cost when called via `eth_call`).

### Before a Withdrawal (Pre-Check)

Use these to show the user what will happen before they submit:

| What You Need                              | Call                                            | Returns                                              |
| ------------------------------------------ | ----------------------------------------------- | ---------------------------------------------------- |
| Will this withdrawal be instant or queued? | `cb.checkOutflow(contract, asset, amount, tvl)` | `(bool wouldBeImmediate, uint256 availableCapacity)` |
| Max amount user can withdraw instantly     | `cb.withdrawalCapacity(contract, asset, tvl)`   | `uint256`                                            |
| Full buffer health for a gauge             | `cb.getAssetHealth(contract, asset, tvl)`       | `AssetHealth` struct (see below)                     |

> **Note:** `contract` is the address of the protected contract (e.g., MintAndRedeem or ftYieldWrapperV2), not the Circuit Breaker itself. `tvl` is the current TVL of that contract for the given asset — see below for how to obtain it.

### How to Obtain TVL

The Circuit Breaker view functions require a `tvl` parameter because the Circuit Breaker itself does not store TVL — it is supplied by the caller. Each protected contract computes TVL differently, and the on-chain `_getTvl()` override is `internal`, so the backend must call the appropriate public getter and apply the same floor logic.

| Protected Contract   | Public TVL Getter          | Units                     | Notes                                                                                                                                                                                                                                                                                                          |
| -------------------- | -------------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **MintAndRedeem**    | `accountedCollateralTvl()` | 6 decimals (ftUSD)        | Sum of `(totalIn - totalOut)` across enabled collaterals, normalized to 6 decimals. Does **not** use oracle prices — assumes 1:1 nominal value per collateral.                                                                                                                                                 |
| **ftYieldWrapperV2** | `valueOfCapital()`         | underlying token decimals | `balanceOf(underlying)` + sum of each strategy's `valueOfCapital()`. Note: does not normalize strategy position-token decimals to underlying decimals (the internal `_getTvl` does this normalization, but the public getter does not — in practice this is a no-op for Aave strategies where decimals match). |

**MintAndRedeem TVL floor:** The on-chain Circuit Breaker integration applies `max(accountedCollateralTvl(), minTVLForMint)` so the buffer cap never drops below `minTVLForMint * maxDrawRate`. The backend should replicate this:

```js
// MintAndRedeem TVL for Circuit Breaker view calls
const rawTvl = await mintAndRedeem.accountedCollateralTvl();
const minTvl = await mintAndRedeem.minTVLForMint();
const tvl = rawTvl > minTvl ? rawTvl : minTvl;

// ftYieldWrapperV2 TVL for Circuit Breaker view calls
const wrapperTvl = await wrapper.valueOfCapital();
```

If the wrong TVL is passed, the view functions will return incorrect capacity values (buffer cap is `tvl * maxDrawRate`), so getting this right is important.

### After a Queued Withdrawal (Queue Management)

| What You Need                     | Call                                           | Returns                                   |
| --------------------------------- | ---------------------------------------------- | ----------------------------------------- |
| List user's pending queue entries | `cb.getQueuedByRecipient(user, offset, limit)` | `QueuedOutflow[]` (paginated)             |
| Get all queue IDs for a user      | `cb.getQueueIdsByRecipient(user)`              | `uint256[]`                               |
| Get a single queue entry          | `cb.getQueued(queueId)`                        | `QueuedOutflow` struct                    |
| Is this entry ready to claim?     | `cb.isSettled(queueId)`                        | `bool`                                    |
| How long until claimable?         | `cb.timeUntilSettled(queueId)`                 | `uint256` (seconds remaining, 0 if ready) |

### Claiming (Executing a Queued Withdrawal)

| Action                 | Call                              | Notes                                 |
| ---------------------- | --------------------------------- | ------------------------------------- |
| Claim a single entry   | `cb.executeQueued(queueId)`       | Permissionless — any address can call |
| Claim multiple entries | `cb.executeQueuedBatch(queueIds)` | Array of IDs, all executed in one tx  |

These are write transactions. They will revert if:

- The system is globally paused
- The asset is paused
- The entry has `Paused` status (admin hold)
- The settlement delay hasn't passed yet
- The entry was invalidated by emergency recovery
- The healthcheck contract (if set) returns `false`

### System Status (Dashboard / Monitoring)

| What You Need                      | Call                        | Returns                                                                |
| ---------------------------------- | --------------------------- | ---------------------------------------------------------------------- |
| Overall system status              | `cb.getSystemStatus()`      | `(active, admin, guardian, delay, numProtected, numAssets, numQueued)` |
| Is system paused?                  | `cb.paused()`               | `bool`                                                                 |
| Settlement delay                   | `cb.settlementDelay()`      | `uint256` (seconds)                                                    |
| Total queued items                 | `cb.activeQueueCount()`     | `uint256`                                                              |
| Pending outflow value for an asset | `cb.pendingOutflows(asset)` | `uint256`                                                              |

### Enumeration

| What You Need                                 | Call                            | Returns     |
| --------------------------------------------- | ------------------------------- | ----------- |
| All registered protected contracts            | `cb.getProtectedContracts()`    | `address[]` |
| All assets with limiter state                 | `cb.getTrackedAssets()`         | `address[]` |
| Whitelisted recipients (bypass rate limiting) | `cb.getWhitelistedRecipients()` | `address[]` |
| Per-contract isolation check                  | `cb.isScopedLimiter(contract_)` | `bool`      |

---

## Data Structures

### QueuedOutflow

Returned by `getQueued()` and `getQueuedByRecipient()`:

| Field           | Type          | Description                                                            |
| --------------- | ------------- | ---------------------------------------------------------------------- |
| `token`         | `address`     | The ERC-20 token being withdrawn                                       |
| `queuedAt`      | `uint40`      | Timestamp when the entry was created                                   |
| `settlesAt`     | `uint40`      | Timestamp when the entry becomes claimable                             |
| `status`        | `QueueStatus` | `0` = Pending, `1` = Paused                                            |
| `recipient`     | `address`     | Who receives the tokens on execution                                   |
| `recoveryEpoch` | `uint64`      | Epoch at queue time; if `assetRecoveryEpoch` differs, entry is invalid |
| `amount`        | `uint256`     | Amount of `token` to be transferred                                    |

### AssetHealth

Returned by `getAssetHealth()`:

| Field             | Type      | Description                                            |
| ----------------- | --------- | ------------------------------------------------------ |
| `mainBuffer`      | `uint256` | Current main buffer capacity remaining                 |
| `mainBufferCap`   | `uint256` | Maximum main buffer capacity (`TVL * maxDrawRate`)     |
| `elasticBuffer`   | `uint256` | Current elastic buffer capacity remaining              |
| `totalCapacity`   | `uint256` | `mainBuffer + elasticBuffer`                           |
| `pendingOutflows` | `uint256` | Total value queued but not yet executed for this asset |
| `utilizationBps`  | `uint256` | 0–10000, percentage of main buffer consumed            |
| `isPaused`        | `bool`    | Whether this asset is paused                           |

### SystemStatus

Returned by `getSystemStatus()`:

| Field                   | Type      | Description                             |
| ----------------------- | --------- | --------------------------------------- |
| `active`                | `bool`    | `true` if not globally paused           |
| `admin`                 | `address` | Owner address (multisig/governance)     |
| `guardianAddr`          | `address` | Guardian — can pause but not unpause    |
| `delay`                 | `uint256` | Current settlement delay in seconds     |
| `numProtectedContracts` | `uint256` | Count of registered protected contracts |
| `numTrackedAssets`      | `uint256` | Count of assets with limiter history    |
| `numQueuedOutflows`     | `uint256` | Current open queue entries              |

---

## Events Reference

### Outflow Lifecycle

| Event                                                         | When Emitted                          | Key Fields                                   |
| ------------------------------------------------------------- | ------------------------------------- | -------------------------------------------- |
| `Inflow(asset, amount, newTvl)`                               | Deposit/mint recorded                 | `newTvl` = TVL after inflow                  |
| `OutflowImmediate(asset, to, amount)`                         | Withdrawal within capacity            | Instant transfer happened                    |
| `OutflowQueued(queueId, asset, recipient, amount, settlesAt)` | Withdrawal exceeds capacity           | `settlesAt` = earliest execution time        |
| `OutflowLimiterContext(queueId, limiterAsset, transferToken)` | Queued with limiter != transfer token | Links the limiter bucket to the actual token |
| `OutflowExecuted(queueId, recipient, asset, amount)`          | Queued withdrawal settled             | Tokens transferred to recipient              |

### Queue State Changes

| Event                                             | When Emitted                        |
| ------------------------------------------------- | ----------------------------------- |
| `OutflowPaused(queueId, recipient)`               | Admin/guardian paused a queue entry |
| `OutflowResumed(queueId, recipient)`              | Owner resumed a paused queue entry  |
| `OutflowSpedUp(queueId, recipient, newSettlesAt)` | Operator/owner shortened the delay  |

### System State Changes

| Event                    | When Emitted                                       | UI Action                                   |
| ------------------------ | -------------------------------------------------- | ------------------------------------------- |
| `Paused(by)`             | Global pause activated                             | Show global banner                          |
| `Unpaused()`             | Global pause lifted                                | Remove banner                               |
| `AssetPaused(asset, by)` | Individual asset paused                            | Show per-asset banner                       |
| `AssetUnpaused(asset)`   | Individual asset unpaused                          | Remove per-asset banner                     |
| `AssetTracked(asset)`    | First time an asset interacts with Circuit Breaker | Use for indexing new assets without polling |

### Configuration Changes

| Event                                            | When Emitted                                                           |
| ------------------------------------------------ | ---------------------------------------------------------------------- |
| `ConfigUpdated(asset, config)`                   | Rate limit parameters changed (`asset = address(0)` for default)       |
| `DelayUpdated(newDelay)`                         | Settlement delay changed                                               |
| `ProtectedContractUpdated(contract_, enabled)`   | Contract registered/removed                                            |
| `ScopedLimiterUpdated(contract_, enabled)`       | Per-contract isolation toggled                                         |
| `GuardianUpdated(newGuardian)`                   | Guardian role changed                                                  |
| `OperatorUpdated(newOperator)`                   | Operator role changed                                                  |
| `HealthcheckUpdated(newHealthcheck)`             | Healthcheck contract changed                                           |
| `RecipientWhitelistUpdated(recipient, enabled)`  | Whitelist entry added/removed                                          |
| `EmergencyOverride(contract_, asset, amount)`    | Elastic buffer manually inflated (`contract_ = address(0)` for shared) |
| `EmergencyRecovery(asset, to, amount, newEpoch)` | All tokens swept, all queued entries invalidated                       |

---

## Default Parameters

| Parameter         | Default        | Description                                          |
| ----------------- | -------------- | ---------------------------------------------------- |
| `maxDrawRateWad`  | 5% (`0.05e18`) | Max outflow as % of TVL before queueing              |
| `mainWindow`      | 24 hours       | Main buffer fully replenishes over this window       |
| `elasticWindow`   | 30 minutes     | Elastic buffer fully decays over this window         |
| `settlementDelay` | 6 hours        | Time before queued entries become claimable          |
| `minTVLForMint`   | 500,000 ftUSD  | Floor TVL to prevent rate-limit gaming at low supply |

---

## Example UI Flows

### Flow 1: User Withdraws (Instant)

1. User enters amount, clicks "Withdraw"
2. **Pre-check:** Call `cb.checkOutflow(contract, asset, amount, tvl)` → `wouldBeImmediate = true`
3. Show: "This withdrawal will be processed instantly"
4. User submits tx → tokens arrive in wallet
5. Listen for `OutflowImmediate` event → show success

### Flow 2: User Withdraws (Queued)

1. User enters amount, clicks "Withdraw"
2. **Pre-check:** Call `cb.checkOutflow(contract, asset, amount, tvl)` → `wouldBeImmediate = false, availableCapacity = X`
3. Show: "This withdrawal exceeds the instant limit (X available). It will be queued and claimable in ~6 hours."
4. User confirms → tx queues the withdrawal
5. Listen for `OutflowQueued` event → show pending state with countdown to `settlesAt`
6. Periodically call `cb.timeUntilSettled(queueId)` to update countdown
7. When `timeUntilSettled` returns `0` → show "Claim" button
8. User clicks "Claim" → calls `cb.executeQueued(queueId)` → tokens arrive
9. Listen for `OutflowExecuted` event → show "Completed"

### Flow 3: Queued Entry Gets Paused

1. Entry is in "Pending" state with countdown
2. Listen for `OutflowPaused(queueId)` event
3. Switch to "On hold — under review" state, hide countdown
4. If `OutflowResumed(queueId)` fires → return to countdown state

### Flow 4: Queued Entry Gets Sped Up

1. Entry is in "Pending" state with countdown
2. Listen for `OutflowSpedUp(queueId, recipient, newSettlesAt)` event
3. Update countdown to new `settlesAt`, optionally show "Expedited" badge

---

## Keeper / Bot Integration

### Executing Queued Outflows

A keeper bot should:

1. **Index `OutflowQueued` events** to track pending entries.
2. **Poll `isSettled(queueId)`** or compute `settlesAt` from the event.
3. **Call `executeQueued(queueId)`** or `executeQueuedBatch(ids)` when ready.
4. **Handle reverts**:
    - `QueueNotSettled` — too early, retry later.
    - `QueueInvalidated` — emergency recovery happened, skip this entry.
    - `GloballyPaused` / `AssetPausedError` — system paused, wait for `Unpaused`/`AssetUnpaused`.
    - `InvalidStatus` — entry was paused by admin, wait for `OutflowResumed`.
    - `HealthcheckFailed` — healthcheck contract rejected, investigate.

### Batch Execution Strategy

For gas efficiency, batch multiple settled entries:

```js
const allIds = await cb.getQueueIdsByRecipient(user); // or index from events
const settled = [];
for (const id of allIds) {
    if (await cb.isSettled(id)) settled.push(id);
}
if (settled.length > 0) {
    await cb.executeQueuedBatch(settled);
}
```

---

## Monitoring Alerts

Recommended event-based alerts for infra/ops:

| Alert               | Trigger                                       | Severity |
| ------------------- | --------------------------------------------- | -------- |
| Rate limit pressure | `OutflowQueued` frequency increases           | Medium   |
| Emergency           | `EmergencyRecovery` or `Paused` emitted       | Critical |
| Config change       | `ConfigUpdated` or `DelayUpdated` emitted     | Info     |
| Large override      | `EmergencyOverride` with significant `amount` | High     |
| Asset paused        | `AssetPaused` emitted                         | High     |
| Guardian change     | `GuardianUpdated` emitted                     | Info     |
| Scoping change      | `ScopedLimiterUpdated` emitted                | Medium   |

---

## Admin Operations

### Roles

| Role         | Set By                           | Permissions                                                                        |
| ------------ | -------------------------------- | ---------------------------------------------------------------------------------- |
| **Owner**    | 2-step transfer (`Ownable2Step`) | Full admin: config, pause/unpause, resume queued, emergency recover, set all roles |
| **Guardian** | Owner                            | Pause globally, pause per-asset, pause individual queue entries                    |
| **Operator** | Owner                            | `speedUp()` queued outflows (reduce `settlesAt`)                                   |

### speedUp

`speedUp(queueId, newSettleDelay)` reduces the settlement time on a pending entry. The new `settlesAt` is set to `block.timestamp + newSettleDelay` — passing `0` makes it instantly claimable. The call reverts if the new time would be later than the current `settlesAt` (can only speed up, never delay further).

**Current state:** The operator is a single address (EOA or multisig).

### Emergency Recovery

`emergencyRecover(asset, to)` transfers all held tokens for an asset and increments the asset's recovery epoch, invalidating all pending queue entries for that asset.

After recovery:

- View functions (`isSettled`, `timeUntilSettled`) may still return stale values for invalidated entries. Only `executeQueued` checks the epoch and reverts.
- `activeQueueCount` is not decremented for invalidated entries.
- The Circuit Breaker instance should be replaced with a fresh proxy after recovery.

### Future: Operator Contract with Relayer Support

A dedicated operator contract could replace the single-address operator to enable:

- **Relayer / multisig access** — Multiple authorized relayers can call `speedUp` through the operator contract without each needing the operator role on the Circuit Breaker.
- **Fee marketplace for queue acceleration** — Users with queued outflows offer a fee (tip) to incentivize a relayer to `speedUp` their entry. The operator contract escrows the bounty, the relayer calls `speedUp` through it, and the bounty pays out on success.
- **Policy rules** — The operator contract could enforce constraints like minimum remaining delay or per-asset cooldowns before allowing a speed-up.

This is planned for future exploration.

---

## Healthcheck & Future Improvements

The Circuit Breaker has an optional `healthcheck` contract slot that is checked at `executeQueued` time. If set and it returns `false`, the claim reverts. **No healthcheck is deployed at launch** — the slot is `address(0)`.

### Why the 6-Hour Default Delay

Without automated checks, the settlement delay is the team's window to detect and manually pause a malicious outflow. 6 hours was chosen to ensure coverage across all timezones.

### Planned Improvements (Post-Launch)

These would allow reducing the settlement delay:

| Approach                              | Target Delay          | How It Would Work                                                        |
| ------------------------------------- | --------------------- | ------------------------------------------------------------------------ |
| **Current (no healthcheck)**          | 6 hours               | Team monitors and pauses manually                                        |
| **On-chain invariant healthcheck**    | ~30 min–1 hour        | `executeQueued` auto-reverts on invalid state                            |
| **Off-chain threat detection keeper** | ~15–30 min            | Keeper monitors for exploits, sets an unhealthy flag to block all claims |
| **Keeper-enabled guardian contract**  | ~15–30 min            | Automated keepers call `pause()` via a guardian contract within seconds  |
| **Combined**                          | Lowest possible delay | Defense in depth: all of the above                                       |

---

## Audit Delta (CS-FTMPR)

Changes from the ChainSecurity audit that affect UI/infra:

### New Event: `AssetTracked`

```solidity
event AssetTracked(address indexed asset);
```

Emitted once per asset on first interaction. Use for indexing new assets without polling `getTrackedAssets()`.

### New Event: `ScopedLimiterUpdated`

```solidity
event ScopedLimiterUpdated(address indexed contract_, bool enabled);
```

When a contract switches to scoped limiter mode, UI must use the 3-arg view overloads for that contract's health/capacity.

### New View Overloads (Scoped)

Three existing views now have overloads that accept a `contract_` parameter:

- `getAssetHealth(contract_, asset, tvl)`
- `withdrawalCapacity(contract_, asset, tvl)`
- `checkOutflow(contract_, asset, amount, tvl)`

These return the scoped contract's isolated buffer state. Falls back to shared state if the contract is not scoped.

### `EmergencyOverride` Event Includes `contract_`

```solidity
event EmergencyOverride(address indexed contract_, address indexed asset, uint256 amount);
```

`contract_ = address(0)` for shared state overrides, actual address for scoped overrides.

### `OutflowLimiterContext` Event

```solidity
event OutflowLimiterContext(uint256 indexed queueId, address indexed limiterAsset, address indexed transferToken);
```

Companion event emitted alongside `OutflowQueued` when `limiterAsset != transferToken`. Links the rate-limit bucket to the actual token being transferred. Relevant for wrapper withdrawals where the limiter is the wrapper token but the transfer is a strategy position token.

### `QueueStatus` Enum Simplified

Removed unused `Executed` variant. Now only:

```solidity
enum QueueStatus { Pending, Paused }
```

If your indexer tracked `Executed = 2`, remove it. Executed entries are deleted from storage (amount becomes 0).
====
docs/guides/intent-whitelist.md

---
title: Intent Whitelist
description: Interest-based whitelist allocation process
image: docs-og.png
---

## Overview

> **Note:** The Intent Whitelist is finalized. No additional activity can change it.

The Intent Whitelist is an early round for participants who register interest by submitting the intent form. This round does not require KYC and has the same terms as all other rounds: 1 FT = \$0.10.

> **Note:** Provide your wallet address, chain, asset, and amount in the intent form, and pass the Flying Tulip Accredited Investor [quiz](https://flyingtulip.com/quiz).

In this round, commitments are collected per network; you choose the network and token you plan to commit on.

## How allocation works

1. We collect interest from addresses that submit the intent form, per network. You choose the network and accepted token, and may set a minimum and a maximum you are comfortable with. No funds are transferred at this step.
2. After signups close, we calculate a single base minimum per address using the total round pool and the number of participants (the same logic applies per network respecting that network's capacity).
3. If your stated minimum is above the base minimum, you are excluded from this round to respect your preference.
4. We notify you of your allocation and provide a short claim window to transfer funds on that network.
5. If there is FT left over, we split that remainder proportionally based on how much extra each person can still take. If combined headroom exceeds the remainder, it's pro‑rata. Otherwise everyone fills to their max.

### What you need to choose

- **Network + token:** where you plan to commit your capital (refer to the [Public Sale guide](sale-process.md) for the list of tokens and networks).
- **Minimum:** defaults to the round's base minimum. Only set it if you want to enforce a higher personal floor. Setting it above the base will exclude you from this round.
- **Maximum:** the most you would accept if there’s leftover. Set this if you want to be considered for more than the base minimum during the pro‑rata step.

### Claiming and waves

- No upfront capital is required during this commitment phase. You only send funds after receiving your final allocation. All claim and transfer instructions for the whitelist will be announced exclusively through the official Flying Tulip socials. Stay tuned.
- We may run multiple waves. Any final remainder after waves (or if there’s no remaining headroom) rolls into later rounds/Public Sale. You can still participate in those later rounds.
====
docs/guides/relayers-and-session-keys.md

---
title: Relayers and Session Keys
description: Gasless and delegated execution for ftUSD and staking flows
image: docs-og.png
---

## Overview

Relayers and session keys are the building blocks for gasless and delegated UX in the ftUSD ecosystem.

- **Relayer**: a service or address that submits transactions and pays gas.
- **Session key**: a delegate key a user authorizes ahead of time with strict limits and an expiry.

Together, they let a relayer execute actions on a user's behalf. With sessions, users can avoid signing every transaction by delegating limited authority to a session key.

## How session keys work

A session is an on-chain authorization that binds a delegate key to a specific scope. Users create a session once, and the session key can then sign per-action intents until the session expires, is revoked, or its limits are exhausted.

Typical session fields:

- Delegate public key
- Expiry time
- Allowed contracts
- Per-asset spend limits
- Optional call limits
- Max relayer fee

## High-level flow

1. **User creates a session** (via `SessionManager` or the app), specifying the delegate key and limits.
2. **Delegate signs an intent** for a specific action (for example, stake or redeem with slippage bounds).
3. **Intent is handed to a relayer** (typically via an API), which submits it to the contract and pays gas (charging a fee capped by the session).
4. **Contract validates** the session and intent (delegate key, approved relayer, nonce, limits, fee cap).
5. **Action executes** if all checks pass (including balances/allowances for the action).

> **Note:** Sessions are always bounded. Users can revoke sessions or invalidate specific nonces at any time.

## Where relayers and session keys show up

### Relayer-friendly flows

For example, `MintAndRedeem` in ftUSD supports `*WithPermit` functions that combine [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) permits with an [EIP-712](https://eips.ethereum.org/EIPS/eip-712) engine authorization. This lets relayers submit mint/redeem actions while the user signs only the required message(s):

- First use: `permit` + engine authorization (2 signatures).
- Subsequent uses: engine authorization only (1 signature) if the permit sets a persistent allowance (for example, max), otherwise a new permit may be needed when the allowance runs out.

Another example is `EpochRewardsVault`, which supports authorization-based relayer entrypoints like `depositWithPermit` and `withdrawWithAuthorization`.

### Session-based flows

For example, `EpochRewardsVault` supports session-based entrypoints for delegated staking and rewards:

- `depositWithSessionAndPermit`
- `withdrawWithSession`
- `claimWithSession`

These accept a session signature (and optional permit), so a relayer can execute actions on the user's behalf.
====
docs/guides/sale-process.md

---
title: Public Sale
description: Accepted assets, caps, and yield priorities
sidebar_position: 2
image: docs-og.png
---

## Prepare for Flying Tulip Public Sale

> **Note:** The Public Sale is currently closed.

The Public Sale has 4 rounds:

1. **Early access**: available for Impossible[^1] and Coinlist[^2] communities.

2. **Supporter whitelist**: available for whitelisted addresses based on published historical participation criteria across YFI, KP3R, and FTM/S.

3. **Intent whitelist**: available for users who showed early interest in Flying Tulip.

4. **Public Sale**: available for everyone to participate.

> **Note:** All rounds have exactly the same terms: **1 FT = \$0.10**.

Withdrawals of FT from the Perpetual PUT will be enabled once **all** sale rounds (early access, supporter and intent whitelists, and the Public Sale) conclude.

The Public Sale has a **\$1B maximum cap**, not a target. You can follow progress live on the Public Sale [dashboard](https://flyingtulip.com/allocation/dashboard).

Capital raised in the Public Sale is not distributed to the team as sale proceeds. Perpetual PUT backing capital is deployed into conservative, liquid strategies.

## Networks and Accepted Tokens

Flying Tulip Public Sale commits are currently accepted only on Ethereum.

- Ethereum: USDT, USDC, USDS, USDtb, USDe, WETH

> **Note:** It is not necessary to bridge tokens as long as they are held on the right network.

## Network Caps

Flying Tulip Public Sale is a challenge in itself. It can't be run concurrently since the token distribution is unknown, and those tokens should be moved to the relevant contracts.

Flying Tulip aims for the lowest risk and "available at any time for withdrawal" strategies. With this in mind, it occupies at most 5% of the strategy's Total Value Locked (TVL), meaning $$\max_{\text{allocation}} \le 0.05 \times TVL_{\text{strategy}}$$. This, together with accepted tokens, translates to Public Sale limits for each network.

Table[^3] below lists the networks, accepted tokens, and strategies to which capital will be allocated, along with each strategy’s approximate Annual Percentage Yield (APY), Total Value Locked (TVL), and maximum capital allocation. Networks other than Ethereum are shown as planned capacity.

| Network   | Token | Strategy                                       | APY   | Total Value Locked (TVL)  | Maximum Capital Allocation |
| --------- | ----- | ---------------------------------------------- | ----- | --------------------------| -------------------------- |
| Ethereum  | USDT  | Aave[^4]                                       | 5.05% | \$6,410,000,000.00        | \$320,500,000.00           |
|           | USDC  | Aave                                           | 4.00% | \$5,780,000,000.00        | \$289,000,000.00           |
|           | USDS  | Aave                                           | 4.24% | \$73,670,000.00           | **\$3,683,500.00**         |
|           | USDtb | Aave                                           | 7.29% | \$102,000,000.00          | **\$5,100,000.00**         |
|           | USDe  | Aave                                           | 8.17% | \$1,440,000,000.00        | **\$72,000,000.00**        |
|           | WETH  | Aave                                           | 1.59% | \$10,470,000,000.00       | \$523,500,000.00           |
|           |       |                                                |       | **Network Max**           | \$80,783,500.00            |
| Avalanche | wAVAX | Aave                                           | 1.23% | \$462,340,000.00          | \$23,117,000.00            |
|           |       | BenQI[^5] Staking                              | 5.02% | \$499,268,767.00          | \$24,963,438.35            |
|           | USDC  | Aave                                           | 6.30% | \$203,450,000.00          | \$10,172,500.00            |
|           | USDT  | Aave                                           | 5.65% | \$101,790,000.00          | \$5,089,500.00             |
|           |       |                                                |       | **Network Max**           | \$63,342,438.35            |
| Sonic     | wS    | Aave                                           | 1.25% | \$29,250,000.00           | \$1,462,500.00             |
|           |       | Beets[^6] Staked S                             | 3.79% | \$67,919,046.00           | \$3,395,952.30             |
|           | USDC  | Aave                                           | 6.41% | \$24,780,000.00           | \$1,239,000.00             |
|           |       |                                                |       | **Network Max**           | \$6,097,452.30             |
| Base      | USDC  | Aave                                           | 5.79% | \$357,150,000.00          | \$17,857,500.00            |
|           | WETH  | Aave                                           | 1.78% | \$545,650,000.00          | \$27,282,500.00            |
|           |       |                                                |       | **Network Max**           | \$45,140,000.00            |
| BSC       | WBNB  | Lista DAO[^7]                                  | 8.95% | \$1,070,849,518.29        | \$53,542,475.91            |
|           |       |                                                |       | **Network Max**           | \$53,542,475.91            |
| Solana    | USDC  | Kamino[^8]                                     | 4.50% | \$468,020,000.00          | \$23,401,000.00            |
|           | wSOL  | Kamino                                         | 5.11% | \$710,650,000.00          | \$35,532,500.00            |
|           |       | Jito[^9] Staked SOL                            | 6.57% | \$3,064,310,353.00        | \$153,215,517.65           |
|           |       | Jupiter[^10] Staked SOL                        | 7%    | \$1,125,058,402.00        | \$56,252,920.10            |
|           |       | Marinade[^11] Staked SOL                       | 7.01% | \$907,032,877.00          | \$45,351,643.85            |
|           |       |                                                |       | **Network Max**           | \$313,753,581.60           |
|           |       |                                                |       | **Total Max**             | \$562,659,448.16           |

## Waterfall Approach

Flying Tulip follows a "waterfall approach" for the Public Sale based on networks, tokens, caps, and **yield priority** from the table above.

- **Ethereum**: USDe up to \$72m, USDtb up to \$5.1m, and USDS up to \$4m.

> **Note:** If Ethereum caps are not met, then the remainder is filled with other eligible Ethereum assets (e.g. USDT, USDC, and WETH), subject to policy and available liquidity.

---

## FAQ

**How can I apply for the whitelist?**\
The supporter round is fixed by a completed snapshot using published criteria. The intent whitelist requires showing interest when the form is open.

**How much FT will be available in the public sale after the whitelist round?**\
The remainder after the early access & whitelist rounds. Minimum 0 FT, maximum 8,000,000,000 FT.

**Is there a limit per address?**\
In the supporter whitelist and intent whitelist rounds, yes; in the public sale round, no.

**When will FT be launched?**\
It will already be launched before the Public Sale.

**Will FT be listed on exchanges?**\
No exchange listings are planned. The Flying Tulip exchange will be the dominant trading venue.

**Are there any fees associated with the Public Sale?**\
No.

**Do I need to pay any fees when withdrawing FT from the FT NFT (the Perpetual PUT) or submitting it to Exit at par for my initial capital?**\
No. Withdrawing or Exiting at par from your Perpetual PUT does not incur protocol fees.

**Does the Public Sale have the same terms as the private sale?**\
Yes. All rounds have the same terms: 1 FT = \$0.10 (no round-based discounts or premiums).

**What is the longest Exit period for returning FT for investment?**\
Indefinite.

**If I deposit non-stablecoin as investment, how is it calculated?**\
Flying Tulip calculates the \$ value of the deposited non-stablecoin at the time of deposit for the purpose of issuing FT at a ratio of 10FT per \$1 deposited.

**Assuming there is available Aave liquidity and I deposited USDC into the sale on Ethereum, how fast will I get my funds back if I Exit at par?**\
Instant.

**Can I deposit my FT back into the FT NFT (the Perpetual PUT) representing my position?**\
No. Once you withdraw FT, the portion of the Perpetual PUT is permanently closed.

**Can I bridge my Perpetual PUT (FT NFT)?**\
We did not plan any bridges, but there are no technical limits to bridges, so while we did not specifically build bridging support, it is not technically disallowed.

**Will there be a secondary market for the Perpetual PUT NFTs?**\
Yes, we will be launching on the same day.

**Is there a minimum/maximum investment amount?**\
For Impossible & Coinlist, this is up to their discretion. In our two whitelist rounds, yes, there is a maximum; for the public sale, no.

**If I deposit USDC on Ethereum, can I Exit at par for USDC on other chains?**\
No, we do not take any bridge risks; you can only Exit at par on the same network that you contributed to.

**Do I need to KYC for the public sale?**\
No.

---

[^1]: Impossible: [website](https://impossible.finance)
[^2]: Coinlist: [website](https://coinlist.co)
[^3]: Data from 2025-10-06
[^4]: Aave: [website](https://aave.com)
[^5]: BenQI: [website](https://benqi.fi)
[^6]: Beets: [website](https://beets.fi/stake)
[^7]: Lista DAO: [website](https://lista.org)
[^8]: Kamino: [website](https://kamino.com)
[^9]: Jito: [website](https://www.jito.network)
[^10]: Jupiter: [website](https://vote.jup.ag)
[^11]: Marinade: [website](https://marinade.finance)
====
docs/guides/supporter-whitelist.md

---
title: Supporter Whitelist
description: Eligibility criteria and allocation process
image: docs-og.png
---

## Overview

> **Note:** The Supporter Whitelist is finalized. No additional activity can change it.

The Supporter Whitelist is an early round for selected participants based on predetermined criteria. This round does not require KYC and has the same terms as all other rounds: 1 FT = \$0.10.

> **Note:** No additional action is required to qualify for this round.

In this round, commitments are collected per network, supporters have to choose the network and token they plan to commit on that network.

> **Note:** No upfront transfer during Support Whitelist round is required. Capital allocation will be announced later.

## Eligibility criteria

One-time snapshot was taken to create a list of supporter addresses which met the historical participation criteria. The list contains 8707 wallets across Yearn, Keep3r Network and Fantom/Sonic ecosystems; and 1648 X accounts.

> **Note:** Eligibility has been pre-determined; no additional activity can change it.

### Yearn

1. Collect all voters in the early Yearn governance [contract](https://etherscan.io/address/0xBa37B002AbaFDd8E89a1995dA52740bbC013D992).
2. Collect all users who transferred YFI within the first three months after launch.
3. From that cumulative set, only pick wallets still holding YFI at the snapshot time.

### Keep3r Network

1. Collect all [vKP3R](https://etherscan.io/address/0x2FC52C61fB0C03489649311989CE2689D93dC1a2) lockers.
2. Exclude short initial locks even if later relocked. Only full-conviction positions with an initial lock of roughly above 1 year are eligible (the original lock UI was just under 1 year, hence, allowed that buffer).

### Fantom/Sonic

1. Collect all FTM stakers and all S stakers, tracking each wallet’s both total staked amounts.
2. Drop wallets whose sum of all S stake minus sum of all FTM stake is negative (to favor full-conviction S staking and penalize repeated FTM restakes unless matched by S stake).

### X (Twitter)

People who interacted with [Flying Tulip X](https://x.com/flyingtulip_) early will be whitelisted.

## Example Scenario

Let's work out an example scenario on how much FT whitelisted accounts could expect.

With all 10,355 eligible addresses signing up and 4b FT available for the Supporter Whitelist round that is roughly 386,280 FT per person (\$38,628 at \$0.10 per FT), and then:

- Base minimum is 386,280 FT.
- Anyone who set their minimum >386,280 FT drops from the Supporter Whitelist round (you can still join later rounds).
- After giving 386,280 FT to everyone still in, we allocate the remainder pro‑rata based on each person's "headroom" (their maximum minus 386,280 FT), up to their maximum.

This way, people who are comfortable taking more can get more, but nobody who stays in gets less than the announced base minimum.

## How allocation works

1. We collect interest from eligible addresses, per network. You choose the network and accepted token, and may set a minimum and a maximum you are comfortable with. No funds are transferred at this step.
2. After signups close, we calculate a single base minimum per address using the total round pool and the number of participants (the same logic applies per network respecting that network's capacity).
3. If your stated minimum is above the base minimum, you are excluded from this round to respect your preference.
4. We notify you of your allocation and provide a short claim window to transfer funds on that network.
5. If there is FT left over, we split that remainder proportionally based on how much extra each person can still take. If combined headroom exceeds the remainder, it's pro‑rata. Otherwise everyone fills to their max.

### What you need to choose

- **Network + token:** where you plan to commit your capital (refer to the [Public Sale guide](sale-process.md) for the list of tokens and networks).
- **Minimum:** defaults to the round's base minimum. Only set it if you want to enforce a higher personal floor. Setting it above the base will exclude you from this round.
- **Maximum:** the most you would accept if there’s leftover. Set this if you want to be considered for more than the base minimum during the pro‑rata step.

### Claiming and waves

- No upfront capital is required during this commitment phase. You only send funds after receiving your final allocation. All claim and transfer instructions for the whitelist will be announced exclusively through the official Flying Tulip socials. Stay tuned.
- We may run multiple waves. Any final remainder after waves (or if there’s no remaining headroom) rolls into later rounds/public sale. You can still participate in those later rounds.
====
docs/overview/flying-tulip.md

---
title: Flying Tulip
sidebar_position: 1
image: docs-og.png
description: "Flying Tulip simplified: making advanced DeFi accessible"
---

## 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 based on 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 accrue base yield while also securing lending, resting CLOB orders, or futures collateral, 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 has its own silos collateral. You supply to a lending market, and that capital cannot simultaneously back orders or collateral. Flying Tulip's permissioned credit layer supports cross‑collateral, so one deposit can secure multiple activities at once while still accruing its base yield.

**Fragmented liquidity and static pricing.** Traditional AMMs `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 Spot 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‑collateralization 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 Futures 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: Spot (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 guardrail 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 use these windows as sources of executable price and depth.

#### Lending: permissionless pairs and a permissioned cross‑collateral pool

- **Permissionless Lend**: every Spot pair exposes a lending market automatically. Borrowing power is size‑ and depth‑aware (from Spot 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/Futures. A debt‑netting mechanism enables delta‑neutral constructions (e.g., ftUSD) with near‑zero conventional liquidation paths under configured bounds. One deposit can accrue a money‑market yield while backing orders and futures collateral simultaneously.

#### Perpetual futures: oracleless, depth‑aware

FT Futures 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 accrue 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 (unstaked ftUSD proceeds accrue to the protocol). Users who want to 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 capital), 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 Spot 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 cashflows

Protocol cashflows (trading, lending, futures, insurance, settlement rails) feed a buyback pipeline for FT. Where policy specifies, bought FT is distributed to users via product programs; burns reduce supply directly. Revenue‑funded burns govern unlocks (Foundation/Team/Incentives 40:40:20, one‑for‑one); interest‑only (backing capital 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 Spot's depth informs LTVs and liquidations; the same windows govern future 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.
====
docs/product-suite/index.md

---
title: Flying Tulip Product Suite
description: Learn more about Flying Tulip ecosystem
sidebar_position: 1
image: docs-og.png
---

<div className="product-grid product-grid--suite">
  <a href="/product-suite/ft-token" className="product-card">
    <img src="../img/Flying Tulip_FT.webp" alt="Flying Tulip Token" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Token</strong>
      <p>Revolutionary tokenomics with Perpetual PUT rights and sustainable buyback-and-burn funded by protocol yield and revenue.</p>
    </div>
  </a>
  <a href="/product-suite/ft-usd" className="product-card">
    <img src="../img/Flying Tulip_FTUSD.webp" alt="Flying Tulip ftUSD" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">ftUSD</strong>
      <p>A next-generation stablecoin that generates 7-8% Annual Percentage Yield (APY) through delta-neutral strategies while maintaining a perfect $1 peg.</p>
    </div>
  </a>
  <a href="/product-suite/ft-spot" className="product-card">
    <img src="../img/Flying Tulip_Spot.webp" alt="Flying Tulip Spot" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Spot</strong>
      <p>Adaptive trading pools that automatically adjust between efficiency during calm markets and protection during volatility.</p>
    </div>
  </a>
  <a href="/product-suite/ft-futures" className="product-card">
    <img src="../img/Flying Tulip_Futures.webp" alt="Flying Tulip Futures" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Futures</strong>
      <p>Oracle-free perpetual futures with sub-500ms settlement and no surprise liquidations, powered by our integrated Spot.</p>
    </div>
  </a>
  <a href="/product-suite/ft-lend" className="product-card">
    <img src="../img/Flying Tulip_Lend.webp" alt="Flying Tulip Lend" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Lend</strong>
      <p>Dynamic lending markets that let you borrow any asset against any collateral with market-responsive loan-to-value ratios.</p>
    </div>
  </a>
  <a href="/product-suite/ft-insurance" className="product-card">
    <img src="../img/Flying Tulip_Insure.webp" alt="Flying Tulip Insure" loading="lazy" />
    <div className="product-card__content">
      <strong className="welcome-link-title">Insure</strong>
      <p>On-demand protection for digital assets with pay-as-you-go premiums that operates like a lending market for risk coverage.</p>
    </div>
  </a>
</div>
====
docs/product-suite/ft-futures.md

---
title: Futures
description: "Flying Tulip Futures: trading the future without oracle risk"
cover: /img/Flying Tulip_Futures_Page.webp
image: docs-og.png
coverY: 0
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_Futures_Page.webp"
  alt="Flying Tulip Futures"
/>

## Product Overview

Perpetual futures let you trade with leverage without an expiry date. In most venues, the contract's price follows an external oracle: a feed that updates every few seconds and decides who is liquidated and who is safe. FT Futures takes a different path. Instead of borrowing prices from somewhere else, it uses its own trading (Spot) as the source of truth. The contract settles to what actually trades here, not to a delayed print from elsewhere. That single design choice removes a familiar class of oracle lag and manipulation risk, and it changes how everything feels: quotes are live, settlements are sub‑500 ms, and liquidations key off prices you can really hit.

### How perpetuals work in crypto: and what breaks

A perpetual future (or "future") is a leveraged product that mirrors spot exposure with no expiry. Longs and shorts pay each other a funding rate that nudges the future back toward spot. On most platforms, "spot" is whatever the oracle says. That introduces two problems. First is latency: the oracle ticks every few seconds, so fast markets can move before the feed catches up. Users get liquidated on stale prices, and recovery is messy. Second is surface area: any integration error, governance bottleneck, or upstream hiccup in the oracle can ripple into your position. You pay for that risk in higher costs and fewer listed markets.

FT Futures turns the model inside‑out: it doesn't ask a third party for the price. It observes its own order flow. If ETH changes hands at $1,800 on the Spot, that is the settlement price. There is nothing to wait for.

![dark-image](/img/ftFutures_Dark.webp#dark-mode-only)
![light-image](/img/ftFutures_Light.webp#light-mode-only)

<p className="image-caption">Futures interconnection with Spot and Lend</p>

### The Spot is the oracle: prices and depth, not just prints

Pricing begins with the Spot's AMM adaptive curve and the CLOB resting orders. Together, they define where size can actually clear right now. The system looks beyond a single last trade. It maintains a TWAP (time‑weighted average price) for a clean time series and a TWAR‑family of depth‑aware measures that ask a more practical question: _how much of X can be sold for Y over this window without punching through reserves?_ Those depth‑aware windows drive the mechanics that matter: maximum leverage, liquidation sizing, and slippage guards. You are not leveraged against a number that only small trades can hit; you are leveraged against what the pool can truly absorb.

Because price discovery is internal, settlements are near‑instant. There is no 2–5s oracle tick to wait for, so liquidations are far less likely to trip on lag. And because the same engine sets prices and absorbs liquidations, unwinds can be sized to depth instead of blasted into a vacuum.

### Collateral and leverage: cross‑collateral when you want it

Futures can run in isolated or cross‑collateral modes. In isolated mode, you post collateral for a specific market and keep risk ring‑fenced. In cross‑collateral mode (via the permissioned Lend pool), a single deposit backs futures, CLOB orders, and borrowing at once. Your idle collateral is not idle: it continues to accrue its underlying money‑market yield while it backs trades. Maximum leverage is not a fixed table; it reflects depth and volatility from TWAR windows and contracts when conditions thin. When you open or adjust a position, limits are snapshotted so the rulebook doesn't change retroactively while you are holding.

### Liquidations that respect the market

When a position needs to be trimmed, the engine simulates the next clip on the AMM's curve and checks it against guardrails. If the clip would push beyond safe impact, the sale is time‑sliced into smaller steps, often crossing any resting CLOB liquidity first, then walking the AMM. Keepers are paid for low‑footprint execution, not for slamming markets. In quiet conditions, liquidations resolve in one or two clips; in fragile conditions, they step down a staircase. The aim is simple: protect solvency without turning stress into a spiral.

### Funding that makes economic sense

Funding exists to pull the future back toward the spot. FT Futures anchors funding to actual borrowing costs and market imbalances seen in the Lend markets and the Spot, not to an external guess. When longs are effectively borrowing dollars to hold coin, and that borrowing is expensive, funding reflects it. When shorts crowd the other side, funding flips. You can see the inputs, the update cycle, and why you paid (or got paid) what you did.

### Who takes the other side: opt‑in settlement LPs

Futures need a counterparty at settlement. FT handles this with opt‑in settlement pools. Liquidity providers deposit ftUSD and volunteer to settle trades in return for per‑settlement fees (around 0.05% per settlement, subject to policy). Exposure is balanced across providers, and providers can adjust or withdraw from the pool, subject to pool parameters. This design means no one is forced into risk they don't want, and new markets can launch when there is Spot liquidity and enough ftUSD settlement supply, not when an oracle committee has time to integrate a feed.

> **Note:** ftUSD is the settlement currency. Holding ftUSD on its own does not pay yield; staking to sftUSD does. Settlement LPs accrue Futures fees by opting into settlement pools; this is distinct from sftUSD yield.

### How it fits the rest of Flying Tulip

Futures sit on top of the same pricing spine as everything else. It references Spot windows for price and depth, uses Lend for cross‑collateral and portfolio health, and settles in ftUSD. Because Flying Tulip is token‑first, a share of futures revenue participates in the FT buyback pipeline, and the revenue‑linked unlocks described in the FT overview. The result is a loop: trading activity funds the token economy that, in turn, helps deepen the markets you trade.

### What it feels like to trade

You pick an asset, choose isolated or cross‑collateral, and set leverage. The route preview shows the expected impact and your funding context. Orders are matched on the CLOB when you want precision, or crossed against the Spot when you want immediate certainty; most flows use both. Your position updates against live prices (no oracle tick to wait for), and your collateral health moves with what actually trades. If the market turns, the liquidation engine trims exposure in measured steps. When conditions are calm, your fills feel like a centralized exchange. When they are not, the system is built to be conservative first and clever second.

### Fees and where they go

Futures charge trading fees and funding transfers between longs and shorts. Settlement LPs accrue a per‑settlement fee for providing ftUSD to the settlement pools. A protocol fee may be taken where policy allows; that portion flows into the FT buyback pipeline (and, when revenue‑funded, into the token‑unlock logic). Nothing here promises a fixed rate: fees and funding are variable and transparent, tied to realized activity and risk.

### Risks to understand

Leverage amplifies outcomes. Depth can thin under stress, spreads can widen, and liquidations can still occur. Internal pricing removes a class of oracle risk but not market risk. Smart contracts and integration risks are inherent to DeFi, and cross‑collateralization introduces portfolio‑level interactions that you should understand before you size up. The Risks, Security & Audits page explains our controls (guardrails, pausing, caps, monitoring) and what users can do to protect themselves.

### How‑to (overview)

**Open a future position.** Choose isolated or cross‑collateral, post collateral, set leverage, and place a market or limit order. Review your snapshot limits and funding context before confirming.\
**Manage collateral.** Add or remove collateral, reduce size, or close the position. Adjusting re‑snapshots limits under current conditions.\
**Provide settlement liquidity.** Deposit ftUSD into a futures settlement pool to accrue per‑settlement fees. Monitor pool parameters (utilization, fee schedule) and adjust or withdraw as policy allows.

### FAQs

**Without external oracles, what stops manipulation?**\
Attackers would need to move actual on‑platform liquidity. Pre‑trade guardrails, depth‑aware windows (TWAR family), dynamic fees, and time‑sliced execution raise the cost of forcing prices where depth doesn't support it. No system is risk‑free, but the incentives target practical, executable prices.

**How fast are settlements, really?**\
Settlements are sub‑second (targeting sub‑500 ms) because prices come from our own Spot. There is no oracle tick to wait for.

**What determines my maximum leverage?**\
Depth and volatility. The engine reads TWAR/TWAP windows and sets leverage to size your position against what the market can absorb. As conditions change, new openings/adjustments get new snapshots.

**Do settlement LPs take directional risk?**\
They provide ftUSD to settle trades and accrue per‑settlement fees. Exposure is diversified across providers and managed by a pool policy. LPs can adjust or withdraw, subject to parameters.

**Does ftUSD pay yield by itself?**\
No. ftUSD is the settlement currency and is non‑yielding by default. If you want yield, stake ftUSD to sftUSD. Settlement LP fees are a separate earnings path tied to futures activity.

**What happens in thin markets?**\
Leverage limits contract, fees can rise, and the liquidation engine relies more heavily on slicing and routing through any resting CLOB liquidity. In extreme conditions, circuit breakers and policy caps apply.

### Related pages

- **[FT Spot](/product-suite/ft-spot)**: the adaptive curve, TWAP/RWAP, and routing with the CLOB
- **[FT Lend](/product-suite/ft-lend)**: cross‑collateral, snapshot LTV, and soft liquidations
- **[ftUSD](/product-suite/ft-usd)**: settlement currency and the distinction between ftUSD and sftUSD
- **[FT](/product-suite/ft-token)**: token‑first revenue flows and buyback pipeline
- **[Risks, Security & Audits](/risks/)**: platform‑wide risks and controls
- **How‑to Guides:** Open/Close a Future, Manage Collateral, Provide Settlement Liquidity (coming soon)
====
docs/product-suite/ft-insurance.md

---
title: Insurance
description: "FT Insurance: on-demand protection for digital assets"
cover: /img/Flying Tulip_Insure_Page.webp
image: docs-og.png
coverY: 0
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_Insure_Page.webp"
  alt="Flying Tulip Insurance"
/>

## Product Overview

Insurance in crypto usually looks like a subscription: you prepay a lump sum for a fixed term, hope nothing happens, and then repeat. FT Insurance takes a different path. It treats protection like a lending market. Instead of buying a block of coverage time, you open a position in a pool and pay a running premium only while you want protection. Capital providers supply the pool and accrue those premiums; buyers "borrow" protection capacity and can scale it up or down in minutes. The effect is a protection system that breathes with the market: liquidity flows in when returns are attractive, coverage grows where demand appears, and users can align what they pay with the risk they actually face.

![dark-image](/img/ftInsure_Dark.webp#dark-mode-only)
![light-image](/img/ftInsure_Light.webp#light-mode-only)

<p className="image-caption">Insurance pool mechanics for buyers and liquidity providers.</p>

### Protection as a market, not a contract

The core of FT Insurance is a pooled backstop denominated in highly liquid assets (e.g., USDC). When you contribute capital, you receive a pool token (e.g., FT\_exploit\_insurance) that tracks your share of the pool's assets and premiums. When you want protection, you post collateral and open a coverage position against that pool, functionally "borrowing" the right to claim if a covered event is confirmed. As long as the position is open, you pay a continuous premium rate. Close the position, and the meter stops. There is no up‑front prepayment and no need to guess the perfect term length.

If an exploit occurs, an external verifier (e.g., UMA's optimistic oracle) confirms whether the event meets the on‑chain criteria for coverage. Once confirmed, addresses with active coverage can settle: the system accepts the relevant insurance token and pays out 1:1 in USDC from the pool up to the covered amount. If no exploit occurs, buyers simply withdraw their coverage when they no longer need it; capital providers keep the streamed premiums for the time coverage was active.

### How pricing and capacity emerge

Because protection behaves like borrowing from a pool, premiums resemble an interest rate. The rate responds to utilization (how much of the pool is spoken for), to risk conditions around the covered protocol, and to market‑wide signals (volatility, recent incidents, liquidity). High demand for coverage or elevated risk drives the rate up; new capital entering the pool drives it down. Coverage caps per protocol and global limits prevent concentration. You can see the live rate before you open a position, and adjust coverage size as conditions change, scaling up during a contentious upgrade and scaling down when risk subsides.

### What it feels like to use

As a buyer, you decide how much coverage you want and for how long you want to keep it open. You post a small amount of collateral, open the position, and watch a live premium accrue while the protection is active. If conditions worsen (rates rise), you can trim coverage; if you need more for a specific window, you can add to your position. If an incident occurs and is verified, you present your active coverage and claim at par from the pool. If nothing happens, you close the position and stop paying.

As a capital provider, you supply USDC to the pool, receive the pool token, and begin accruing a share of all active premiums. Your exposure is diversified across buyers and covered protocols, in accordance with the pool policy. You can increase or decrease your stake; withdrawals may be subject to short cooldowns when utilization is high or while claims are settling. Returns are variable: high utilization and elevated risk raise premiums; calm markets lower them.

### Claims and verification

Coverage is only as strong as its adjudication. FT Insurance relies on an external oracle process to confirm whether a claimed event meets predefined on-chain criteria (for example, a smart-contract exploit on a named protocol within a time window and loss threshold). An optimistic‑oracle model introduces a challenge period: if the community disagrees with the proposed resolution, they can dispute it. Once the outcome finalizes, settlement opens for addresses with active coverage during the incident window. This split of responsibilities (market‑based pricing on one side, external verification on the other) keeps the pool accountable to transparent rules.

### How it fits the rest of Flying Tulip

Insurance is plugged into the same spine as trading and lending. The Spot provides the pricing context that informs risk signals; Lend provides cross‑collateral so the same deposit can back lending, orders, futures, and insurance coverage simultaneously. Data about utilization, incident frequency, and claim resolutions feed back into the broader risk model. And because Flying Tulip is token‑first, a policy share of insurance premiums flows into the FT buyback pipeline; when revenue‑funded, those buybacks drive the unlock logic explained in the FT overview.

### The economics under the hood

Premiums are streamed from buyers to the pool in real time and split between providers and the protocol, per policy. Provider share accrues to pool assets; protocol share participates in FT buybacks. Because rates reflect utilization and risk, capital naturally migrates: if returns fall, providers can reduce exposure; if demand spikes, new capital is attracted by higher yields. The pool is not a black box; balances, utilization, premium rates, pending claims, and historical settlements are visible on‑chain.

### Risk, plainly stated

Insurance shifts risk; it does not delete it. Providers bear the risk that a verified exploit will trigger payouts from the pool; that is the service for which they accrue premiums. Buyers bear the risk that a suspected event is ultimately not verified by the oracle. Both sides face smart‑contract and integration risks typical of any DeFi system, and liquidity can tighten temporarily during heavy utilization or while claims are being processed. Coverage scopes and exclusions matter; each market specifies what counts as a covered event before you open a position. The Risks, Security & Audits page explains the guardrails: caps, cooldowns, pausing, change management, and what users can do to protect themselves.

### How‑to (overview)

**Open coverage.** Choose a covered protocol/market, enter the coverage amount, review the live premium rate and terms, post the required collateral, and open. Premiums accrue only while the position is active. You can increase, decrease, or close coverage at any time.

**Provide capital.** Deposit USDC to the insurance pool to receive the pool token (FT\_exploit\_insurance). Your share of premiums accrues automatically to the pool's assets. You may withdraw, subject to utilization and any configured cooldown.

**File a claim.** If an incident occurs, the UI shows the verification status. Once the oracle confirms the event, submit your claim: present your active coverage for the incident window and claim 1:1 from the pool up to your covered amount.

### FAQs

**What counts as an "exploit" or covered event?**\
Each market defines its scope (affected contracts, chains, thresholds, time window). The oracle confirms whether the incident meets that scope before settlement opens.

**Do I pay premiums even if there's no incident?**\
Yes, premiums are pay‑as‑you‑go while coverage is active. If no incident occurs, you can close coverage and stop paying immediately.

**Can providers lose principal?**\
Yes, if a verified event triggers payouts, the pool pays claims and its asset balance decreases. Premiums exist to compensate providers for bearing that risk.

**How are premiums set?**\
Rates respond to utilization, market risk signals, and per‑market policy. High demand or elevated risk → higher rate; fresh capital or calmer conditions → lower rate.

**Can I use the same collateral I use elsewhere?**\
In the permissioned environment, yes. Cross‑collateral lets a single deposit back lending, orders, futures, and insurance coverage simultaneously, subject to health checks.

**Where do protocol fees go?**\
A policy share of premiums is routed to the FT buyback pipeline. When revenue‑funded, those buybacks drive the unlock mechanics (40:40:20) described in the FT docs.

**Is coverage transferable?**\
Coverage positions are account‑bound to avoid moral‑hazard games. Close and reopen if you need to change ownership.

**What happens if the pool is highly utilized during a claim?**\
Withdrawals by providers may be rate‑limited during settlement. Once claims are paid and utilization normalizes, withdrawals resume under the usual rules.

### Related pages

- **[FT Spot](/product-suite/ft-spot)**: price and depth windows that inform risk
- **[FT Lend](/product-suite/ft-lend)**: cross‑collateral and portfolio health that power insurance positions
- **[ftUSD](/product-suite/ft-usd)**: stable settlement currency used across markets
- **[FT Token](/product-suite/ft-token)**: token‑first revenue flows and buyback pipeline
- **[Risks, Security & Audits](/risks/)**: platform‑wide risks and operational safeguards
- **How‑to Guides**: Open/Close Coverage, Provide Capital, File a Claim (coming soon)
====
docs/product-suite/ft-lend.md

---
title: Lend
description: "Flying Tulip Lend: two smart lending systems for every need"
cover: /img/Flying Tulip_Lend_Page.webp
image: docs-og.png
coverY: 0
layout:
  width: default
  cover:
    visible: true
    size: full
  title:
    visible: true
  description:
    visible: true
  tableOfContents:
    visible: true
  outline:
    visible: true
  pagination:
    visible: true
  metadata:
    visible: true
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_Lend_Page.webp"
  alt="Flying Tulip Lend"
/>

## Product Overview

Lending is one of the simplest ideas in crypto: you supply an asset, others borrow it, and interest bridges the two. Most protocols stop there. Flying Tulip's FT Lend takes the familiar model and places it inside an adaptive market that "understands" depth, volatility, and where prices can actually clear. That context matters for everything: how much you can safely borrow, how expensive it is to do so, and how positions are unwound when they need to be. The result is a lending layer that feels like the experience you know, yet behaves like it's plugged into a living market, because it is.

![dark-image](/img/ftLend_Dark.webp#dark-mode-only)
![light-image](/img/ftLend_Light.webp#light-mode-only)

<p className="image-caption">Lend mechanics for permissionless markets.</p>

Two forms of FT Lend coexist. A permissionless layer spins up a lending market for any trading pair on Spot. If there is an ETH/USDC pool, there is an ETH↔USDC lending pair automatically. Beside it sits a permissioned pool with pre‑configured parameters for assets that the protocol is willing to cross‑collateralize broadly. That pool is the collateral backbone for the rest of the system: the CLOB (central limit order book), Futures, settlement, and liquidation logic all speak to it. A single deposit can back a loan, serve as collateral for a limit order, and support a future position simultaneously, without moving the funds around.

### What "lending" means in practice

On the surface, FT Lend works the way you expect. Suppliers deposit assets and begin accruing interest; borrowers post collateral and take loans within loan‑to‑value limits. Under the hood, the limits and the rates are market‑aware. Instead of hard‑coded tables, the system asks: _How much of token X could we sell for token Y right now without blowing through depth?_ and _How variable is that answer over the last hour, the last day, the last week?_ That information comes from the Spot's price and reserve windows (time‑weighted TWAP and reserve‑weighted RWAP, among others). When the market is calm and deep, your borrowing power is more generous. As volatility rises or depth thins, your available LTV gracefully tightens.

"Snapshot LTV" makes those promises predictable. When you open (or adjust) a position, the system evaluates the market and snapshots your LTV limits at that moment. If policy shifts later, your existing position isn't retroactively punished; you'll see new limits the next time you make a change. Your collateral is still marked‑to‑market; if the asset you posted drops, your health moves with it, but the rulebook doesn't change under your feet.

Interest rates follow the same philosophy. Utilization still matters; busy pools raise rates to attract supply and ration demand, but the schedule can lean higher in more volatile regimes and relax when conditions are benign. Rates are posted up front, visible on the pool page, and update continuously.

### Permissionless markets: lending where there is liquidity

The permissionless side takes the Spot as its map. If the Spot exposes a pair, FT Lend exposes a lending market for that pair. You can borrow ETH against USDC, or USDC against ETH, without asking governance to whitelist anything. The system reads depth from the Spot and computes size‑aware borrowing power: a small loan that would barely nudge price is treated differently from a large one that would have to walk through reserves.

Because each market is anchored to a real pool, liquidations are soft by default. When a position needs to be trimmed, the engine simulates impact against the Spot's adaptive curve, then sells into depth in slices rather than dumping it in a single clip. It prefers the Spot path that minimizes slippage, and if resting orders exist on the CLOB at a better price, it crosses those first. For suppliers, that means fewer fire‑sale events. For borrowers, it means a gentler path back to safety.

### Permissioned pool: cross‑collateral and zero‑liquidation strategies

The permissioned pool covers a curated set of assets that the protocol is willing to cross‑collateralize against one another. Here, collateral is fungible across products: a single deposit can accrue money‑market yield, back a CLOB limit order you placed earlier in the day, and collateralize a future position you open this afternoon. While your order is waiting to fill, your deposit remains productive; there is no "dead" capital tied up on the sidelines.

A debt‑netting mechanism lives in this pool and makes certain delta‑neutral constructions behave very differently from typical loans. If your long and short legs are sized to offset, your borrow can be netted by the yield in the structure and, within configured bounds, eliminate conventional liquidation paths. That's how ftUSD can operate with near‑zero liquidation risk in practice: the borrow and yield legs are designed to cancel directional exposure, and the pool enforces the balance.

The permissioned pool launches with a 10 million TVL cap, and it may start as low as 1 million.

### Liquidations that respect the market

Liquidations are not a punishment; they are a risk tool. FT Lend treats them accordingly. Before any sale, the engine "asks" the Spot curve what the next clip would do to the price. If the impact would breach guardrails, the system takes a smaller step, waits a beat, and checks again. Large positions are time‑sliced by design. Keepers who execute with low impact are paid; slash‑and‑grab behavior gets nothing. Because the same market informs lending and pricing, the engine can also choose to net exposures internally when that reduces footprint, or route a portion through resting CLOB liquidity when it improves outcomes.

This is not just kinder during stress; it's also fairer in ordinary moments. When markets are healthy, you get fast, single‑clip resolution. When they are fragile, you get a staircase instead of a cliff.

### Pricing and LTV: how the Spot informs the numbers

Everything starts with prices you can actually trade at. The Spot publishes TWAP and RWAP windows across multiple horizons. TWAP gives you a clean time average; RWAP weights by reserves near the execution path and is therefore closer to _realizable_. LTVs are computed against those windows with buffers that reflect volatility and utilization. If depth is abundant and dispersion low, a borrower can responsibly draw more. If reserves thin or spreads widen, the window tightens. You see those numbers the moment you create or adjust a position; they are the basis of your snapshot.

Because the Spot curve itself adapts, leaning toward constant‑sum when calm and constant‑product when volatile, these windows reflect that reality. It is harder to push prices in a quiet regime; it is easier to push them when the pool is already stressed. The lending engine reads the same signals and sets limits accordingly.

### Fees, interest, and where they go

Borrowers pay interest; suppliers accrue it. FT Lend routes these cashflows through the protocol's token‑first model. Lenders receive their share as FT‑denominated distributions (the system converts the stream into FT, so the percentage you receive stays in line with the market, while also creating direct demand for the token). A protocol fee may be taken where policy allows; that portion flows into the FT buyback pipeline that also governs unlocks for Foundation, Team, and Incentives. No rates are promised, and all yields are variable. The point is that the revenue created by borrowing activity is visible and programmatic, paid to lenders and reflected in the token economics, not vanishing into operational burn.

### Using FT Lend day‑to‑day

If you want to supply, choose an asset or deposit, and watch your balance climb as interest accrues. If you want to borrow, you post collateral and draw the asset you need. On the permissionless side, you borrow against the Spot pair it exposes. On the permissioned side, you borrow against your whole approved portfolio and keep trading while your deposit continues to accrue yield. Your dashboard shows health, snapshot LTV, current rates, and the amount of room you have left.

If you do nothing after opening, the rules you opened under remain in force for that position, even if the policy changes tomorrow. If the market moves against your collateral, the engine trims exposure softly. If the market is calm, you barely notice; if it's turbulent, you see slices instead of shocks.

### How‑to overview

**Supplying.** Open Lend, pick the asset, review the current supplier Annual Percentage Yield (APY) and policy fee, and deposit. Your position appears immediately and begins accruing. You can withdraw at any time, subject to pool liquidity.

**Borrowing (permissionless).** Pick the Spot pair market (e.g., ETH/USDC), post one side as collateral, and borrow the other. The interface displays your snapshot LTV, liquidation buffers, and the rate you'll pay.

**Borrowing (permissioned / cross‑collateral).** Deposit any approved collateral, and borrow any other approved asset. Your single deposit backs loans, CLOB orders, and futures simultaneously. Health and limits reflect the whole portfolio.

**Repaying & adjusting.** Repay interest and principal to free up collateral, or add collateral to increase headroom. Adjusting your position will re‑snapshot LTV under current conditions.

### FAQs

**What is "snapshot LTV", and why does it matter?**\
It's the practice of locking your borrowing limits at the moment you open or adjust a position. Policy changes won't retroactively tighten your existing headroom; you'll see new limits only when you modify the position.

**How does FT Lend choose liquidation size?**\
By simulating the impact on the Spot's adaptive curve and using time‑sliced execution when needed. It also sweeps resting CLOB orders when they offer better prices, and pays keepers who minimize footprint.

**Can I use one deposit to trade and borrow at the same time?**\
Yes, in the permissioned pool. One deposit can back a loan, rest as collateral for CLOB orders, and support a future position, all while accruing the underlying money‑market yield.

**How are lenders paid? In what token?**\
Lenders receive the same market‑determined APY they would expect, delivered as FT via the token‑first pipeline. A policy fee may be taken to fund protocol operations and buybacks.

**Are there assets I can borrow in the permissionless markets that I can't borrow cross‑collateral?**\
Permissionless markets exist wherever the Spot has a pair. The permissioned pool supports a curated list of assets suitable for broad cross‑collateralization and portfolio‑level risk.

**Is any of this guaranteed?**\
No. Rates and limits are variable. Collateral is marked‑to‑market. Liquidations are possible. See the risk page for details on smart‑contract, market, and venue risks.

**Is there a TVL cap on the permissioned pool?**\
Yes. The initial cap is 10 million, and it may start as low as 1 million.

### Related pages

- **[FT Spot](/product-suite/ft-spot)**: how prices and depth are computed, and how they adapt by regime
- **[Futures](/product-suite/ft-futures)**: how funding and risk reference AMM/CLOB windows
- **[ftUSD](/product-suite/ft-usd)**: delta‑neutral stable that relies on Lend's debt‑netting
- **[FT Token](/product-suite/ft-token)**: token‑first revenue flows and buyback pipeline
- **[Risks, Security & Audits](/risks/)**: general DeFi risks and capital‑allocation specifics
- **How‑to Guides**: Supply, Borrow, Cross‑Collateral (coming soon)
====
docs/product-suite/ft-spot.md

---
title: Spot
description: "Flying Tulip Spot: smarter way to trade digital assets"
cover: /img/Flying Tulip_Spot_Page.webp
image: docs-og.png
coverY: 0
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_Spot_Page.webp"
  alt="Flying Tulip Spot"
/>

## Product Overview

Flying Tulip's Spot is the ecosystem's trading engine and price source. It is the venue where swaps clear, where liquidity is supplied, and where the system takes its cues for pricing, funding, and risk. Instead of fixing one curve and hoping markets behave, the Spot's AMM adapts in real time. In quiet conditions, it aims to achieve spreads that feel close to those of a professional market maker. When volatility arrives, it adds curvature to cushion impact and protect liquidity providers. Alongside the AMM, a CLOB (central limit order book) accepts resting limit orders. Trades can clear entirely on the AMM, entirely through the CLOB, or across both; whichever produces the best executable price for the size at hand.

![dark-image](/img/ftSpot_Dark.webp#dark-mode-only)
![light-image](/img/ftSpot_Light.webp#light-mode-only)

<p className="image-caption">Spot: adaptive AMM and CLOB.</p>

### A market that changes with the weather

Conventional AMMs commit to a single formula, typically the constant product model. That is robust but can be wasteful in calm markets, and it still leaves LPs exposed when prices trend. The FT Spot blends behaviors instead of choosing one. In stable regimes, the curve leans toward constant‑sum, so prices barely move for modest flow; the experience is tight spreads and low slippage. As dispersion increases, the Spot's AMM tilts toward constant‑product, so each marginal unit moves the price more. That extra curvature slows toxic flow and reduces divergence losses for LPs during stress. The transition is not binary. It is driven by smooth regime signals and bounded coefficients, so the curve slides rather than snaps from one extreme to the other.

### Knowing when to shift

The Spot watches prices and flow and smooths what it sees with exponential moving averages. Those EMAs dampen overreaction to a single print while allowing the system to respond to genuine regime change. Guardrails cap how far and how fast the curve can move within any window, keeping the experience predictable for both traders and LPs. The result is an engine that responds to conditions without becoming twitchy.

### Prices you can actually trade at

A time‑weighted average (TWAP) is useful, but it is blind to depth. The Spot's AMM also maintains a reserve‑weighted view (RWAP), which weights each price observation by the liquidity available along the likely execution path. RWAP answers a practical question, _what price can this order size actually clear?_, and is more informative for routing and for evaluating realized impact. Downstream systems can also reference depth‑aware measures (such as reserve‑weighted windows) when sizing liquidations, setting leverage limits, or computing funding for futures.

### What it feels like to trade

When you request a swap, the router looks at both books. If there are limit orders resting on the CLOB at a better price, those are swept first. Any remainder is filled against the Spot's AMM at the current adaptive curve. Before the transaction is finalized, the router simulates the trade on‑chain to assess its impact on your slippage tolerance and the pool's risk guardrails. If a single clip would be too heavy, the order can be split and time‑sliced so it walks through depth more gently. Fees are shown up front and vary with regime; lighter in calm conditions to encourage flow, heavier in turbulence to compensate LPs and slow informed bursts. The receipt shows how much moved through the CLOB, how much crossed the Spot's AMM, and what fees were paid.

### What it feels like to provide liquidity

If you want to accrue fees, you can allocate assets in a way that aligns with your attention and risk tolerance. A full‑range position is the simplest: you deposit both sides, and the AMM spreads them across the entire price domain. You will always be in range, you will collect a steady share of fees, and you will still experience impermanent loss if the pair trends. If you want more fee density, you can concentrate liquidity into a band you choose. While the market lives inside your band, you accrue a higher fee share per unit of capital; if the price exits the band, you stop accruing until you rebalance.

LP returns are generated by trade fees and any programmatic incentives displayed in the interface. Fees accrue continuously into the pool's accounting, and you can add or remove liquidity or adjust bands at any time, subject to pool policies. All of the usual AMM caveats apply: if the pair drifts, your assets rebalance; if the market runs, concentrated bands need managing. The goal of the adaptive curve is not to eliminate those realities but to make them kinder; tighter prices when it is safe, more protection when it is not.

### Fees that make sense

Fixed fees ignore context. The AMM treats fees as a policy instrument. In quiet regimes, the schedule approaches its lower bound, encouraging users to route flow here rather than elsewhere. As volatility and toxicity rise, the schedule climbs toward its upper bound so LPs are paid appropriately, and flow slows to a sustainable pace. Bounds and sensitivity are public.

### Safety before speed

Every swap proposal is simulated against the live curve before state changes are applied. If the simulation shows the trade would breach pool guardrails - too much impact, too shallow reserves, too close to configured limits - the router refuses the transaction. For large orders, the system can slice clips over blocks to reduce the footprint. The idea is to be fast in all the ordinary moments and conservative in the rare ones which harm users.

### How the Spot's AMM fits the rest of Flying Tulip

The Spot's AMM is more than a place to swap. Its prices and depth windows are the foundation for the CLOB, which provides limit‑order precision on top of continuous liquidity. The futures system takes its funding and risk cues from the Spot prices and depth rather than relying on external oracles. The lending markets lean on Spot depth to perform soft, size‑aware liquidations that minimize market impact and commit LTV ratios based on available size. The insurance primitive uses Spot‑anchored windows for transparent valuations and event checks. And because Flying Tulip is token‑first, a share of the revenue generated here flows into the FT buyback pipeline described in the FT overview.

### Using it day to day

If you are swapping, you will see a single route preview. Sometimes everything fills on the CLOB, sometimes everything crosses the Spot's AMM, and often it is a blend. You choose a slippage tolerance; the router enforces it. If you are providing liquidity, you decide whether you want set‑and‑forget coverage, a concentrated band you will tend occasionally. The interface shows the current regime, the fee tier, and the band economics so you can decide whether now is a good moment to lean in, widen out, or step aside.

### Understanding the trade‑offs

Adaptive design makes the experience smoother, not risk‑free. Impermanent loss still exists when pairs diverge. Concentrated bands pay more while they are in range and pay nothing when they are not. In stressed markets, spreads widen and fees increase; execution may be sliced to protect the pool. As with any on‑chain system, smart‑contract, integration, and MEV risks apply. The risk page of the documentation explains these in depth and describes the controls - role separation, caps, pausing and circuit breakers, and change management - that sit around the engine.

If you want the short version: the Spot's AMM is built to behave like a thoughtful market maker when the seas are calm, and like a cautious one when they are rough. It is the price reference for the rest of Flying Tulip and the place where liquidity is provided in a way that respects both sides of a trade.

### How to LP (overview)

1. Open **Provide Liquidity** on the pair you want.
2. Choose **Full‑range**, **Concentrated** (set band), or **Leveraged‑style** profile.
3. Review **fee schedule**, **current regime**, and **projected fee density**.
4. Confirm deposit; receive LP position representation (visible in the dashboard).
5. Monitor P&L (fees accrued minus IL). Adjust bands or exit anytime.

### How to Swap/Trade (overview)

1. Open **Swap/Trade**.
2. Select tokens and enter size; set **slippage** (and advanced options if needed).
3. Review the **route preview** (estimated price, dynamic fee).
4. Confirm; the router executes, slicing as needed.
5. Review the receipt (final price, fee, realized impact).

### Risks (summary)

- **Impermanent loss (IL).** More pronounced with trending divergence; mitigated (not eliminated) by adaptive curvature.
- **Out‑of‑range risk.** Concentrated liquidity accrues no fees when the price leaves the band until you rebalance.
- **Execution risk.** In stress, spreads widen and price impact grows; dynamic fees also rise.
- **Venue/contract risk.** As with all DeFi, smart‑contract, integration, and MEV risks exist.

> **Note:** Read [Risks, Security & Audits](docs/risks/index.md) for platform‑wide and capital‑allocation risk frameworks.

### FAQs

**Is this still an AMM if there's also a CLOB?**\
Yes. The AMM provides continuous liquidity; the CLOB provides limit‑order precision. The router can use both for the best execution.

**Do I have to micromanage ranges?**\
No. Use full‑range for low‑maintenance exposure. If you want tighter fee density, choose concentrated and periodically rebalance.

**What makes RWAP better than TWAP for large orders?**\
TWAP averages over time; RWAP weights by available reserves near the path, so it approximates the price you'll actually get for size.

**Can Spot prices be manipulated to affect Futures or Lend?**\
Pre‑trade guardrails, depth‑aware metrics (RWAP/TWAR), dynamic fees, and slicing are designed to resist short‑burst attacks. No system is risk‑free; see the [risk](docs/risks/index.md) page for details.

### Related pages

- **[FT Token](/product-suite/ft-token)**: token‑first flows and buyback pipeline
- **[ftUSD](/product-suite/ft-usd)**: how settlement currency and staking (sftUSD) work
- **[Futures](/product-suite/ft-futures)**: how pricing/funding leverage Spot + CLOB metrics
- **[Lend](/product-suite/ft-lend)**: soft liquidations and depth‑aware risk controls
- **[Risks, Security & Audits](/risks/)**: general DeFi and AMM‑specific risks
- **How‑To Guides**: Add/Remove Liquidity, Choose Ranges, Advanced Swap Routing (coming soon)
====
docs/product-suite/ft-token.md

---
title: Token
description: "Flying Tulip Token: a revolutionary approach to crypto investment"
cover: /img/Flying Tulip_FT_Page.webp
coverY: 0
image: docs-og.png
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_FT_Page.webp"
  alt="Flying Tulip Token"
/>

## Product Overview

The FT Token is designed to align users, contributors, and the protocol around a simple idea: convert real activity into lasting value. FT achieves this through conservative capital stewardship, clear Exit rights for primary participants, and a token‑first model that returns yield and fees to FT.

This page explains what FT is, how it's issued, how the Perpetual PUT works (for primary allocations), and how dollars flow to FT across the ecosystem. For details of the on‑chain raise, see the [Public Sale guide](docs/guides/sale-process.md). For quantitative models, see the [Technical Appendix](docs/capital-allocation/technical-appendix.md) for Capital Allocation. For platform‑wide risks, see [Risks, Security & Audits](docs/risks/index.md).

### What FT is and how it fits

FT is the **native token** of Flying Tulip. It exists to:

- **Connect activity to cashflows:** Products generate revenue and fees; those dollars are used to buy FT (and in many cases burn it), turning usage into scarcity for holders.
- **Preserve and compound capital:** Primary raise proceeds are not spent; they are deployed into conservative, liquid yield. That funds ecosystem development (infrastructure, operations) first; any surplus is routed to ongoing buyback-and-burn.
- **Offer clear, on‑chain rights** during the Capital Allocation: the Perpetual PUT for primary participants (explained below).

Across the product suite - ftUSD, Spot, Lend, Futures, Insurance, the protocol takes a token‑first approach: where appropriate, fees and yield are converted into FT, creating direct demand for the token as usage grows.

### Issuance & supply (high‑level)

FT has a maximum supply of 10,000,000,000 (10B), and that fixed supply is pre-minted at deployment. During [Capital Allocation](docs/capital-allocation/index.md), FT is allocated at a fixed rate of 10 FT per \$1 contributed (implied \$0.10). Unallocated FT remains in the Investment Contract (Perpetual PUT reserve) as non-circulating supply. `totalSupply` remains at 10B, while circulating vs non-circulating balances shift over time. There is no inflation through additional minting.

### The Perpetual PUT (for primary allocations)

When a primary contribution settles during the Capital Allocation, the resulting FT is issued as a Perpetual PUT, represented on-chain by your FT NFT (ftPUT). While your FT remains in the PUT, you have three choices at all times:

**1) Hold: keep the Perpetual PUT open**\
Do nothing; you keep your Exit right attached to your position while participating in any FT upside.

**2) Exit: Exit at par**\
Exit any portion of your FT at par for the same asset and amount you originally contributed (e.g., 10,000 FT ↔ 1,000 USDC).

**3) Withdraw: unlock FT (PUT invalidated; backing capital funds buyback-and-burn)**\
If you prefer to hold or use FT without the PUT, withdraw your FT from the PUT. This invalidates the PUT on that portion, and the backing capital that had been reserved for your Exit at par is released and used by the protocol to buy FT on the open market and burn it. What you do with your now‑unencumbered FT (hold, trade, transfer) is up to you.

> **Note:** Only primary FT allocated via the Private and Public Sale carries the Perpetual PUT.
<!-- markdownlint-disable-next-line MD028 no-blanks-blockquote -->
> **Note:** You can also sell the Perpetual PUT itself via the [ftPUT Marketplace](/product-suite/ftput-marketplace).

### Where FT demand comes from

Flying Tulip routes multiple cashflow streams toward FT:

**1) Backing capital yield (carry)**\
Primary contributions (while the Perpetual PUT is open) are deployed to conservative, liquid strategies. For example, major stables on Aave, staked assets like stETH/jupSOL/AVAX, or sUSDe for USDe. The first call on this carry is the ecosystem budget (salaries, marketing, infrastructure, operations). Any surplus carry is used for continuous buyback-and-burn of FT.

**2) Protocol revenue & fees**\
As products like ftUSD, Spot, Lend, Futures, and Insurance are used, revenue and fees are used to buy FT (and, in many cases, burn it). This is the core of the token‑first integration: user activity translates into programmatic FT demand.

**3) PUT invalidation releases (Withdrawals)**\
When a primary holder withdraws FT from the PUT Option, the PUT is invalidated, and the previously reserved backing capital becomes buyback ammo to purchase and burn FT on the market.

**4) Exits recycle supply in-contract**\
When a holder Exits at par, the original collateral goes back to the holder.

Together, these flows tie usage and prudently managed capital to per‑token scarcity.

### Unlock mechanics (alignment)

FT's unlocks are governed by revenue‑funded buybacks. When protocol revenue funds buybacks, Foundation / Team / Incentives unlock 1:1 in a 40:40:20 split.

### Key facts

- **Ticker:** FT
- **Supply cap:** 10,000,000,000 (10B)
- **Primary issuance:** via Capital Allocation at 10 FT per \$1 contributed (implied \$0.10)
- **Unlock policy:** revenue‑funded buybacks unlock 40:40:20 (Foundation / Team / Incentives)
- **Cross‑chain:** FT supports omnichain transfers (OFT)

### What this is not

FT is not a promise of fixed yield or principal outside the conditions of the Perpetual PUT for primary allocations. Market prices vary; yields fluctuate; burns depend on realized activity and budgets. Nothing in this page is investment advice.

### Related pages

- **[Capital Allocation](/capital-allocation/)**: mechanics, accepted assets, Perpetual PUT lifecycle
- **[Technical Appendix](/capital-allocation/technical-appendix)**: backtests, formulas (yield/revenue → buybacks), scenario tables
- **[ftPUT Marketplace](/product-suite/ftput-marketplace)**: secondary market for Perpetual PUT Options
- **[Risks, Security & Audits](/risks/)**: general DeFi risks and Capital Allocation considerations
- **[Smart Contracts → FT](/smart-contracts/ft-token)**: token interfaces, roles, and implementation details
====
docs/product-suite/ft-usd.md

---
title: ftUSD
description: "Flying Tulip USD: a smarter stablecoin that makes money while you sleep"
cover: /img/Flying Tulip_FTUSD_Page.webp
coverY: 0
image: docs-og.png
---

import ProductPageHeader from '@site/src/components/ProductPageHeader';

<ProductPageHeader
  image="/img/Flying Tulip_FTUSD_Page.webp"
  alt="Flying Tulip ftUSD"
/>

## Product Overview

![dark-image](/img/ftUSD_Dark.webp#dark-mode-only)
![light-image](/img/ftUSD_Light.webp#light-mode-only)

<p className="image-caption">ftUSD and sftUSD lifecycle.</p>

ftUSD is Flying Tulip's dollar‑pegged token designed for stability first, with optional yield when you choose to stake it as sftUSD. Unstaked ftUSD serves as a composable, on‑chain dollar across the ecosystem (trading, settlement, collateral). If you want yield, you opt in by staking your ftUSD for sftUSD. Proceeds from unstaked ftUSD accrue to the protocol, helping fund operations and deepen liquidity; stakers receive the distributed yield. ftUSD and sftUSD are fully on-chain, auditable, and transparent, with no oracles or centralized systems.

> **Note:** ftUSD is stable and non‑yielding by default (great for payments, settlement, collateral); sftUSD is staked ftUSD that accrues yield (opt‑in).

### Why choose ftUSD

- **Stable unit of account.** A $1‑target stable designed to act as the settlement currency across Flying Tulip (e.g., futures, order book settlement, liquidity).
- **Optional yield when you want it.** Stake sftUSD to accrue distributed strategy carry; keep ftUSD unstaked if you prefer pure stability or need immediate liquidity.
- **Engineered for resilience.** A delta‑neutral architecture aims to reduce liquidation risk by balancing long/short legs and sizing positions conservatively.
- **On‑chain transparency.** Collateral, parameters, and flows are visible and programmatic.
- **Composability.** Use ftUSD throughout the FT product suite: trade, settle, post as collateral, or provide liquidity where available.

> **Note:** Only staked ftUSD (sftUSD) accrues yield distributions.

### How ftUSD works

ftUSD maintains its dollar target using balanced, delta‑neutral strategies that combine conservative money markets and staking with offsetting short exposure. The aim is to generate a strategy that carries (net of costs) while keeping net market exposure near zero.

**Illustrative pipeline (one possible strategy):**

1. **Supply base collateral** to a money market (e.g., USDC → Aave) to accrue low‑risk interest.
2. **Borrow a hedging asset** (e.g., Sonic "S") against that collateral, creating a short leg (you owe S).
3. **Stake the borrowed asset** (e.g., S → stS via a staking venue) to accrue staking earnings = a long leg in stS.
4. **Loop collateral prudently** (e.g., deposit stS back to the money market) to increase safety buffers and carry.

The long (staked) side and the short (borrowed) side are sized to offset directional risk and reduce liquidation risk under typical conditions. Risk controls (position caps, rebalancing bands, and venue limits) constrain exposure.

> **Note:** Exact venues, parameters, and chain support can change over time. The principle remains: delta‑neutral construction + conservative sizing to target $1 while producing strategy carry.

### Staged roll-out

- **Stage 0:** Start with USDC/USDT to Aave wrapper.
- **Stage 1:** Expand to FT Lend as it hardens.
- **Stage 2:** Add extra stablecoin collateral.
- **Stage 3:** Deploy delta-neutral on-chain yield.
- **Stage 4:** Deploy short funding delta-neutral strategy (after perpetuals engine is live).
- **Stage 5:** Deploy covered call options selling delta-neutral strategy (after options engine is live).

### Buying ftUSD

1. Open the **Buy ftUSD** screen.
2. Choose your **input asset** (e.g., USDC).
3. Review the **quote** and **confirm**.
4. Receive **ftUSD** in your wallet.

> **Note:** Buying ftUSD does not start yield. To accrue yield, stake to sftUSD.

### Selling ftUSD

- Convert **ftUSD → input asset** at the prevailing rate.
- Timing and any small exit/cooldown parameters are shown in‑app (subject to change with risk settings and network conditions).

### Staking ftUSD → sftUSD

Staking converts ftUSD into **sftUSD**, the **yield‑accruing** receipt token for the staking pool.

#### Staking quick flow

1. Open **Stake ftUSD**.
2. Enter the **amount of ftUSD** to stake.
3. **Confirm** to receive **sftUSD** (your staked position).

#### How yield is delivered

- sftUSD represents your staked position in the rewards vault.
- Net strategy yield and protocol fees are collected by the treasury and distributed to stakers.
- Stakers claim rewards as FT from the rewards vault.
- Rates are variable and not guaranteed; they depend on realized strategy carry net of costs and any active policy buffers.

> **Note:** sftUSD rewards do not auto-compound. Rewards should be claimed as FT from the rewards vault.

#### Unstaking

- Convert **sftUSD → ftUSD** at the prevailing rate.
- Timing and any small exit/cooldown parameters are shown in‑app (subject to change with risk settings and network conditions).

> **Note:** Unstaked ftUSD receives no yield; proceeds accrue to the protocol treasury. Staked ftUSD receives distributed yield from ftUSD strategies.

### Yield sources

ftUSD yield is generated from a mix of strategy yield on collateral and protocol revenue. The only on-chain strategy currently implemented is stablecoin lending via Aave[^1]; other optional modules are planned.

#### Strategy yield

1. Stablecoin lending (implemented): supply stablecoin collateral to a lending market (e.g., USDC/USDT into Aave) to earn interest.
2. Lending-based delta-neutral carry (roadmap): use stablecoin collateral in a lending market to borrow native network asset, wrap it into a staking asset, and earn net carry when `(staking yield + staking rewards) - (native borrow cost) > 0`.
3. Crypto-collateral carry (roadmap): deposit a yield-bearing crypto asset (e.g., staked ETH), borrow equivalent native (ETH), sell to USD, and deploy the USD for yield; target `(USD yield + native yield + staking yield) - (native borrow cost) > 0`.
4. CDP-style minting (roadmap): allow multi-collateral minting, with a variable interest rate driven by supply/demand (utilization) on the lending layer.
5. Peg keeper module (roadmap): sell when ftUSD trades above net asset value (NAV) and buy when below, capturing arbitrage profits.
6. CFD/perp carry (roadmap): use staking assets as collateral and hold a 1x native short to earn positive funding/carry when available.

#### Protocol fees

- **Money‑market interest** (e.g., Aave supply APRs for stablecoins or LST collateral).
- **Staking earnings** (e.g., stS) on the long leg.

#### Distribution to stakers

All net strategy yield and protocol fee revenue is collected by the protocol treasury; then at treasury discretion distributed via buyback-and-distribute to ftUSD stakers.

#### Comparative benchmarks (snapshot)

Reference rates[^2] that drive the strategies include stablecoin supply APY, native borrow APR, staking APY, and funding/basis.

| Benchmark               | Chain    | APY   |
| ----------------------- | -------- | ----- |
| Aave v3 USDC supply     | Ethereum | 3.50% |
| Aave v3 USDT supply     | Ethereum | 2.56% |
| Compound v3 USDC supply | Ethereum | 3.52% |
| Lido stETH staking      | Ethereum | 2.55% |

### Benefits at a glance

- **Optionality:** Hold ftUSD for pure stability, or stake to sftUSD to accrue protocol distributions.
- **Lower operational burden:** Yield routing and rebalancing are handled on‑chain; staking is one click.
- **Ecosystem native:** ftUSD is the settlement currency across futures and other markets; widely usable as collateral/liquidity.
- **Risk‑aware design:** Delta‑neutral construction with sizing bands and venue caps to reduce common liquidation paths.

### Risks

- **Peg and basis risk:** Severe market moves can widen basis or stress hedges; the $1 target can deviate.
- **Venue risk:** Money markets, staking, and external protocols carry smart‑contract and validator risks.
- **Liquidity/exit timing:** Staked assets (LSTs) may require queues; large rebalances can take time.
- **Parameter risk:** Strategy weights, caps, and rebalancing rules can change as risk conditions change.

> **Note:** Read [Risks, Security & Audits](docs/risks/index.md) for a full discussion of general DeFi risks and capital‑allocation specifics.

### FAQs

**Does ftUSD pay interest automatically?**\
No. ftUSD is non‑yielding by default. To accrue yield, stake to sftUSD.

**What's the difference between ftUSD and sftUSD?**\
ftUSD is the base stable (target $1). sftUSD is the staked receipt that accrues protocol distributions tied to ftUSD strategies.

**How is the ftUSD peg maintained?**\
By constructing delta‑neutral positions (balanced long/short) with conservative sizing and rebalancing controls. This reduces exposure to directional market moves.

**Can I use ftUSD across the protocol?**\
Yes. ftUSD is designed as the settlement currency and a common collateral across the product suite; availability varies by feature and chain.

**Where can I see rates and history?**\
The Stake UI shows current pool stats (e.g., exchange rate, historical performance). Rates are variable and not guaranteed.

**Is ftUSD just a USDC/USDT to Aave wrapper?**\
At launch, ftUSD is a USDC/USDT to Aave wrapper (Stage 0). It expands through the staged roll-out above.

**Is the ftUSD/USDC (ftUSD/USDT) pool just a Uniswap v3-style CLMM?**\
Yes. The ftUSD/USDC (ftUSD/USDT) AMM uses a standard Uniswap v3-style CLMM as a security consideration.

### Related pages

- **[FT Token](/product-suite/ft-token)**: how value flows into FT via buyback-and-burn
- **[Capital Allocation](/capital-allocation/)**: mechanics, Perpetual PUT lifecycle
- **[Risks, Security & Audits](/risks/)**: risk framework and controls
====
docs/product-suite/ftput-marketplace.md

---
title: Perpetual PUT Marketplace
description: "Trade ftPUT positions with clear pricing, built-in validation, and safety controls"
image: docs-og.png
---

## Overview

The [Perpetual PUT Marketplace](https://marketplace.flyingtulip.com/marketplace) is a secure, decentralized venue for trading Flying Tulip Perpetual PUTs (ftPUT). It allows holders to sell Perpetual PUTs with transparent pricing and built-in checks that protect both sides of the trade.

### What it supports

- Listing, buying, editing, and removing ftPUT listings.
- Direct purchases at a pre-defined price.
- Signed buy offers that only settle if a seller accepts them.
- Built-in validation to prevent trades on outdated positions.

### How trades stay accurate

ftPUT positions can change over time as collateral or FT is withdrawn. Before any purchase is finalized, the marketplace verifies that the underlying position still matches the buyer's expectation, including the collateral type and remaining balances. If the position has changed, the trade will fail.

### Payments and fees

- Listings can be priced in ETH or in tokens approved by the protocol.
- Bids are paid in approved tokens, not ETH.
- Maker and taker fees are applied separately to the seller and buyer.
- Fees are capped and shown before confirmation.
- Fee rates and fee recipients are managed by the protocol.

> **Note:** Maker and taker fees are set to 0.1\% and 0.3\%, respectively.

### Listings

- The user should own the ftPUT and approve the marketplace for transfer.
- Each ftPUT can have only one active sell listing.
- Price must be greater than zero and set in approved tokens.
- Every listing has an expiration time.
- WETH can not be used for listings.

### Bids (Offers)

Bids are created with a wallet signature and only settle if a seller accepts them. Bids include an expiration time and can specify minimum remaining collateral and FT to ensure the position still meets the buyer's requirements. Bids are token-only (no ETH) and use tokens approved by the protocol.

### Safety controls

- Early position validation runs before the trade proceeds to prevent last-minute changes.
- Each trade is atomic: payment and a Perpetual PUT transfer together.
- Failed ETH payments are held and can be withdrawn later – transfers can not block the marketplace.
- The marketplace can be paused in case of an emergency.

### Owner and upgradability

The protocol manages accepted payment tokens, fee settings, and emergency pause authority. The marketplace is upgradeable to support future improvements. The current owner is set to the Flying Tulip treasury.

### Transparency

Listings, edits, sales, fee updates, and payment token changes are recorded on-chain for auditability.

### Related pages

- **[FT Token](/product-suite/ft-token)**: what ftPUT represents and how the Perpetual PUT works.
- **[Capital Allocation](/capital-allocation/)**: primary issuance and Exit flows
====
docs/risks/index.md

---
title: Risks, Security, Audits
sidebar_position: 5
image: docs-og.png
description: Stay up-to-date with Flying Tulip security
---

This page explains how we think about security. It is written for all readers (users, investors, institutions, and developers). Before reading this section, it is important to understand:

- Smart contracts are immutable once deployed; transactions are irreversible.
- DeFi involves market, protocol, and operational risks. Losses are possible.
- Nothing here is investment advice. Yields are variable and not guaranteed.

## Our Security Principles

1. **Minimize avoidable risk.** Prefer simple, battle‑tested patterns and conservative assumptions over yield‑chasing or complexity.
2. **Least privilege & separation of duties.** Use role‑based access, multisig guardianship, and timelocks where appropriate.
3. **Defense in depth.** Multiple layers: audits, monitoring, pausing/guardians, circuit breakers, parameter caps, and incident runbooks.
4. **Transparency.** Publish parameters, addresses, audit reports, and incident post‑mortems.
5. **No surprise dependencies.** Limit external protocol reliance; avoid leverage and bridging in the backing capital allocation for the PCA by default.

## General DeFi Risks

### 1) Smart Contract Risk

Bugs or logic errors can lead to loss of funds, frozen assets, or unintended behavior. Even audited code can contain undiscovered issues.

#### What we do: smart contract risk

- Multiple internal reviews and external audits before enabling capital‑bearing features.
- Gradual launch with caps/whitelists where prudent.
- Continuous monitoring and formal incident runbooks.

### 2) Market, Liquidity & Volatility Risk

On‑chain markets can move quickly; liquidity can disappear in stress. This affects pricing, collateral health, liquidations, and exit timing.

#### What we do: market, liquidity & volatility risk

- Conservative risk parameters and dynamic mechanisms in the broader product suite (e.g., snapshot LTVs, soft liquidations, time‑slicing).
- Emphasis on unwind‑friendly positions for treasury and backing capital.

### 3) Price Discovery, MEV & Economic Attack Risk

Front‑running, sandwich attacks, and flash‑loan‑driven manipulations can harm users and LPs if not mitigated. External oracle feeds can lag or be manipulated.

#### What we do: price discovery & MEV risk

- Depth‑aware pricing metrics in trading products; guardrails and regime detection.
- Reduce reliance on external oracles where design allows; if used, apply cross‑checks and conservative thresholds.

### 4) Third‑Party & Integration Risk

When capital is deployed to external venues (lending, staking, LSTs), those venues have their own contracts, validators, and operational risks.

#### What we do: third-party & integration risk

- Use established, liquid venues for conservative yield.
- Avoid leverage and bridging in the backing capital allocation.
- Diversify and size exposures with caps and stress assumptions.

### 5) User Operational Risk

Key loss, phishing, malicious approvals, wrong addresses/URLs, and wallet compromises are common causes of loss.

#### What you can do

- Use hardware wallets; verify URLs and contract addresses.
- Review token approvals; start small; simulate transactions when possible.

## Security Controls & Operational Safeguards

- **Roles & Multisig.** Sensitive functions gated by multisig; roles separated (Configurator, Treasury, Strategy Manager, etc.).
- **Parameter Caps.** Per‑asset/venue caps and whitelists; snapshot LTVs where relevant.
- **No Leverage / No Bridging (backing capital).** Backing capital allocation avoids leverage and bridging by default for unwind simplicity.
- **Transparency.** Publish contract addresses, ABIs, parameters, and post‑mortems where applicable.

## Incident Response (Overview)

1. **Detect & Verify.** Monitoring alerts; reproduce on a fork; classify severity.
2. **Contain.** Pause/circuit breakers; parameter throttles; multisig actions.
3. **Remediate.** Hotfixes via audited patterns; re‑audit if code changes.
4. **Communicate.** Timely, factual updates; impact and user guidance.
5. **Post‑Mortem.** Public root‑cause analysis and long‑term fixes.

## What Users Can Do

- **Verify** URLs and contract addresses; never trust DMs.
- **Use hardware wallets** and limit approvals to trusted contracts.
- **Start with smaller allocations** and scale only after you are comfortable with the flow.
- **Monitor** your allowances and revoke unused approvals.
- **Understand** the differences between **Hold**, **Exit**, and **Withdraw** in the Perpetual PUT.
====
docs/risks/audits-and-responsible-disclosure.md

---
title: Audits & Responsible Disclosure
hidden: true
image: docs-og.png
---

> **Status**
>
> - Audit firm(s): **TBA**.
> - Reports: will be **published** in this section (with versioning and checksums).
> - Scope (initial): **PutManager**, **FT Token**, **ftYieldWrapper** and associated libraries. Additional audits precede enabling Spot/Lend/Futures with real funds.

## Approach

- **Multiple reviews** (internal + external) before enabling capital‑bearing features.
- **Re‑audit on material changes** or new major modules.
- **Gating & caps** post‑deployment until audit findings are addressed and monitoring is live.
- **Public artifacts:** audit reports, diffs vs. deployed bytecode, and "what changed since audit" notes.

## Bug Bounty (planned)

- Public bounty with clear scope, severity tiers, and payouts.
- Acknowledgment policy and response SLAs published with the bounty.
====
docs/risks/circuit-breaker.md

# Circuit Breaker

At Flying Tulip, the security of user funds is the top priority. As part of this commitment to robust protection, the **Circuit Breaker** system reinforces the PUT Options offering.

The Circuit Breaker is a proactive measure to prevent a threat actor from draining user funds. A rate-limiting mechanism gives the Flying Tulip team time to respond during an incident, following industry best practices.

> **Note:** Most users should be unaffected by the Circuit Breaker mechanism.

This page covers **Circuit Breaker v1 (CBv1)** used in **Perpetual PUT (ftPUT)**. For **Circuit Breaker v2 (CBv2)** used in **ftUSD**, see the [Circuit Breaker v2 guide](/guides/circuit-breaker-v2).

## What is a Circuit Breaker?

Think of the Circuit Breaker like the fuse box at home. If too many appliances are turned on at once, a fuse "trips" to prevent a fire. Similarly, the Circuit Breaker monitors the flow of funds leaving the protocol.

If it detects a large token withdrawal over a short period of time (a pattern often associated with security attacks), it automatically limits the rate of subsequent withdrawals.

## Why is it essential for you?

In the world of decentralized finance (DeFi), speed is often critical. However, instant withdrawals can be exploited by attackers to drain an entire system in seconds.

The Circuit Breaker acts as a **speed limit** for outflows. By limiting how fast funds can leave the system, Flying Tulip ensures that:

1. **Attacks are stopped early:** Even in a worst-case scenario, an attacker could only take a small fraction of the funds before the door closes.
2. **The team can react:** It gives the security team and the community time to investigate and respond to any anomalies.
3. **User principal is safer:** The vast majority of the capital remains secure in the vault, protected by this rate limit.

> "It's for your security: a guarded launch that slows attackers, not users." - Storm0x, Security Researcher

## CBv1 vs CBv2

- **CBv1 (used in Perpetual PUT):** If outflow capacity is exceeded, withdrawals can revert. Users must come back and retry the withdrawal transaction when capacity is available again.
- **CBv2 (used in ftUSD):** If outflow capacity is exceeded, the withdrawal is queued instead of rejected. The withdrawal does not need to be re-submitted by the user, it becomes claimable after the delay (currently ~6 hours).
- **Claim step in CBv2:** After the delay expires, anyone can execute the queued payout to send tokens to the user's wallet. If no relayer/automation executes it, the user returns and claims manually.
- **Key behavior difference:** In CBv1, outflows can be fully blocked at the time of request. In CBv2, outflows proceed via delayed settlement so funds are not permanently locked by a revert path.

For integration and operational details, see the [Circuit Breaker v2 guide](/guides/circuit-breaker-v2).

## How does it affect user transactions?

Most users will not notice the Circuit Breaker is in place.

- **Deposits:** Always fully operational.
- **Normal Withdrawals:** The system is configured to handle standard withdrawal volumes easily.
- **High Traffic:** If there is a sudden "rush" for the exit (unlikely in normal operations), withdrawals may take longer (e.g., a few hours) while outflow capacity replenishes.

The Circuit Breaker only limits outflows. Exits flow through the wrapper and withdrawals are subject to the same outflow checks. Deposits are tracked for safety monitoring but are never rate-limited.

### The "Fail-Open" guarantee

The system is designed with a "Fail-Open" philosophy. This means that if the Circuit Breaker itself were to malfunction or break, it would default to **allowing transactions**. Users never have to worry about their tokens being locked permanently by an issue in the safety system.

## Transparency

Being open about the system's status is essential to Flying Tulip. A dedicated [Status Page](https://flyingtulip.com/allocation/dashboard#circuit_breaker) will allow users to see the current health of the system in real-time, including:

- Current withdrawal capacity.
- Any active rate limits.
- Estimated recovery times if usage is high.
====
docs/risks/multisigs.md

---
title: Multisigs
image: docs-og.png
description: Privileged roles in Flying Tulip
---

## **How it works**

The Flying Tulip Perpetual PUT system has privileged roles, some of which are controlled by multisigs. These multisigs are available on Avalanche, Base, Binance Chain, Ethereum, and Sonic. Addresses, thresholds, respective roles, and contracts with those roles are given in the table below.

| Address                                      | Threshold | Role             | Contract                 |
| -------------------------------------------- | --------- | ---------------- | ------------------------ |
| `0x1118e1c057211306a40A4d7006C040dbfE1370Cb` |  3/5      | Msig, treasury   | PutManager, Marketplace  |
| `0x22246a9183ce2ce6e2c2a9973f94aea91435017c` |  3/4      | Configurator     | PutManager               |
| `0x333A1ad484b540EcAc1edFa73a066aB57275293C` |  2/5      | Yield claimer    | ftYieldWrapper           |
| `0x5557729b169082f07d3131D560E2f2cb5e6c48f6` |  3/5      | Strategy manager | ftYieldWrapper           |

<!-- For detailed roles descriptions, refer to the corresponding contracts in [Smart Contracts](/risks/smart-contracts/) section. -->

All multisigs are implemented as Safes, meaning multisig assets, transactions, and signers can be viewed using [Safe's Web UI](https://app.safe.global/home).

### Members

Multisigs' membership can be validated from [Safe's Web UI](https://app.safe.global/home). All members (or signers) are part of Flying Tulip's team and use the following addresses for signing:

1. `0x3c42749709BF354B3aE0Db29Fd2dd88089b21B4E`
2. `0x09e2b49280f1879172b2c3345d08896921707881`
3. `0xd0ca88388d1732594d611535314e9b6745396f5a`
4. `0xf9E5aF16243041cE3141284D225CAfC0fC749a10`
5. `0xB7B543337539219A5a1326aCB71dBa8Bba408bc8`
====
docs/roadmap/index.md

---
title: Roadmap
description: Development cycle for guarded and permissionless launches
image: docs-og.png
sidebar_position: 4
---

## 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](/img/FT_Roadmap_Dark.webp#dark-mode-only)
![light-image](/img/FT_Roadmap_Light.webp#light-mode-only)

<p className="image-caption">Roadmap: release dependencies and milestones.</p>

Right‑side items have a hard dependency on the left‑side items, e.g., CLOB depends on ftUSD.

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**](/product-suite/ft-token) is allocated from a fixed pre-minted supply as capital is committed. Unallocated FT remains in the Investment Contract (Perpetual PUT reserve) as non-circulating supply. [Capital Allocation](/capital-allocation) comes together with on-chain **Perpetual PUT**. 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](/product-suite/ft-lend)**: Cross‑collateral pool that backs CLOB orders and Futures while deposits continue to accrue.
- **[ftUSD](/product-suite/ft-usd)**: Dollar‑target settlement rail that enables Futures, trading, and collateral.
- **Leveraged Spot**: Comes with dependency on Lend.
- **[Spot](/product-suite/ft-spot)**: Price source and execution venue that feeds time and reserve‑weighted windows to downstream systems.
- **Perpetual [Futures](/product-suite/ft-futures)**: Oracleless perpetual futures engine that settles to internal trading.
- **Futures and Options**: Sequenced after perpetual futures 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 AMM**: 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](/product-suite/ft-spot) page.
- **[Dynamic Lend](/product-suite/ft-lend/#permissionless-markets-lending-where-there-is-liquidity)**: Every AMM 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](/product-suite/ft-usd).

### 4. Oracles & Applications Layer

Proven pricing and settlement stack powers ecosystem apps and integrations.

- **[Witnessnet](/glossary#w)**: Brings oracleless proofs for on‑chain verification of HTTPS data without third‑party oracles.
- **[Binary prediction markets](/glossary#b)**: Resolve to facts proven via Witnessnet from accepted domains such as CoinDesk and CoinTelegraph. Anyone can submit proof to resolve a Yes or No question.
- **[Launchpad](/glossary#l)**: Token creation flow with threshold‑based launches and auto‑deployed AMM plus a money market. The initial launch window has anti‑MEV protections. Leverage and futures unlock after an [RWAP](/glossary#r) warm‑up.
- **[Insurance](/product-suite/ft-insurance)**: Provides pay‑as‑you‑go protection that behaves like a lending market, integrates with Lend for cross‑collateral, and uses AMM and CLOB context for risk.

With the whole product vertical set, protocol revenue flows into FT buyback-and-burn, 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:

- [Witnessnet](/glossary#w) accepts `(url, response, proof)` and validates [AEAD](/glossary#a)‑authenticated TLS records, key derivation to traffic keys, finished verification, and certificate and hostname binding through [CertificateVerify](/glossary#c). Any HTTPS endpoint becomes an implicit oracle.
- [Launchpad](/glossary#l) is a simple token‑launch workflow with liquidity thresholding and staged unlocks for leverage and futures after an [RWAP](/glossary#r) warm‑up.
- [Binary Prediction Markets](/glossary#b) are "Yes" or "No" markets resolved permissionlessly via Witnessnet proofs from approved domains. Accepted sources are configured per market.
- Volatility‑Adaptive AMM 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 [TWAP](/glossary#t), [RWAP](/glossary#r), [TWAR](/glossary#t), and [RVOL](/glossary#r) windows and supports concentrated and leveraged liquidity. See the [AMM](/product-suite/ft-spot) page.
- Options run on on‑chain [Black–Scholes](/glossary#b) model with implied volatility from AMM windows. They support covered call and put writing and later IV‑informed pricing.
- The Cross‑Collateral permissioned venue is an institution‑oriented stack with reporting and OFAC controls. Deposits can back CLOB orders, futures, and options under one risk engine.
- [Session Keys](/glossary#s) and Wallet Abstraction provide Passkey and WebAuthn sign‑in and delegated session keys for seamless UX. State channels enable continuous trading while withdrawals remain on‑chain gated.
====
docs/smart-contracts/index.md

---
title: Smart Contracts
hidden: true
image: docs-og.png
---

# Smart Contracts

The source code of the Flying Tulip Ecosystem contracts is available on Github. All contracts are licenced under XXX.
====
docs/smart-contracts/ft-token.md

---
image: docs-og.png
---

# FT Token

## Overview

The FT token is Flying Tulip's native cross-chain token built on LayerZero's OFT standard, enabling seamless transfers between supported blockchains while incorporating pause functionality and role-based access control.

## Technical Implementation

The FT token contract:

* Is initially deployed with 10 billion tokens minted on Sonic chain (ID 146)
* Implements ERC20Permit for gasless approval transactions
* Features a pausing mechanism that can be controlled by owner or configurator
* Supports burning functionality for token redemption mechanisms
* Uses LayerZero's OFT standard for cross-chain transfers

## Access Control

The contract has two privileged roles:

* **Owner**: Can change token name/symbol and toggle pause state
* **Configurator**: Can toggle pause state and transfer configurator role

When paused, transfers are restricted except for:

* The configurator address
* The LayerZero endpoint
* Messages initiated by the configurator

## Contract Inheritance

The contract inherits all standard ERC20 functions (`balanceOf`, `totalSupply`, `allowance`, etc.) and ERC20Permit functions (`permit`, `nonces`, `DOMAIN_SEPARATOR`).

## Write Functions

### transfer

Transfers tokens from caller to recipient

```solidity
function transfer(address to, uint256 amount) external returns (bool)
```

#### Parameters

`to`: Recipient address

`amount`: Amount to transfer

#### Returns

`bool`: Success boolean

### transferFrom

Transfers tokens using allowance mechanism

```solidity
function transferFrom(address from, address to, uint256 amount) external returns (bool)
```

#### Parameters

`from`: Source address

`to`: Destination address

`amount`: Amount to transfer

#### Returns

`bool`: Success boolean

### approve

Sets spender's allowance over caller's tokens

```solidity
function approve(address spender, uint256 amount) external returns (bool)
```

#### Parameters

`spender`: Address to authorize

`amount`: Allowance amount

#### Returns

`bool`: Success boolean

### increaseAllowance

Increases spender's allowance

```solidity
function increaseAllowance(address spender, uint256 addedValue) external returns (bool)
```

#### Parameters

`spender`: Address to authorize

`addedValue`: Amount to add to allowance

#### Returns

`bool`: Success boolean

### decreaseAllowance

Decreases spender's allowance

```solidity
function decreaseAllowance(address spender, uint256 subtractedValue) external returns (bool)
```

#### Parameters

`spender`: Address to authorize

`subtractedValue`: Amount to subtract from allowance

#### Returns

`bool`: Success boolean

### permit

Approves spender to spend owner's tokens via signed authorization

```solidity
function permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external
```

#### Parameters

`owner`: Token owner

`spender`: Authorized spender

`value`: Amount to approve

`deadline`: Permit expiration timestamp

`v`, `r`, `s`: Signature components

### burn

Burns tokens from caller's balance

```solidity
function burn(uint256 amount) external
```

#### Parameters

`amount`: Number of tokens to burn

### burnFrom

Burns tokens from another account (requires approval)

```solidity
function burnFrom(address account, uint256 amount) external
```

#### Parameters

`account`: Address to burn from

`amount`: Number of tokens to burn

### setPaused

Pauses or unpauses token transfers

```solidity
function setPaused(bool isPaused) external
```

#### Parameters

`isPaused`: True to pause, false to unpause

### transferConfigurator

Transfers configurator role to new address

```solidity
function transferConfigurator(address newConfigurator) external
```

#### Parameters

`newConfigurator`: New configurator address

### setName

Changes token name

```solidity
function setName(string memory newName) external
```

#### Parameters

`newName`: New token name

### setSymbol

Changes token symbol

```solidity
function setSymbol(string memory newSymbol) external
```

#### Parameters

`newSymbol`: New token symbol

### send

Sends tokens to another chain

```solidity
function send(uint16 dstChainId, bytes calldata to, uint256 amount, address zroPaymentAddress, bytes calldata adapterParams) external payable
```

#### Parameters

`dstChainId`: Destination chain ID

`to`: Recipient address bytes

`amount`: Amount to send

`zroPaymentAddress`: ZRO payment address

`adapterParams`: Parameters for the adapter

## View Functions

### name

Gets token name

```solidity
function name() public view returns (string memory)
```

#### Returns

`string`: Current token name

### symbol

Gets token symbol

```solidity
function symbol() public view returns (string memory)
```

#### Returns

`string`: Current token symbol

### totalSupply

Returns the total token supply

```solidity
function totalSupply() external view returns (uint256)
```

#### Returns

`uint256`: Total token supply

### balanceOf

Returns the token balance of an account

```solidity
function balanceOf(address account) external view returns (uint256)
```

#### Parameters

`account`: Address to query

#### Returns

`uint256`: Token balance

### allowance

Returns amount spender is allowed to use on behalf of owner

```solidity
function allowance(address owner, address spender) external view returns (uint256)
```

#### Parameters

`owner`: Token owner

`spender`: Authorized spender

#### Returns

`uint256`: Allowance amount

### nonces

Returns the current nonce for owner (used in permit)

```solidity
function nonces(address owner) external view returns (uint256)
```

#### Parameters

`owner`: Address to query

#### Returns

`uint256`: Current nonce

### configurator

Gets configurator address

```solidity
function configurator() external view returns (address)
```

#### Returns

`address`: Current configurator address

### estimteSendFee

Estimates fee for sending tokens to another chain

```solidity
function estimateSendFee(uint16 dstChainId, bytes calldata to, uint256 amount, bool useZro, bytes calldata adapterParams) external view returns (uint256 nativeFee, uint256 zroFee)
```

#### Parameters

`dstChainId`: Destination chain ID

`to`: Recipient address bytes

`amount`: Amount to send

`useZro`: Whether to use ZRO token for fees

`adapterParams`: Parameters for the adapter

#### Returns

`nativeFee`: Fee in native currency

`zroFee`: Fee in ZRO tokens

### circulatingSupply

Returns the circulating supply of tokens on the current chain

```solidity
function circulatingSupply() external view returns (uint256)
```

#### Returns

`uint256`: Circulating supply

### owner

Returns the address of the current owner

```solidity
function owner() public view returns (address)
```

#### Returns

`address`: Owner address

### SONIC\_CHAIN\_ID

Gets the Sonic chain ID

```solidity
function SONIC_CHAIN_ID() public view returns (uint16)
```

#### Returns

`uin16`: Sonic chain ID (146)

### DOMAIN\_SEPARATOR

Returns the domain separator used in the encoding of the signature for permit

```solidity
function DOMAIN_SEPARATOR() external view returns (bytes32)
```

#### Returns

`bytes32`: Domain separator hash

### eip712Domain

Returns the EIP712 domain values used for permit signatures

```solidity
function eip712Domain() external view returns (bytes1 fields, string memory name, string memory version, uint256 chainId, address verifyingContract, bytes32 salt, uint256[] memory extensions)
```

#### Returns

`fields`: Bit field indicating which parameters are present

`name`: Name of the signing domain (token name)

`version`: Version of the signing domain (typically "1")

`chainId`: Chain ID where contract is deployed

`verifyingContract`: Address of the token contract

`salt`: Domain disambiguator (typically unused)

`extensions`: Array for future extensions (typically empty)

## Mainnet Deployments

### Ethereum: 1

| Contract     | Address |
| ------------ | ------- |
| Flying Tulip | 0x0     |

### Binance Smart Chain: 56

| Contract     | Address |
| ------------ | ------- |
| Flying Tulip | 0x0     |

### Sonic: 146

| Contract     | Address |
| ------------ | ------- |
| Flying Tulip | 0x0     |

### Avalanche: 43114

| Contract     | Address |
| ------------ | ------- |
| Flying Tulip | 0x0     |
====
docs/smart-contracts/ftyieldwrapper.md

---
image: docs-og.png
---

# ftYieldWrapper

## Overview

The ftYieldWrapper contract is a capital management system that wraps a single underlying asset (e.g., USDC) and issues corresponding ftTokens (e.g., ftUSDC). It enables deploying assets across multiple yield-generating strategies while maintaining a unified interface for deposits, withdrawals, and yield claiming. The contract serves as a key infrastructure component for Flying Tulip's yield generation and capital efficiency.

## Access Control

The contract has four privileged roles:

* **Yield Claimer**: Primary administrator who can deploy capital to strategies, force withdrawals, and claim yield. Also manages the role assignments.
* **Strategy Manager**: Responsible for adding, removing, and reordering strategies.
* **Treasury**: Receives claimed yield and serves as a confirming party for role changes.
* **Sub Yield Claimer**: Secondary yield claiming role with limited permissions.

These roles operate with a two-step confirmation process for critical changes, enhancing security.

## Contract Inheritance

The contract also inherits all standard ERC20 view and transfer functions.

## Write Functions

### setYieldClaimer

Sets a new yield claimer (requires confirmation)

```solidity
function setYieldClaimer(address _yieldClaimer) external onlyYieldClaimer
```

#### Parameters

`_yieldClaimer`:: Address of the proposed new yield claimer

### setSubYieldClaimer

Sets the sub yield claimer directly

```solidity
function setSubYieldClaimer(address _subYieldClaimer) external onlyYieldClaimer
```

#### Parameters

`_subYieldClaimer`: Address of the new sub yield claimer

### confirmYieldClaimer

Confirms a pending yield claimer change

```solidity
function confirmYieldClaimer() external
```

### setStrategyManager

Sets a new strategy manager (requires confirmation)

```solidity
function setStrategyManager(address _strategyManager) external onlyStrategyManager
```

#### Parameters

`_strategyManager`: Address of the proposed new strategy manager

### confirmStrategyManager

Confirms a pending strategy manager change

```solidity
function confirmStrategyManager() external
```

### setTreasury

Sets a new treasury (requires confirmation)

```solidity
function setTreasury(address _treasury) external
```

#### Parameters

`_treasury`: Address of the proposed new treasury

### confirmTreasury

Confirms a pending treasury change

```solidity
function confirmTreasury() external
```

### setStrategy

Sets a new strategy to be added (requires confirmation)

```solidity
function setStrategy(address _strategy) external onlyStrategyManager
```

#### Parameters

`_strategy`: Address of the strategy to add

### confirmStrategy

Confirms adding a pending strategy

```solidity
function confirmStrategy() external
```

### removeStrategy

Removes a strategy whose wrapper share balance is zero

```solidity
function removeStrategy(uint256 index) external onlyStrategyManager
```

#### Parameters

`index`: Index of the strategy to remove

### setStrategiesOrder

Reorders strategies for withdrawal priority

```solidity
function setStrategiesOrder(address[] calldata _newOrder) external onlyStrategyManager
```

#### Parameters

`_newOrder`: Array of strategy addresses in the desired order

### claimYield

Claims yield from a specific strategy

```solidity
function claimYield(address _strategy) external onlyYieldClaimers returns (uint256 _yield)
```

#### Parameters

`_strategy`: The strategy to claim yield from

#### Returns

`_yield`: Amount of yield claimed

### claimYields

Claims yield from all registered strategies

```solidity
function claimYields() external onlyYieldClaimers returns (uint256 _yield)
```

#### Returns

`_yield`: Total amount of yield claimed

### claimMerkl

Claims Merkle rewards from a strategy

```solidity
function claimMerkl(address _strategy, address[] calldata users, address[] calldata tokens, uint256[] calldata amounts, bytes32[][] calldata proofs) external onlyYieldClaimers
```

#### Parameters

`_strategy`: Strategy to claim Merkle rewards from

`users`: Array of user addresses

`tokens`: Array of token addresses

`amounts`: Array of token amounts

`proofs`: Array of Merkle proofs

### execute

Executes a custom function call on a strategy

```solidity
function execute(address _strategy, address to, uint256 value, bytes calldata data) external onlyYieldClaimers returns (bool success, bytes memory result)
```

#### Parameters

`_strategy`: Strategy to execute the call on

`to`: Target address for the call

`value`: Native token value to send

`data`: Call data

#### Returns

success: Whether the call was successful

result: Return data from the call

### deposit

Deposits underlying tokens and mints wrapper tokens

```solidity
function deposit(uint256 amount) external nonReentrant
```

#### Parameters

`amount`: Amount of underlying tokens to deposit

### withdraw

Burns wrapper tokens and returns underlying tokens

```solidity
function withdraw(uint256 amount, address to) external nonReentrant
```

#### Parameters

`amount`: Amount of wrapper tokens to burn

`to`: Address to receive the underlying tokens

### withdrawUnderlying

Burns wrapper tokens and returns position tokens

```solidity
function withdrawUnderlying(uint256 amount, address to) external nonReentrant
```

#### Parameters

`amount`: Amount of wrapper tokens to burn

`to`: Address to receive the position tokens

### deploy

Deploys capital to a registered strategy

```solidity
function deploy(address strategy, uint256 amount) external onlyYieldClaimer nonReentrant
```

#### Parameters

`strategy`: Strategy to deploy capital to

`amount`: Amount of underlying tokens to deploy

### forceWithdrawToWrapper

Forces withdrawal from a strategy to the wrapper

```solidity
function forceWithdrawToWrapper(address strategy, uint256 amount) external onlyYieldClaimer nonReentrant
```

#### Parameters

`strategy`: Strategy to withdraw from

`amount`: Amount of tokens to withdraw

### withdrawQueued

Queues a withdrawal from a strategy

```solidity
function withdrawQueued(address strategy, uint256 amount) external onlyYieldClaimer nonReentrant returns (uint256 id)
```

#### Parameters

`strategy`: Strategy to queue withdrawal from

`amount`: Amount to withdraw

#### Returns

`id`: Withdrawal queue ID

### claimQueued

Claims a queued withdrawal

```solidity
function claimQueued(address strategy, uint256 id) external onlyYieldClaimer nonReentrant returns (uint256 received)
```

#### Parameters

`strategy`: Strategy to claim from

`id`: Withdrawal queue ID

#### Returns

`received`: Amount received from the withdrawal

## View Functions

### numberOfStrategies

Returns the number of registered strategies

```solidity
function numberOfStrategies() external view returns (uint256)
```

#### Returns

`uint256`: Number of registered strategies

### capital

Returns the total capital managed by the wrapper

```solidity
function capital() external view returns (uint256)
```

#### Returns

`uint256`: Total capital (in underlying tokens)

### valueOfCapital

Returns the total value of capital including yield

```solidity
function valueOfCapital() public view returns (uint256 _capital)
```

#### Returns

`_capital`: Total value of capital including yield

### yield

Returns the accumulated yield

```solidity
function yield() public view returns (uint256)
```

#### Returns

`uint256`: Accumulated yield

### availableToWithdraw (strategy)

Returns the amount available to withdraw from a strategy

```solidity
function availableToWithdraw(address strategy) public view returns (uint256 liquidity)
```

#### Parameters

`strategy`: Strategy address to check

#### Returns

`liquidity`: Amount available to withdraw

### availableToWithdraw (total)

Returns the total amount available to withdraw

```solidity
function availableToWithdraw() public view returns (uint256 liquidity)
```

#### Returns

`liquidity`: Total amount available to withdraw

### canWithdraw

Checks if a withdrawal amount is possible

```solidity
function canWithdraw(uint256 amount) external view returns (bool)
```

#### Parameters

`amount`: Amount to check

#### Returns

`bool`: Whether the amount can be withdrawn

### maxAbleToWithdraw

Returns the maximum amount that can be withdrawn

```solidity
function maxAbleToWithdraw(uint256 amount) external view returns (uint256)
```

#### Parameters

`amount`: Requested amount

#### Returns

`uint256`: Maximum amount that can be withdrawn

### isStrategy

Checks if an address is a registered strategy

```solidity
function isStrategy(address _strategy) public view returns (bool)
```

#### Parameters

`_strategy`: Address to check

#### Returns

`bool`: Whether the address is a registered strategy

### availableToDeposit

Returns the amount available to deposit

```solidity
function availableToDeposit() external view returns (uint256)
```

#### Returns

`uint256`: Amount available to deposit

### decimals

Returns the number of decimals for the token

```solidity
function decimals() public view returns (uint8)
```

#### Returns

`uint8`:: Number of decimals

### deployed

Returns the total amount deployed to strategies

```solidity
uint256 public deployed
```

#### Returns

`uint256`: Total amount deployed

### token

Returns the underlying token address

```solidity
address public immutable token
```

#### Returns

`address`: Underlying token address

### strategies

Returns a strategy at the specified index

```solidity
IStrategy[] public strategies
```

#### Parameters

`index`: Array index

#### Returns

IStrategy: Strategy contract at that index

### deployedToStrategy

Returns the amount deployed to a specific strategy

```solidity
mapping(address strategy => uint256 deployed) public deployedToStrategy
```

#### Parameters

`strategy`: Strategy address

#### Returns

`uint256`: Amount deployed to strategy
====
docs/smart-contracts/pft.md

---
image: docs-og.png
---

# pFT

## Overview

The pFT contract is an ERC721 NFT implementation representing PUT options for Flying Tulip tokens, allowing holders to divest their FT tokens back to original collateral at a predetermined strike price. Each NFT represents one PUT position with its specific terms.

## Access Control

The contract has one privileged role:

* **Put Manager**: Controls all operational aspects including minting new PUT options, processing withdrawals, divests, and burns. This is typically the PutManager contract.

The NFT ownership model ensures that only token owners can perform actions on their specific PUT positions.

## Contract Inheritance

The contract also inherits all standard ERC721Enumerable view functions for token enumeration and ownership queries.

## Write Functions

### initialize

Initializes the contract with put manager address

```solidity
function initialize(address _putManager) public initializer
```

#### Parameters

`_putManager`: Address of the put manager

### setPutManager

Updates the put manager address

```solidity
function setPutManager(address _putManager) external onlyPutManager
```

#### Parameters

`_putManager`: Address of the put manager

### mint

Creates a new PUT option NFT

```solidity
function mint(address owner, uint256 amount, uint256 ft, uint256 usd, address token) external onlyPutManager nonReentrant returns (uint256 id)
```

#### Parameters

`owner`: Recipient address

`amount`: Collateral amount

`ft`: FT token amount

`usd`: Strike price

`token`: Collateral token address

#### Returns

`id`: New token ID

### withdrawFT

Withdraws FT tokens from a PUT position

```solidity
function withdrawFT(address owner, uint256 id, uint256 amount) external onlyPutManager nonReentrant returns (uint256 strike, address token)
```

#### Parameters

`owner`: NFT owner address

`id`: NFT token ID

`amount`: FT amount to withdraw

#### Returns

`strike`: Strike price

`token`: Collateral token address

### divest

Exercises the PUT to divest FT for collateral.

```solidity
function divest(address owner, uint256 id, uint256 amount) external onlyPutManager nonReentrant returns (uint256 strikeAmount, address token)
```

#### Parameters

`owner`: NFT owner address

`id`: NFT token ID

`amount`: FT amount to divest

#### Returns

`strike`: Strike price

`token`: Collateral token address

### burn

Burns a PUT token during public offering

```solidity
function burn(address owner, uint256 id) external onlyPutManager nonReentrant
```

#### Parameters

`owner`: NFT owner address

`id`: NFT token ID

## View Functions

### puts

Returns the PUT details for a given token ID

```solidity
mapping(uint256 tokenId => Put put) public puts
```

#### Parameters

`tokenId`: NFT token ID

#### Returns

Put: Struct with PUT details

### nextIndex

Returns the next token ID to be minted

```solidity
uint96 public nextIndex
```

#### Returns

`uint96`: Next token ID

### putManager

Returns the current put manager address

```solidity
address public putManager
```

#### Returns

`address`: Put manager address

### divestable

Returns divestable info for a PUT

```solidity
function divestable(uint256 id) external view returns (uint256 divestableAmount, uint256 strikeAmount, address token)
```

#### Parameters

`id`: NFT token ID

#### Returns

`divestableAmount`: Amount of FT that can be divested

`strikeAmount`: Strike price

`token`: Collateral token address

### supportsInterface

Checks if contract implements an interface

```solidity
function supportsInterface(bytes4 interfaceId) public view override returns (bool)
```

#### Parameters

`interfaceId`: Interface identifier

#### Returns

`bool`: Interface support status
====
docs/smart-contracts/putmanager.md

---
image: docs-og.png
---

# PutManager

## Overview

The PutManager contract manages PUT options for Flying Tulip tokens (FT), enabling users to invest collateral to withdraw FT tokens and later divest those tokens for their original collateral at a fixed exchange rate.

## Access Control

The contract has two privileged roles:

* **Multisig Wallet (msig)**: Primary administrator with the ability to pause/unpause the contract, add accepted collateral, update key addresses, and withdraw divested capital.
* **Configurator**: Secondary administrator that can end the public offering, add FT liquidity, set collateral caps, and send remainder FT back to the configurator.

The contract operates in two states:

* **IN\_PUB\_OFFERING**: Initial state where users can invest collateral and withdraw FT tokens into their PUT position
* **AFTER\_PUB\_OFFERING**: State after the offering ends where users can withdraw FT (invalidating their PUT) or divest (return FT for their original collateral)

## Write Functions

### initialize

Initializes the proxy contract with initial configuration

```solidity
function initialize(address _configurator, address _msig) external initializer
```

#### Parameters

`_configurator`: Address of the configurator

`_msig`: Address of the multisig

### pause

Pauses contract operations

```solidity
function pause() external onlyMsig
```

### unpause

Unpauses contract operations

```solidity
function unpause() external onlyMsig
```

### setMsig

Schedules an update to the multisig wallet address

```solidity
function setMsig(address _msig) external onlyMsig
```

#### Parameters

`_msig`: New multisig wallet address

### acceptMsig

Confirms multisig wallet change after delay period

```solidity
function acceptMsig() external
```

### setPutManager

Updates the Put Manager address in the ftPut contract

```solidity
function setPutManager(address _putManager) external onlyMsig
```

#### Parameters

`_putManager`: New Put Manager address

### setConfigCurator

Updates the configurator address

```solidity
function setConfigurator(address _configurator) external onlyMsig
```

#### Parameters

`_configurator`: New configurator address

### endPubOffering

Ends the public offering phase

```solidity
function endPubOffering() external onlyConfigurator
```

### addFTLiquidity

Adds FT tokens to the offering supply

```solidity
function addFTLiquidity(uint256 amount) external onlyConfigurator
```

#### Parameters

`amount`: Amount of FT tokens to add

### setPriceBounds

Sets minimum and maximum price bounds for collateral

```solidity
function setPriceBounds(address token, uint256 minP, uint256 maxP) external onlyMsig
```

#### Parameters

`token`: Collateral token address

`minP`: Minimum price

`maxP`: Maximum price

### sendRemainderFTtoConfigurator

Sends unsold FT tokens back to configurator

```solidity
function sendRemainderFTtoConfigurator() external onlyConfigurator
```

### addAcceptedCollateral

Adds a token to accepted collateral list

```solidity
function addAcceptedCollateral(address _collateral, address _vault) external onlyMsig
```

#### Parameters

`_collateral`: Collateral token address

`_vault`: Yield wrapper address

### setCollateralCaps

Sets maximum amount for a specific collateral

```solidity
function setCollateralCaps(address token, uint256 cap_) external onlyConfigurator
```

#### Parameters

`token`: Collateral token address

`cap_`: Maximum collateral amount

### invest

Creates a PUT position by depositing collateral

```solidity
function invest(address token, uint256 amount) external nonReentrant whenNotPaused returns (uint256 id)
```

#### Parameters

`token`: Collateral token address

`amount`: Collateral amount

#### Returns

`id`: Position ID

### exit

Exits a position during public offering

```solidity
function exit(uint256 id) external nonReentrant
```

#### Parameters

`id`: Position ID

### withdrawFT

Withdraws FT tokens, invalidating PUT

```solidity
function withdrawFT(uint256 id, uint256 amount) external nonReentrant
```

#### Parameters

`id`: Position ID

`amount`: FT amount

### withdrawInvestedCapital

Withdraws capital released from divested positions

```solidity
function withdrawDivestedCapital(address token, uint256 amount) external nonReentrant onlyMsig
```

#### Parameters

`token`: Token address

`amount`: Amount to withdraw

### divest

Executes PUT to divest FT for original collateral.

```solidity
function divest(uint256 id, uint256 amount) external nonReentrant
```

#### Parameters

`id`: Position ID

`amount`: FT amount

### divestUnderlying

Executes PUT to divest FT for underlying token.

```solidity
function divestUnderlying(uint256 id, uint256 amount) external nonReentrant
```

#### Parameters

`id`: Position ID

`amount`: FT amount

## View Functions

### collateralIndex

Returns the number of accepted collateral tokens

```solidity
function collateralIndex() external view returns (uint256)
```

#### Returns

`uint256`: Number of collateral tokens

### getAssetPrice

Gets asset price from Aave Oracle

```solidity
function getAssetPrice(address token) public view returns (uint256)
```

#### Parameters

`token`: Token address

#### Returns

`uint256`: Asset price in oracle units

### getFTAddress

Returns the FT token address

```solidity
function getFTAddress() public view returns (address)
```

#### Returns

`address`: FT token address

### getAaveOracleAddress

Returns the Aave Oracle address

```solidity
function getAaveOracleAddress() public view returns (address)
```

#### Returns

`address`: Aave Oracle address

### getAssetFTPrice

Calculates FT tokens for a collateral amount

```solidity
function getAssetFTPrice(address token, uint256 amount) public view returns (uint256 ftToTransfer, uint256 assetToUSD)
```

#### Parameters

`token`: Collateral token address

`amount`: Collateral amount

#### Returns

`ftToTransfer`: FT amount

`assetToUSD`: USD price from oracle

### canDivest

Checks if a position can be divested

```solidity
function canDivest(uint256 id, uint256 _amount) external view returns (bool divestable, uint256 amount)
```

#### Parameters

`id`: Position ID

`_amount`: Requested amount

#### Returns

`divestable`: Whether divestment is possible

`amount`: Amount that can be divested

### maxDivestable

Calculates maximum divestable amount

```solidity
function maxDivestable(uint256 id, uint256 _amount) external view returns (bool divestable, uint256 amount)
```

#### Parameters

`id`: Position ID

`_amount`: Requested amount

#### Returns

`divestable`: Whether divestment is possible

`amount`: Maximum amount that can be divested
====