DIP-1: Tokenised Vaults

1. Overview

DIP-1 introduces tokenised vaults as a core liquidity primitive for Defx.

Historically, Defx Liquidity Engine (DLE) has functioned as a vault on Defx's ecosystem that acted as the primary liquidity engine, aggregating capital and routing it to provide liquidity on Defx's order book.

DIP-1 takes this further.

• Vaults hold capital and run defined strategies.

• Each vault is tokenised into a fungible receipt token that represents proportional claim on the vault’s NAV.

• Vaults can be managed not only by Defx, but also by approved external risk managers and curators.

2. Why have vaults?

Vaults are a way to separate how capital is used from who is providing the capital.

Instead of every LP or participant needing to:

• Understand order book microstructure

• Run their own market-making stack

• Manage risk, hedges, and margin across markets

…they can simply deposit into a vault that does this on their behalf, under transparent and predefined rules.

Vaults helps Defx in several ways:

1. Simplified LP Experience

   • LPs deposit a single asset into a vault.

   • The vault handles strategy execution, risk controls, and operational complexity.

   • LPs see a clear vault token balance and PnL, instead of dealing with per-position or per-market complexity.

2. Unified Liquidity Engine for Defx

   • Vaults act as additional liquidity sources for Defx.

   • Customisable strategies can include market making, funding arbitrage, delta-hedging, or other systematic strategies that help deepen orderbooks and improve execution quality for traders.

3. Isolated Risk Profiles

   • Different vaults can be created with distinct risk/return profiles (e.g., “Conservative Basis Vault”, “Directional MM Vault”, “Delta-Neutral Vault”).

   • Risk is isolated at the vault level: LPs choose their risk bucket and opt into the vaults that work for them

4. Operational & Governance Clarity

   • Vaults create a clean interface between protocol, risk managers, and LPs.

   • Parameters (fee structure, whitelisted protocols, asset list, risk limits) are attached to specific vaults and can be governed and iterated on independently.

DLE was the first vault. This proposal’s goal is to formalise that, make it explicit onchain, and set the stage for multiple specialised vaults.

3. Why Tokenise Them?

Tokenising vault deposits into a standardised receipt token unlocks:

1. Composability

   • Vault tokens become ERC-20 style assets that can be used across all DeFi protocols (money markets, DEXs, structured products).

   • This turns vaults from a closed system into a composable building block.

2. Transparent Claim on NAV

   • Each vault token represents ownership on the vault’s underlying assets (and PnL).

   • The token supply and vault assets can be transparently tracked onchain.

   • Accounting, performance tracking, and reporting become significantly simpler and more auditable.

3. Liquidity & Exit Flexibility

   • LPs can either:

     • Redeem vault tokens for underlying assets or

     • Sell vault tokens on secondary markets

   • This provides more flexible exit options, especially for time sensitive redemptions.

4. Standard Interface for External Managers

   • Tokenisation creates a standard contract interface for:

     • Deposits / withdrawals

     • Fee flows

     • Performance reporting

   • External managers can build on top of that interface and focus on building interesting products with perps and the rest of DeFi in a unified

In short, tokenisation turns vaults into a first-class onchain primitive that users, protocols, and managers can integrate with.

4. Supported Chains & Protocols

Chains:

1. Ethereum

2. Base

3. Arbitrum One

4. Polygon PoS

5. Solana (coming soon)

Approved Protocols:

1. Perp protocols - Defx, Lighter, HyperLiquid

2. AMMs - Aerodrome, Uniswap

3. Lending - Aave, Morpho, Pendle

4. OES (Off-Exchange Settlement) Providers - Copper, Ceffu

5. OES supported CEXs - Binance, ByBit, OKX

5. Onboarding Vault Managers:

• Initially, managers are onboarded via an approval process.

• Over time, the framework may move closer to a permissionless model, subject to safety standards.

Requirements for prospective managers:

• Clear description of the strategy and its edge.

• Defined risk profile:

  • Max leverage, max single-asset exposure, max drawdown, scenario assumptions.

• Operational details:

  • How trades are executed (manual/systematic), failover plans, monitoring.

• Track record or relevant experience.