# Saffron DAO
Source: https://docs.saffron.finance/dao-docs/index

Information on the Saffron DAO.

Coming soon.

[Back to Product Documentation](/)


# Saffron History
Source: https://docs.saffron.finance/history/history

Timeline of Saffron Products.

The first implementation of the Saffron risk exchange mechanism was released in October 2020 as a DeFi tranching mechanism for Compound. It was later deprecated in 2021 and replaced by a DeFi insurance mechanism, where users entered short-term insurance contracts protecting against underlying protocol failure. This resulted in one successful protocol cover and payout on the Harmony network.

Previous versions of Saffron were deprecated and efforts to build fixed yield vaults began in early 2023. The first implementation of Saffron fixed yield vaults use Uniswap concentrated liquidity pools (Uniswap V3) as an underlying yield source.

## Learn more about Saffron:

* [Audits](/security/audits)
* [Saffron Vaults](/saffron-vaults/overview)
* [Community](/introduction/community)


# Community
Source: https://docs.saffron.finance/introduction/community

Saffron Community Links.

<Icon icon="x-twitter" /> [Twitter / 𝕏](https://x.com/Saffron)

<Icon icon="telegram" /> [Telegram](https://t.me/saffronfinance)

<Icon icon="github" /> [GitHub](https://github.com/saffron-finance)

<Icon icon="medium" /> [Medium](https://medium.com/saffron-finance)

[Next Section: Saffron Vaults](/saffron-vaults/overview)


# Saffron Intro
Source: https://docs.saffron.finance/introduction/index



<img alt="Saffron Logo" />

Saffron is a peer-to-peer interest risk adjustment protocol. Underlying yield is transformed by a smart contract system according to users' indicated risk.

The current implementation of Saffron is a fixed yield layer on top of [Uniswap pools](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/pools). Saffron vaults match liquidity providers who want fixed yield with traders who buy future yield.

Learn more about Saffron vaults here: [Vaults Overview](/saffron-vaults/overview).

### Audits

Saffron has undergone 9 audits as of December 19th, 2025. The 5 most recent audits are based on the same commit hash, which is the hash that will be used to deploy the upcoming Saffron vaults release, scheduled for early 2026.

You can view audit reports and security commitments [here](/security/audits).

### Saffron's native token Spice (SFI)

\$SFI, or [Spice (SFI)](https://app.uniswap.org/explore/tokens/ethereum/0xb753428af26E81097e7fD17f40c88aaA3E04902c?inputCurrency=NATIVE), is the native token for Saffron. SFI was created in a liquidity mining program in the early epochs of Saffron from October 2020 to mid 2021.

## Learn more about Saffron:

* [Saffron Vaults](/saffron-vaults/overview)
* [Community](/introduction/community)
* [History](/history/history)


# Saffron Academy
Source: https://docs.saffron.finance/saffron-academy

Coming Soon



# Saffron V2
Source: https://docs.saffron.finance/saffron-v2





# External Integrations
Source: https://docs.saffron.finance/saffron-vaults/external-integrations

Third-party dependencies for token handling, liquidity management, and vault execution.

### Dependencies

* **Uniswap V3 Core and Periphery**
  * `IUniswapV3Factory` validates pool authenticity before adapter initialization
  * `INonfungiblePositionManager` for LP position management (`mint`, `collect`, `decreaseLiquidity`, `burn`)

* **OpenZeppelin**
  * `ReentrancyGuard` — protects state-modifying calls
  * `Ownable2Step` — secure ownership transfer pattern
  * `ERC20` — base implementation for all vault bearer tokens


# Fee Mechanism
Source: https://docs.saffron.finance/saffron-vaults/fee-mechanism

How protocol fees are calculated, minted, and distributed using variableBearerToken during vault settlement.

Protocol fees are collected by minting additional `variableBearerToken` to the vault during settlement rather than deducting from deposits or yields.

* **Fee mint formula:**
  `mintAmount = variableBearerToken.totalSupply() * feeBps / (10000 - feeBps)`

  Rather than deducting fees from earnings, the protocol mints new `variableBearerToken` to itself, diluting existing holders. This formula ensures the protocol ends up with exactly `feeBps` percentage of the final token supply.

  **Example (12.5% fee):**

  * Pre-mint supply: 100 tokens
  * `mintAmount = 100 * 1250 / (10000 - 1250) ≈ 14.29`
  * Post-mint supply: 114.29 tokens
  * Protocol share: 14.29 / 114.29 = 12.5%
  * Depositor share: 100 / 114.29 = 87.5%

* **Fee invariants:**
  * Fee rate is locked per vault at initialization
  * `expectedFeeBps` prevents configuration drift between vault creation and initialization

* **Realization:**
  * Fees accrue to the protocol and are redeemed by the current `feeReceiver()` upon withdrawal

<Info>
  Fee rates are configured by the vault factory owner.
</Info>


# Important System Parameters
Source: https://docs.saffron.finance/saffron-vaults/important-system-parameters

Configuration parameters for factories, vaults, and adapters.

### Core Parameters

| Parameter               | Location            | Description                                                                                                        |
| ----------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------ |
| feeBps                  | VaultFactory, Vault | Protocol fee rate in basis points (range: 0–9999). Set on VaultFactory and copied to each Vault at initialization. |
| feeReceiver             | VaultFactory        | Address that collects protocol fees. Dynamically queried by vaults at withdrawal time.                             |
| defaultDepositTolerance | VaultFactory        | Default deposit tolerance in basis points (e.g., 100 = 1%). Applied to adapters at creation time.                  |
| positionManager         | VaultFactory        | Immutable Uniswap V3 Position Manager address passed to all adapters.                                              |

### Vault Parameters

| Parameter            | Location | Description                                                                                             |
| -------------------- | -------- | ------------------------------------------------------------------------------------------------------- |
| fixedSideCapacity    | Vault    | Target Uniswap liquidity ("L" value) for the fixed side deposit                                         |
| variableSideCapacity | Vault    | Maximum amount of variable asset deposits allowed.                                                      |
| duration             | Vault    | Time-lock period for the vault in seconds.                                                              |
| variableAsset        | Vault    | Address of the ERC20 token used for variable side deposits.                                             |
| endTime              | Vault    | Timestamp when the vault duration ends. Calculated as block.timestamp + duration when the vault starts. |

### Adapter Parameters

| Parameter                 | Location     | Description                                                                                                                                 |
| ------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| poolMinTick / poolMaxTick | UniV3Adapter | Uniswap V3 tick range for LP positions. Auto-calculated for full-range adapters; specified by the vault creator for limited-range adapters. |
| depositTolerance          | UniV3Adapter | Lower-bound tolerance for liquidity in basis points. Deposit fails if minted liquidity falls below fixedSideCapacity \* (1 - tolerance).    |
| upperDepositTolerance     | UniV3Adapter | Upper-bound tolerance for liquidity in basis points. Deposit fails if minted liquidity exceeds fixedSideCapacity \* (1 + tolerance).        |
| poolKey                   | UniV3Adapter | Uniswap V3 pool configuration containing token0, token1, and fee.                                                                           |
| tokenId                   | UniV3Adapter | Uniswap V3 NFT position token ID, set when the fixed side deposit mints liquidity.                                                          |
| liquidity                 | UniV3Adapter | The "L" value of the minted Uniswap V3 position.                                                                                            |


# Non-Trivial Financial Logic
Source: https://docs.saffron.finance/saffron-vaults/non-trivial-financial-logic

Formulas and validation rules for payouts, fees, and liquidity.

### Proportional Share Calculation

variable side earnings are based on proportional ownership of total supply and total generated yield.

```solidity theme={null}
share = mulDiv(userTokens, totalEarnings, totalTokens);
```

* Uses mulDiv to avoid rounding loss and overflow

***

### Liquidity Tolerance Protection

To prevent misconfiguration or malicious deviation in liquidity provisioning, adapters enforce strict tolerance bounds.

Example: **100 bps tolerance (±1%)**

```solidity theme={null}
require(actualLiquidity >  targetLiquidity * 9900 / 10000,  "L");
require(actualLiquidity <= targetLiquidity * 10100 / 10000, "Excessive liquidity");
```

* Ensures the deployed liquidity matches expectations within an acceptable error window


# Overview
Source: https://docs.saffron.finance/saffron-vaults/overview

How Saffron Vaults Work

Saffron Fixed Income Vaults enable zero-coupon swaps on Uniswap V3 liquidity positions. The fixed side provides liquidity and sells their future trading fees for a guaranteed upfront payment. The variable side pays this premium, speculating that the yield earned will exceed their cost.

### Participants

* **Fixed side** — Provides token0 and token1 to mint a Uniswap V3 position. Receives a guaranteed premium upfront instead of uncertain trading fees. Limited to one depositor per vault

* **Variable side** — Pays the premium in exchange for all trading fees generated during the vault's duration. Multiple depositors can participate, sharing yield proportionally

### Vault Mechanics

A typical vault lifecycle consists of:

1. A vault is created with configured duration, capacities, and pool parameters
2. The fixed side deposits token0 and token1, minting a Uniswap V3 position
3. The variable side deposits the premium amount
4. Once both sides reach capacity, the vault starts automatically
5. The fixed side calls `claim()` to receive their premium
6. The Uniswap position earns trading fees for the configured duration
7. After maturity, the fixed side withdraws their original liquidity (token0/token1)
8. The variable side withdraws all accumulated trading fees

### Hypothetical Example

**Fixed side:**

* \$1,000,000 WETH/USDC LP position
* 1 year lock duration
* 20% fixed APR (\$200,000 paid upfront)

**Variable side:**

* \$200,000 premium payment
* Exclusive rights to all trading fees from the \$1,000,000 position

**Outcome:**

* Assume 40% APY on the WETH/USDC position
* Variable side earns 400,000 USDC in trading fees
* Net profit: 200,000 USDC (100% return on premium)

### Vault Parameters

Vaults are configured with the following parameters:

* **Duration** — lock period for the vault
* **Fixed Capacity** — target liquidity amount for the Uniswap V3 position
* **Variable Capacity** — total premium required from variable side depositors
* **Variable Asset** — token used for premium payments
* **Fee** — protocol fee (set at factory level, locked at initialization)
* **Pool** — the Uniswap V3 pool for liquidity provision
* **Tick Range** — price bounds for the LP position

The combination of duration and capacities determines the fixed APR. Any standard ERC20 token can be used as the variable asset. Non-standard tokens (fee-on-transfer, rebasing, etc.) are not supported.


# Smart Contracts
Source: https://docs.saffron.finance/saffron-vaults/smart-contracts

Technical overview of the Saffron Vaults smart contract system

```mermaid theme={null}
flowchart LR

%% ================= Node Definitions & Shapes =================
    RVF["RestrictedVaultFactory"]
    VF["VaultFactory"]

    V(["UniV3Vault"])
    VA[["Vault (abstract)"]]

    LRA["UniV3LimitedRangeAdapter"]
    FRA["UniV3FullRangeAdapter"]
    ABase["AdapterBase"]

%% ================= Factories =================
    RVF -.-> |"extends"| VF

%% ================= Vault =================
    VF -- "createVault" --> V
    V -.-> VA

%% ================= Adapter System =================
    VF -- "creates" --> LRA
    VF -- "creates" --> FRA
    FRA -.-> |"extends"| LRA

    V -- "manages" --> ABase
    V --> LRA
    V --> FRA

%% ================= Assets & External =================
    subgraph Tokens ["Token Layer"]
        direction TB
        CT["ClaimToken"]
        FBT["FixedBearerToken"]
        VBT["VariableBearerToken"]
    end

    V --> Tokens

    subgraph External ["External Protocols"]
        direction TB
        UPool[("Uniswap V3 Pool")]
        UPosMgr["PositionManager"]
        VarAsset["variableAsset (ERC20)"]
    end

    LRA & FRA --> External

%% ================= Styling (CSS Classes) =================
    classDef factory fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#2e1065
    classDef vault fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e3a8a
    classDef adapter fill:#fff7ed,stroke:#ea580c,stroke-width:2px,color:#7c2d12
    classDef tokens fill:#f0fdf4,stroke:#16a34a,stroke-width:2px,color:#14532d
    classDef external fill:#fafafa,stroke:#525252,stroke-width:1px,stroke-dasharray: 5 5,color:#171717

    class RVF,VF factory
    class V,VA vault
    class LRA,FRA,ABase adapter
    class CT,FBT,VBT tokens
    class UPool,UPosMgr,VarAsset external
```

## Contract Architecture

Saffron Vaults consist of four contract types: factories, vaults, adapters, and bearer tokens.

### VaultFactory / RestrictedVaultFactory

* Deploys new vaults and adapters from stored bytecode implementations
* Maintains protocol-level settings such as:
  * `feeBps` (protocol fee in basis points)
  * `feeReceiver` (address receiving protocol fees)
* Registers and tracks all deployed instances with associated metadata
* `RestrictedVaultFactory` extends `VaultFactory` and:
  * Restricts all vault and adapter creation to `onlyOwner`
  * Restricts initialization and configuration flows to `onlyOwner`

### UniV3Vault

* Core vault contract that coordinates fixed side and variable side deposits
* Starts automatically when both fixed and variable sides reach capacity
* Once started, funds are locked until maturity
* Enables fixed side positions to convert from `claimToken` to `fixedBearerToken` via `claim()` after vault start
* Settles Uniswap V3 fee earnings at maturity and:
  * Distributes variable side yield via `variableBearerToken`
  * Mints protocol fees in `variableBearerToken` (held by vault for `feeReceiver` to claim)
* Allows early withdrawals only before the vault has started; no withdrawals after start until maturity

### UniV3LimitedRangeAdapter

* Connects a vault to a specific Uniswap V3 pool over a defined tick range
* Mints, manages, and burns the Uniswap V3 position NFT on behalf of the vault
* Provides functions to:
  * Add/remove liquidity
  * Collect and return underlying liquidity and accumulated trading fees
* Enforces:
  * Liquidity tolerance bounds (to protect against misconfiguration)
  * Pool authenticity checks (ensuring the correct Uniswap V3 pool is used)
* Handles early capital return for fixed side withdrawals before the vault starts

### UniV3FullRangeAdapter

* Extends `UniV3LimitedRangeAdapter` with full-range tick configuration
* Automatically sets tick range to `MIN_TICK` and `MAX_TICK` during initialization
* Provides the same functionality as `UniV3LimitedRangeAdapter` but covers the entire price range

### VaultBearerToken

* ERC-20 token contract used for all vault position tokens
* Three instances created per vault:
  * `claimToken` — represents the initial fixed side deposit
  * `fixedBearerToken` — represents the fixed side position after claiming
  * `variableBearerToken` — represents variable side deposits and share of trading fees
* Minting and burning restricted to the owning vault contract


# Trust Model
Source: https://docs.saffron.finance/saffron-vaults/trust-model

Users control their funds trustlessly; only privileged roles can configure or deploy vaults.

### Factory Owner

The factory owner controls protocol-level settings but cannot access user funds or modify deployed vaults.

**Can:**

* Add or revoke vault and adapter contract types
* Set fee parameters and the fee receiver
* Set default deposit tolerance for adapters
* Deploy adapters and create vaults
* Initialize vault parameters (capacity, duration, asset type)

**Cannot:**

* Modify or upgrade deployed vaults
* Access or withdraw user funds
* Renounce ownership (`renounceOwnership()` is disabled to prevent unowned factory risk)

Ownership transfers use `Ownable2Step` for added safety.

### Users

Users interact with vaults trustlessly — no administrator can access or gate their funds.

* Funds are fully withdrawable prior to vault start
* Once active, funds are locked only by the vault's configured duration (not by any admin control)

### External Dependencies: Uniswap V3

Vaults rely on Uniswap V3 for liquidity provisioning, fee accounting, and NFT position management.

* AMM performance, tick behavior, and fee generation are external to the protocol
* Adapter validation ensures only authentic Uniswap V3 pools are used


# Vault Lifecycle
Source: https://docs.saffron.finance/saffron-vaults/vault-lifecycle

How vaults are created, funded, and settled on-chain.

### Phase 0: Vault Creation

<Note>
  These steps assume a `VaultFactory` has already been deployed and configured with valid vault and adapter types.
</Note>

Vault creation is a three-step process:

1. `createAdapter(adapterTypeId, poolAddress, data)` — Deploys and initializes an adapter for a specific Uniswap V3 pool
2. `createVault(vaultTypeId, adapterAddress)` — Deploys a vault; caller must own the adapter, and the adapter must not already be linked to a vault
3. `initializeVault(vaultId, fixedSideCapacity, variableSideCapacity, duration, variableAsset, expectedFeeBps)` — Sets the vault parameters and binds the adapter

Only the factory owner can perform these actions.

### Phase 1: Depositing

Two deposit paths exist: fixed side and variable side.

#### Fixed Side

`vault.deposit(amount, FIXED, deployCapitalData)`

* The `amount` must be 0 — token amounts are derived from `fixedSideCapacity` and current pool price
* `deployCapitalData` encodes slippage protection (`amount0Min`, `amount1Min`) and a transaction `deadline`
* Adapter mints a Uniswap V3 LP position; depositor receives 1 `claimToken`
* There is only one fixed side depositor per vault

#### Variable Side

`vault.deposit(amount, VARIABLE, deployCapitalData)`

* Mints `variableBearerToken` 1:1 with the deposit
* `deployCapitalData` optionally encodes a minimum accepted amount (for partial fills near capacity)

Balances are tracked against `fixedSideCapacity` and `variableSideCapacity`.

### Phase 2: Vault Start

Once both sides reach capacity, the vault starts automatically.

### Phase 3: Earning Period

The Uniswap V3 position accrues trading fees for the configured duration. No withdrawals are permitted during this phase.

After the vault starts, the fixed side depositor may claim their premium:

`vault.claim()`

* Transfers a proportional share of variable side deposits (the fixed premium) to the caller
* Burns the caller's `claimToken` and mints an equivalent `fixedBearerToken`
* Can be called at any time after the vault starts

### Phase 4: Settlement and Withdrawal

Once maturity is reached, the first withdrawal triggers `settleEarnings()` and mints the protocol fee (in `variableBearerToken` to the vault for the current `feeReceiver()`).

#### Fixed Side

`vault.withdraw(FIXED, removeLiquidityData)`

* Removes all liquidity from Uniswap V3 and returns the underlying tokens (`token0` and `token1`) to the depositor

#### Variable Side

`vault.withdraw(VARIABLE, "")`

* Returns a proportional share of the Uniswap trading fees collected during the vault's lifetime, minus the protocol fee


# Saffron security
Source: https://docs.saffron.finance/security/audits

Smart contract audits and security protocols

## Audits

Below you can find a chronological list of security audits and corresponding reports.

### 2025-2026

| Auditor               | Date       | Commit Hash                     | Report                                                                                                                        |
| --------------------- | ---------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| 0xleastwood           | 01.14.2026 | <Tooltip>edaa...5025b</Tooltip> | [View](https://github.com/saffron-finance/audits/blob/main/0xleastwood-saffron-audit.pdf)                                     |
| ChainSecurity         | 12.15.2025 | <Tooltip>edaa...5025b</Tooltip> | [View](https://www.chainsecurity.com/security-audit/saffron-fixed-income-vaults)                                              |
| WebThree              | 11.18.2025 | <Tooltip>edaa...5025b</Tooltip> | [View](https://github.com/saffron-finance/audits/blob/main/saffron-finance-audit.pdf)                                         |
| Internal              | 10.25.2025 | <Tooltip>edaa...5025b</Tooltip> | Internal                                                                                                                      |
| Sherlock              | 10.18.2025 | <Tooltip>edaa...5025b</Tooltip> | [View](https://github.com/saffron-finance/audits/blob/main/2025_12_05_Final_Saffron_Finance_Public_Audit_Contest_Report_.pdf) |
| Pashov Security Group | 07.21.2025 | <Tooltip>64e4...a4f6a</Tooltip> | [View](https://github.com/pashov/audits/blob/master/team/pdf/Saffron-security-review_2025-07-31.pdf)                          |
| Halborn               | 06.19.2025 | <Tooltip>6c29...2e5bd</Tooltip> | [View](https://drive.google.com/file/d/1GkokNq5zDe8kgSTK1gU-bmJIYror2ql2/view)                                                |

### 2024

| Auditor               | Date       | Commit Hash                     | Report                                                                                    |
| --------------------- | ---------- | ------------------------------- | ----------------------------------------------------------------------------------------- |
| Pashov Security Group | 01.28.2024 | <Tooltip>61a8...b741a</Tooltip> | [View](https://github.com/pashov/audits/blob/master/team/pdf/Saffron-security-review.pdf) |

### 2023

| Auditor    | Date       | Commit Hash                     | Report                                                                                                  |
| ---------- | ---------- | ------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Quantstamp | 01.13.2023 | <Tooltip>223b...6a1d4</Tooltip> | [View](https://certificate.quantstamp.com/full/saffron/e75728bd-278c-4651-b84a-1ee7b8488cb2/index.html) |

## Security Commitments

Upon the release of Saffron Vaults, the following commitments to security systems will be made:

1. \$250,000 ongoing live bug bounty for critical issues (scales up based on TVL).
2. The first round of protocol revenue will be used to perform a 10th audit.
3. DevSecOps will be funded on an ongoing basis by a percentage of protocol revenue.


# Saffron Whitepapers
Source: https://docs.saffron.finance/whitepaper/saffron-fixed-income-vault

Whitepapers written by Saffron team

## Fixed Income Vaults Whitepaper

* Authors: rx, psykeeper
* Date: April 14th, 2023
* Link: [GitHub](https://github.com/saffron-finance/papers/blob/main/SaffronFixedIncomeVault.pdf)

## Lido Fixed Yield Whitepaper

* Whitepaper coming soon
* Authors: rx, psykeeper
* Plain-language article: [https://medium.com/saffron-finance/introducing-saffron-lido-vaults-b3ac6b529023](https://medium.com/saffron-finance/introducing-saffron-lido-vaults-b3ac6b529023)