链上衍生品（机构级） — dYdX, Squeeth, Power Perpetuals

日期: 2026-06-17 方向: 机构DeFi / RWA 阶段: Phase 1 - 机构DeFi与桥接系统设计 (Day 43-56) 标签: #衍生品 #Perpetuals #dYdX #Squeeth #机构架构

---

今日目标

---

一、Perp市场背景：为什么是衍生品最大的链上市场

1.1 Perp占据链上衍生品80%+

Perp主导的原因：

1. 24/7市场：传统期货有结算日，Perp永不到期
2. 杠杆友好：链上Perp提供10-100x杠杆
3. Funding Rate自动化：通过资金费率维持价格锚定，不需要交割

1.2 机构关心Perp的什么？

1. 对冲(Hedging)：

• 持有现货BTC的机构通过做空Perp对冲价格风险
• 链上Perp的Cross-Margin让对冲更高效

2. 套利(Arbitrage)：

• CEX-DEX价差套利（如Binance Perp vs dYdX Perp）
• Funding Rate套利（持有现货+空Perp，赚Funding）

3. 杠杆敞口：

• 不持有现货，用Perp获得敞口
• 资本效率高于现货+借贷组合

4. 复杂策略：

• Basis Trade（现货+Perp组合）
• Calendar Spread（不同期限Perp组合，但Perp无期限）

---

二、Perpetual Futures核心机制

2.1 三大核心组件

┌──────────────────────────────────────────┐
│  1. Mark Price (用于Margin/Liquidation)   │
│     - Index Price (现货均价)              │
│     - Funding Rate (动态调整)             │
├──────────────────────────────────────────┤
│  2. Funding Rate (维持价格锚定)           │
│     - 多头付空头 (Long pays Short) when:  │
│       Mark Price > Index Price            │
│     - 周期: 每8小时 (传统CEX) / 1h (dYdX) │
├──────────────────────────────────────────┤
│  3. Liquidation Engine                    │
│     - Maintenance Margin Ratio (MMR)      │
│     - 触发清算: Equity/Position < MMR     │
│     - 部分清算 vs 全部清算                 │
└──────────────────────────────────────────┘

2.2 Funding Rate公式

Funding Rate = max(min(P, +clamp), -clamp) + Interest Component

P = Premium = (Mark - Index) / Index
clamp = 0.05% per 8h period (一般)
Interest = (LongBorrowRate - ShortBorrowRate) / 3 (每8h)

示例（BTC Perp）：

• Index Price = $60,000
• Mark Price = $60,300
• Premium = 0.5% per 8h = 1.5% per day
• Annualized = 547.5%
• 多头每8h付出0.5% × 头寸价值给空头

经济意义：高Funding Rate = 多头过热，激励空头入场把价格拉回Index。

2.3 Margin系统

Initial Margin (IM)：开仓所需最低保证金，通常10x杠杆 = 10% IM Maintenance Margin (MM)：维持仓位的最低保证金，通常5% Liquidation Threshold：Equity / Position Value < MM 时触发

Cross-Margin vs Isolated-Margin：

• Isolated：每个仓位独立Margin，损失上限是该仓位IM
• Cross：所有仓位共享Margin池，资本效率高但风险传染

机构通常用Cross-Margin（资本效率），但可能Isolated单独大额仓位。

---

三、链上Perp协议对比

3.1 dYdX V4 (Cosmos App-Chain)

架构：从StarkEx (V3) 迁移到Cosmos独立App-Chain (V4)

• 共识：Cosmos Tendermint, ~1秒block
• Order Book：Off-chain Order Book + On-chain Settlement
• TPS：~2000
• TVL/日交易：$2B+ daily volume (2024)

机构友好特性：

• API-driven（类似传统交易所）
• Sub-account支持（机构可以隔离不同策略）
• Cross-margin
• 真正的Limit Order Book（不是AMM）

3.2 Hyperliquid

架构：自建L1，专为Perp优化

• 共识：HyperBFT，~0.2秒block
• TPS：100,000+
• 2024年起飞：从$10M到$5B+ daily volume

机构友好：

• 高性能（接近CEX）
• 完整Order Book
• HLP（Hyperliquidity Provider）做市机制创新

3.3 GMX (V1/V2)

架构：基于Arbitrum，与dYdX根本不同

• 机制：GLP/GM作为流动性池
• 价格：Chainlink Oracle，无order book
• 优点：零滑点、深度好
• 缺点：LP承担trader对手方风险

机构态度：GMX的Pool模式让风险敞口不透明，机构更喜欢Order Book。

3.4 Drift Protocol (Solana)

架构：Solana，混合AMM+Order Book

• 创新：vAMM (virtual AMM) + JIT Liquidity
• TPS：受Solana限制，~50K
• 机构应用：Sub-account, Cross-Margin, API access

---

四、Power Perpetuals (Squeeth) 深度

4.1 概念创新

传统Perp追踪价格P（线性）。Power Perpetuals追踪P^n（非线性）。

• Squeeth (Squared Eth)：追踪 ETH^2
• 意义：提供Convexity，类似期权的Gamma

4.2 Opyn Squeeth (V1) - 已下线

机制：

• 1 Squeeth = ETH^2 / Normalization Factor
• Long Squeeth = 类似ATM Call永续期权
• Short Squeeth = 类似ATM Put永续期权（卖方）

Funding机制：

• Long Squeeth付Funding给Short
• Funding率 = ETH波动率^2 × time_decay
• 经济上等价于 "为Convexity支付Vega"

机构应用：

• 不需要to-the-moon options（避免time decay）
• 持续做空Vega（卖Squeeth）作为收益策略
• 现货+Squeeth组合实现复杂Greeks敞口

4.3 为什么V1下线（2024年）

• 流动性不足（日交易量$5M peak）
• 用户教育门槛高
• Squeeth的risk profile复杂，机构需要专门风控
• Opyn团队转向其他产品（Stack）

教训：Power Perpetuals是金融创新但机构采用慢——他们更习惯标准化产品（Perp, Options）。

---

五、机构级Perp架构详细设计

5.1 模块图

┌─────────────────────────────────────────────────────┐
│               Trader Interface                       │
│  - Web UI (Retail) / API (Institutions)             │
│  - REST/WebSocket for Order Management              │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────┐
│             Order Management System                  │
│  - Sub-account Management                            │
│  - Order Validation (Risk Limits, Position Limits)   │
│  - Routing                                           │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────┐
│             Matching Engine (Off-chain)              │
│  - Price-Time Priority                               │
│  - Order Book                                        │
│  - 100K+ orders/sec capacity                         │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────┐
│        Settlement Layer (On-chain)                   │
│  - Trade Settlement Smart Contract                   │
│  - Position Tracking                                 │
│  - Margin Accounting                                 │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────┐
│        Risk Engine (Hybrid)                          │
│  - Real-time Margin Monitoring                       │
│  - Funding Rate Calculator                           │
│  - Liquidation Engine                                │
│  - Insurance Fund                                    │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────┴────────────────────────────────┐
│        Oracle Layer                                  │
│  - Spot Price (multiple sources)                     │
│  - Funding Index                                     │
│  - Volatility Index                                  │
└─────────────────────────────────────────────────────┘

5.2 核心合约接口

interface IInstitutionalPerp {
    struct Position {
        address trader;
        bytes32 market;       // e.g., "BTC-PERP"
        int256 size;          // Positive=Long, Negative=Short
        uint256 entryPrice;
        uint256 margin;
        uint256 lastFundingPaid;
        uint64 openTime;
    }
    
    struct MarketParams {
        uint16 initialMarginBPS;     // 1000 = 10% (10x leverage)
        uint16 maintMarginBPS;       // 500 = 5%
        uint16 liquidationFeeBPS;    // 50 = 0.5%
        uint64 maxFundingRateBPS;    // 100 = 1% per period
        uint8 fundingPeriodHours;    // 8 = 每8h
        uint256 maxPositionSize;     // 单仓位上限
        uint256 maxOpenInterest;     // 总持仓上限
    }
    
    // 开仓
    function openPosition(
        bytes32 market,
        int256 size,
        uint256 marginAmount,
        uint256 limitPrice,
        bool isLong
    ) external returns (uint256 positionId);
    
    // 平仓（部分或全部）
    function closePosition(uint256 positionId, uint256 sizeToClose) external returns (int256 pnl);
    
    // 增减Margin
    function addMargin(uint256 positionId, uint256 amount) external;
    function removeMargin(uint256 positionId, uint256 amount) external;
    
    // Funding结算（任何人可触发）
    function settleFunding(bytes32 market) external;
    
    // 清算
    function liquidate(uint256 positionId) external;
    
    // 查询
    function getPosition(uint256 positionId) external view returns (Position memory);
    function getMarginRatio(uint256 positionId) external view returns (uint256);
    function isLiquidatable(uint256 positionId) external view returns (bool);
}

// 子账户管理（机构友好）
interface ISubAccountManager {
    function createSubAccount(string calldata name) external returns (bytes32 subAccountId);
    function depositToSubAccount(bytes32 subAccountId, uint256 amount) external;
    function withdrawFromSubAccount(bytes32 subAccountId, uint256 amount) external;
    function transferBetweenSubAccounts(bytes32 from, bytes32 to, uint256 amount) external;
    
    // 风控限额
    function setSubAccountLimit(bytes32 subAccountId, uint256 maxNotional) external;
    function setSubAccountWhitelist(bytes32 subAccountId, address[] calldata allowedTraders) external;
}

5.3 Margin引擎设计

interface IMarginEngine {
    /// @notice 计算账户总Equity
    function getEquity(address account) external view returns (uint256);
    
    /// @notice 计算账户总Position Value
    function getPositionValue(address account) external view returns (uint256);
    
    /// @notice 计算Margin Ratio (Equity / PositionValue)
    function getAccountMarginRatio(address account) external view returns (uint256);
    
    /// @notice 检查是否可清算
    function isAccountLiquidatable(address account) external view returns (bool);
    
    /// @notice 计算开仓所需Margin
    function calculateRequiredMargin(
        bytes32 market,
        int256 size,
        uint256 price
    ) external view returns (uint256);
    
    /// @notice Cross-Margin: 多仓位共享Margin Pool
    function getCrossMarginRatio(address account) external view returns (uint256);
}

5.4 Funding Rate计算

contract FundingRateOracle {
    function calculateFundingRate(
        bytes32 market,
        uint256 markPrice,
        uint256 indexPrice
    ) public view returns (int256 fundingRate) {
        // Premium部分
        int256 premium = int256(markPrice) - int256(indexPrice);
        int256 premiumRate = (premium * 1e6) / int256(indexPrice); // BPS * 10000
        
        // Clamp到 ±0.5%
        int256 maxRate = 5000; // 0.5% in BPS*10000
        if (premiumRate > maxRate) premiumRate = maxRate;
        if (premiumRate < -maxRate) premiumRate = -maxRate;
        
        // Interest Rate Component (假设固定0.01%)
        int256 interestRate = 100; // 0.01% in BPS*10000
        
        fundingRate = premiumRate + interestRate;
    }
    
    function settleFunding(address account, bytes32 market) external {
        Position memory pos = positions[account][market];
        int256 rate = calculateFundingRate(market, getMarkPrice(market), getIndexPrice(market));
        int256 fundingPayment = (pos.size * int256(getMarkPrice(market)) * rate) / 1e10;
        
        if (fundingPayment > 0) {
            // Long pays
            _deductMargin(account, uint256(fundingPayment));
            _addToInsuranceFund(uint256(fundingPayment));
        } else {
            // Short pays
            _addMargin(account, uint256(-fundingPayment));
        }
    }
}

5.5 清算流程序列图

sequenceDiagram
  participant Account as Trader Account
  participant Engine as Margin Engine
  participant Oracle as Price Oracle
  participant Liquidator as Liquidator Bot
  participant Insurance as Insurance Fund
  
  Note over Account,Oracle: 价格变动
  Oracle->>Engine: BTC price drop, $60K → $58K
  Engine->>Engine: 重新计算所有long position margin ratio
  
  loop 每个long position
    Engine->>Engine: ratio = equity / position_value
    alt ratio < maintenance
      Engine->>Engine: mark as liquidatable
    end
  end
  
  Note over Liquidator,Insurance: Liquidator检测
  Liquidator->>Engine: getLiquidatablePositions()
  Engine-->>Liquidator: [pos_id_1, pos_id_2, ...]
  
  Liquidator->>Engine: liquidate(pos_id_1)
  Engine->>Engine: 计算liquidation amount
  alt 仓位足够大，部分清算
    Engine->>Account: 关闭25% position size
    Engine->>Liquidator: 转0.5% as liquidation fee
  else 全部清算（小仓位）
    Engine->>Account: 关闭100% position
    Engine->>Liquidator: 转1% as liquidation fee
  end
  
  alt 残余亏损 > 剩余Margin (Underwater)
    Engine->>Insurance: 提取赔付
    Insurance->>Account: 平掉剩余仓位
  end
  
  Engine->>Account: 更新Position State
  Engine->>Engine: emit LiquidationEvent

---

六、设计决策与权衡

6.1 Order Book vs AMM？

机构选择Order Book（dYdX/Hyperliquid）：

• 价格发现更精准
• 可放Limit Order（必备）
• 类似CEX体验
• 滑点可控

为什么GMX在散户成功：

• 零滑点（对小单友好）
• 深度好
• LP机制简单

机构不喜欢AMM Perp：

• 价格依赖Oracle，Oracle操纵风险
• 大单滑点不可控（GMX有限制但机构嫌麻烦）
• LP角色复杂

6.2 Off-chain Match + On-chain Settle vs Full On-chain？

机构选Off-chain Match：

• 性能（10K+ TPS）
• API兼容（机构有现成的SOR/EMS）
• 成本（链上Gas高）

Full On-chain（Hyperliquid）：

• 真透明
• 抗审查
• 但需要超高性能L1（Hyperliquid自建）

dYdX的演进：V3是StarkEx (Off-chain Match + ZK Settlement)，V4是自建App-Chain (Full On-chain)。

6.3 Cross-Margin vs Isolated-Margin？

机构通常Cross-Margin per Sub-account, Isolated between Sub-accounts：

• 同一策略的多仓位用Cross（资本效率）
• 不同策略隔离（风险隔离）
• 例如：BTC Hedge Fund的"Basis Trade"账户和"Trend Following"账户隔离

6.4 Insurance Fund来源？

Funding Rate Skew：当多空不平衡时，Funding超出"实际需要"的部分进入Insurance Fund。 Liquidation Penalty：清算手续费的一部分进入Insurance Fund。 初始资金：协议team捐赠。

为什么需要：清算时如果损失大于剩余Margin（Underwater Position），Insurance Fund兜底。否则只能ADL（Auto-Deleveraging），强制盈利方平仓。

---

七、风险与攻击面

7.1 Oracle操纵

威胁：攻击者操纵Index Price，导致大量清算或Funding偏离。 缓解：

• 多Oracle源（Chainlink, Pyth, Median）
• TWAP（5分钟）
• 异常检测（>5%突变Pause）
• 链下Oracle作为back stop

7.2 ADL (Auto-Deleveraging) 风险

威胁：Insurance Fund耗尽，只能强制平掉盈利交易者的仓位。 缓解：

• Insurance Fund充足（$50M+）
• ADL优先级排序（高杠杆+高盈利的优先被ADL）
• 透明的ADL规则（用户可预期）
• 机构客户合同中明确ADL条款

7.3 Front-Running by Sequencer

威胁：链的Sequencer看到大单，前置交易获利。 缓解：

• 加密Mempool（Encrypted Mempool）
• Fair Sequencing Service
• dYdX V4使用Cosmos validator轮换，比单一Sequencer好

7.4 Cascading Liquidations

威胁：大额清算砸价格，触发更多清算（连锁）。 缓解：

• 分批清算（不在一个block清算大量）
• Liquidation Throttle（每block最大清算量）
• Circuit Breaker（极端波动暂停）

---

八、TradFi对照

核心差异：CME是Central Counterparty (CCP)，承担信用风险；链上Perp是去中心化，由Smart Contract+Insurance Fund兜底。

---

九、关键速查

主要链上Perp协议对比（2024）

与CME对比

---

十、面试题（资深级）

Q1: 设计一个机构级Perp协议，需要在CEX之上提供什么差异化？

深度回答：

1. 真正的Self-Custody：机构资金不交给协议（不像Binance），用Smart Contract持有
2. Sub-account架构：支持几十个隔离子账户（Multi-strategy fund的需求）
3. API兼容：FIX协议、REST、WebSocket，与现有OMS/EMS无缝集成
4. 跨保证金灵活性：BTC/ETH/USDC都可作为Margin（CME只接受现金）
5. 24/7 + Funding透明：链上Funding公式可验证
6. 报表自动化：每笔交易事件可入ERP
7. 法律确定性：在合规司法（如新加坡MAS许可）注册
8. 风险参数可治理：机构客户能影响协议参数（DAO投票或Risk Committee）

Q2: 链上Perp的Insurance Fund vs CME的Default Fund，本质差异？

深度回答：

• CME Default Fund：分层(Waterfall)：
  1. Defaulter的Margin
  2. Defaulter的Performance Bond
  3. CME自有资金（"Skin in the Game"）
  4. Member Mutualization（其他Members分摊）
• 链上Insurance Fund：通常单层：
  1. Defaulter的Margin
  2. Insurance Fund
  3. ADL（Auto-Deleveraging）
• 关键差异：CME有Members分摊（明确的资本承诺），链上没有Members概念，Insurance Fund有限耗尽就ADL
• 改进方向：链上协议可引入"Backstop LP"（如GMX的GLP），由LP承担最后兜底，类比CME Members

Q3: Hyperliquid的HLP机制如何让机构愿意做市？

深度回答：

• HLP (Hyperliquidity Provider)：协议自有的做市资金池
• 机构参与方式：
  1. 用户存入USDC到HLP
  2. HLP由协议算法做市（提供流动性）
  3. 收益来自Funding Rate + 做市价差
• 优势：
  1. Passive流动性提供（不需要自己写做市策略）
  2. 比传统LP更主动（动态调整）
  3. 透明（链上可查PnL）
• 风险：
  1. 极端行情可能亏损（2024 Q4 Hyperliquid HLP有过-15%回撤）
  2. 做市策略不公开（信任假设）
• 机构态度：作为Beta暴露的工具不错，但不会作为核心策略

Q4: 为什么CME至今没做BTC Perp，而是只做BTC Futures (有到期)？

深度回答：

• 监管原因：CFTC对Perpetual产品有顾虑（无法到期 = 无法close out for risk management）
• 市场结构：CME Members（大投行）对Perp接受度低，习惯Calendar Spread
• Funding机制不熟悉：CME的清算所对Funding Rate的法律性质不清楚（是利息？还是手续费？税务处理）
• 空间已被Crypto-Native占据：dYdX/Hyperliquid/Binance已抢先，CME进入market share低
• 未来：CFTC如果批准Perp（理论上可以），CME可能进入。Coinbase已申请，是先行试验

Q5: 机构如何在链上Perp上构建Basis Trade（现货+空Perp）？

深度回答： 策略：买入现货BTC，卖空等量BTC Perp，赚Funding Rate 链上执行：

1. 现货：Binance/Coinbase购买BTC，存入Custodian
2. 链上：将BTC作为Collateral存入dYdX/Hyperliquid
3. 开空Perp（1x，等额）
4. 收Funding（typically 5-15% APR） 风险：

• Mark Price vs Spot差异：Perp可能短时偏离Spot（清算风险）
• Custodian Mismatch：Spot在CEX，Perp在链上，跨平台对账
• Funding Rate反转：Bear市Funding可能为负（多头收Funding，空头付） 优化：
• 用Tokenized BTC（WBTC）作为Margin，Spot和Perp都在链上（资本效率）
• 用Cross-Margin多个市场分散
• 风控：Margin Ratio设置在保守水平（2x而非10x）

---

十一、明日预告

Day 48: Restaking机构应用 — EigenLayer。重点研究EigenLayer机构化路径、AVS（Actively Validated Service）的安全模型、Restaking对机构托管的挑战、与传统再保险（Reinsurance）的对比。