# Dawn Labs

**Your Solana Yield Partner**

Dawn Labs is a **Solana operations partner** for exchanges, DATs (Digital Asset Treasury), lending protocols, traditional finance firms, and high-net-worth individuals. We combine deep validator infrastructure expertise with DeFi yield optimization to deliver institutional-grade returns.

## Services

### Yield Strategies

| Service                                                  | Description                                                                       | Status         |
| -------------------------------------------------------- | --------------------------------------------------------------------------------- | -------------- |
| [**SOL Staking**](/about-dawn-labs/services#sol-staking) | Native Staking, LST Staking, Multiple Staking (0% commission + kickback for VIPs) | Live           |
| [**Dawn Vault (USDC)**](/dawn-vault/overview)            | Automated yield vault: Kamino Multiply + lending + delta-neutral (9-16%+ APY)     | Phase 1 Active |

### Consulting

| Service                                                            | Description                                                         | Status    |
| ------------------------------------------------------------------ | ------------------------------------------------------------------- | --------- |
| [**Validator Growth**](/about-dawn-labs/services#validator-growth) | Onboarding, training, and growth strategy for enterprise validators | Available |

## Why Dawn Labs?

* **Validator-Native** — Our yield strategies start at the infrastructure layer, giving us structural alpha unavailable to pure DeFi aggregators
* **$150M+ Assets Managed** — Proven track record with institutional-scale operations
* **APAC-Based** — Bridging the Japanese market to the Solana ecosystem
* **Compliance-Ready** — Navigate regulation and audit requirements together

## Company Profile

|                  |                                                   |
| ---------------- | ------------------------------------------------- |
| **Legal Entity** | CHAIN TEC LAB - FZCO                              |
| **Location**     | IFZA Business Park, DDP, Dubai Silicon Oasis, UAE |
| **Website**      | [dawnlabs.tech](https://dawnlabs.tech)            |
| **X (Twitter)**  | [@dawnlabs00](https://x.com/dawnlabs00)           |

## Team

| Name               | Role | Contact                                         |
| ------------------ | ---- | ----------------------------------------------- |
| **Yutaro Nagumo**  | CEO  | [@SouthCloud0703](https://x.com/SouthCloud0703) |
| **Toshiyuki Tega** | CTO  | [@SoftgateJa](https://x.com/SoftgateJa)         |

***

> **Disclaimer**: Dawn Vault is an experimental DeFi product. Past performance does not guarantee future results. Please review our [Risk & Security](/dawn-vault/risk-and-security) and [Disclaimer](/legal/disclaimer) before depositing.


# Services

Dawn Labs provides yield strategies and consulting services built on our Solana validator infrastructure.

***

## Yield Strategies

### SOL Staking

Direct delegation to Dawn Labs' validator with multiple staking options.

| Option               | Description                                                                                                                                                                                                                |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Native Staking**   | <p>Direct delegation with <strong>0% commission</strong> — the simplest way to earn staking rewards on Solana<br>- <a href="/pages/D0jxmtLsxGeafVve6f76">Validator Info</a></p>                                            |
| **LST Staking**      | <p>Liquid staking through <strong>dawnSOL</strong> on Sanctum with <strong>0% commission</strong> — use across DeFi while earning staking rewards<br>- <a href="https://app.sanctum.so/stake/dawnSOL">dawnSOL Swap</a></p> |
| **Multiple Staking** | <p>Coming soon — leveraged looping for amplified yield<br>- <a href="/pages/CXTLAWsAm2EFqvBveV7S">Jupiter Native Stake Multiple</a><br>- <a href="/pages/x1EtDRcisJb306zvOxXC">Kamino LST Multiple</a></p>                 |

**VIP Kickback**: Exclusive kickback plans for large-scale stakers. [Contact us](/about-dawn-labs/contact) for details.

{% hint style="success" %}
**Status: Live**
{% endhint %}

***

### Dawn Vault (USDC)

Institutional-grade yield vault on Solana. Automated strategies combining Kamino Multiply, lending aggregation, and delta-neutral arbitrage, powered by our validator infrastructure.

* Deposit USDC, earn 9-16%+ APY through Kamino Multiply + lending + delta-neutral strategies
* Non-custodial, on-chain smart contract design
* Full yield transparency and proof-based reporting

{% hint style="success" %}
**Status: Phase 1 Active** — See [Dawn Vault Documentation](/dawn-vault/overview) for details.
{% endhint %}

***

## Consulting

### Validator Growth

Onboarding, training, and growth strategy for enterprise validators.

#### What We Offer

* **Validator Setup & Training** — Onboarding and training for enterprise validators entering the Solana network
* **Growth Strategy** — Stake pool delegation acquisition, performance optimization, and ongoing advisory based on the latest Solana ecosystem developments
* **Business Development** — Strategic support for Solana-based business opportunities beyond validator operations

#### Who It's For

* Japanese enterprises entering the Solana ecosystem
* Solana startups seeking validator infrastructure expertise
* Institutional partners requiring compliance-ready operations

{% hint style="success" %}
**Status: Available** — [Contact us](/about-dawn-labs/contact) to discuss your needs.
{% endhint %}


# Validator

Dawn Labs operates a top-performing Solana validator, providing the foundation for all our yield strategies.

## Validator Info

|                    |                                                |
| ------------------ | ---------------------------------------------- |
| **Identity**       | `4k6wgP5WPBKQpsFGtzuXNrjcTE2fKWLj17nDvFeG5zSF` |
| **Vote Account**   | `8zuMRTXThoPTTPLLvaiKiJshLLCqGMt9BdRjjCL19xBc` |
| **Commission**     | 0%                                             |
| **MEV Commission** | 0%                                             |
| **Uptime**         | 99.9%+                                         |

## Explorer Links

* [JPool](https://app.jpool.one/validators/8zuMRTXThoPTTPLLvaiKiJshLLCqGMt9BdRjjCL19xBc?epoch=943)
* [Rated](https://explorer.rated.network/v/8zuMRTXThoPTTPLLvaiKiJshLLCqGMt9BdRjjCL19xBc?network=solana\&timeWindow=30d)
* [Validators.app](https://www.validators.app/validators/4k6wgP5WPBKQpsFGtzuXNrjcTE2fKWLj17nDvFeG5zSF?locale=en\&network=mainnet)

## Infrastructure

* Top 10 performing validators on Solana
* Multi-level security including HSM key management, sentry nodes, and DDoS protection
* Multi-region redundancy with continuous monitoring


# Links & Contacts

## Contact

* **Email**: <info@dawnlabs.tech>
* **Telegram**: [@SouthCloud0703](https://t.me/SouthCloud0703)
* **X (Twitter)**: [@dawnlabs00](https://x.com/dawnlabs00)
* **Website**: [dawnlabs.tech](https://dawnlabs.tech)
* **Contact Form**: [dawnlabs.tech/#contact](https://dawnlabs.tech/#contact)

## GitHub

* **Organization**: [github.com/DawnLabsTech](https://github.com/DawnLabsTech)
* **Vault (Bot / Backtest / Dashboard)**: [github.com/DawnLabsTech/vault](https://github.com/DawnLabsTech/vault)

## Design Kit

Logos, colors, and brand assets for press and partners.

* **Download**: [Google Drive](https://drive.google.com/drive/folders/1nCs0MvDhgehNQSdmrWdH3_uI-Q3kTbj5)

## VIP Kickback Program

Fee kickback program for VIP depositors.

* **Apply**: [Google Form](https://forms.gle/Qx6hg59sM5Jea4Pm7)


# Jupiter Native Stake Multiple

A looping strategy that uses Jupiter Lend to borrow SOL against natively staked SOL with the Dawn Labs validator, then restakes the borrowed SOL to amplify staking yield.

## How to Use

### 1. Native Stake SOL with the DawnLabs Validator

Stake SOL to the Dawn Labs validator using native staking from your wallet:

* **Phantom**: [Stake SOL in Phantom with native staking](https://help.phantom.com/hc/en-us/articles/4406374138771-Stake-SOL-in-Phantom-with-native-staking)
* **Solflare**: [Native Solana (SOL) Staking on Solflare: A Step-by-Step Guide](https://help.solflare.com/en/articles/9264008-native-solana-sol-staking-on-solflare-a-step-by-step-guide)
* **Ledger**: [Stake SOL with Ledger](https://www.ledger.com/staking/ledger-node/solana)

### 2. Wait for Your Stake to Become Active

Native stake activation takes 1 epoch (\~2–3 days). Wait until your stake status shows **Active** before proceeding.

### 3. Deposit nsDawn as Collateral on Jupiter Lend

Once your stake is active, it is tokenized as **nsDawn** (an nsToken representing your native stake position). Go to [Jupiter Lend](https://jup.ag/lend/borrow/73) and deposit the desired amount of nsDawn as collateral.

### 4. Borrow SOL Against Your Collateral

On Jupiter Lend, borrow SOL using your deposited nsDawn as collateral.

### 5. Restake Borrowed SOL and Repeat

Return to step 1 and native stake the borrowed SOL with the Dawn Labs validator again. By repeating this loop, you can achieve up to **\~7x leverage** on your staking yield.

Staking rewards continue to accrue even after the staked SOL is used as collateral, since the stake state is maintained throughout the borrowing structure.

## Features

|                    |                                                     |
| ------------------ | --------------------------------------------------- |
| **Collateral**     | Natively staked SOL (nsToken)                       |
| **Borrow Asset**   | SOL                                                 |
| **Max Leverage**   | \~7x                                                |
| **LST Price Risk** | None (native stake, not LST)                        |
| **Operation**      | Manual (Jupiter is developing automated management) |

* No LST price deviation risk since native stake is used directly
* Collateral and borrowed asset are both SOL — no USD price-driven liquidation risk
* Borrow rate follows a utilization-based variable rate model, dampening sudden rate spikes

## Risks

### Borrow Rate Volatility

**Risk**: SOL borrow rates fluctuate with market conditions. If the borrow rate exceeds staking yield, returns decrease. Prolonged periods could push the collateral ratio below the liquidation threshold, resulting in principal loss.

**Mitigation**: Jupiter's SOL borrow market has deep liquidity and rates are generally stable. Since this is a SOL-to-SOL borrow structure, liquidation can only occur if borrow rates significantly exceed staking yield for an extended period — a scenario that has never occurred historically.

### Smart Contract Risk

**Risk**: Vulnerabilities may exist in the DeFi protocol's smart contracts.

**Mitigation**: Jupiter has completed multiple independent security audits and is one of the largest protocols in the Solana ecosystem (integrated with 500+ projects) with a long operational track record. A bug bounty program is continuously maintained.

**Audit History** ([full list](https://dev.jup.ag/resources/audits)):

* [OtterSec](https://dev.jup.ag/resources/audits) — 4 audits (latest: November 2025)
* [Offside Labs](https://dev.jup.ag/resources/audits) — v6 audit (October 2025, April 2024), Oracle & Flashloan audit (October 2025)
* [Zenith](https://dev.jup.ag/resources/audits) — June–July 2025, all findings resolved
* [Sec3](https://dev.jup.ag/resources/audits) — v3 audit
* [Code4rena](https://code4rena.com/audits/2026-02-jupiter-lend) — Competitive audit contest ($107K scope, February–March 2026)

### Liquidity Risk

**Risk**: Unstaking native SOL requires a cooldown period (\~2–3 days). Immediate liquidity needs may not be met.

**Mitigation**: Solana's cooldown period is short compared to other chains (Ethereum: several days to weeks).

### Manual Management Risk

**Risk**: Looping currently requires manual operations, adding position management overhead.

**Mitigation**: Dawn Labs provides support for position setup and management. Jupiter has planned development of automated looping management features, which will significantly reduce operational burden.


# Kamino LST Multiple

> **This strategy is currently under preparation and not yet available.** Support will be added once dawnSOL is listed on Kamino. Please check back later.

A looping strategy that uses Kamino (K-Lend) and Sanctum to leverage Dawn Labs' LST (dawnSOL) for amplified staking yield. Kamino's Multiply feature enables one-click leveraged position construction.

## How It Works

1. Stake SOL into dawnSOL (via Sanctum)
2. Deposit dawnSOL as collateral on Kamino
3. Borrow SOL, convert back to dawnSOL, and deposit again (Looping)
4. Multiply feature enables up to \~7x leverage

Kamino's Multiply feature uses Flash Loans to build the entire leveraged position in a single transaction:

1. Flash Loan borrows SOL without collateral (fee: 0.001%)
2. Convert borrowed SOL to dawnSOL (via Sanctum)
3. Deposit dawnSOL as collateral on K-Lend
4. Borrow SOL against the new collateral
5. Repay Flash Loan with borrowed SOL — position complete

The entire process executes with one click on the UI.

## Features

|                  |                             |
| ---------------- | --------------------------- |
| **Collateral**   | dawnSOL (LST)               |
| **Borrow Asset** | SOL                         |
| **Max Leverage** | \~10x (with eMode)          |
| **Operation**    | One-click (Kamino Multiply) |

* One-click leveraged position construction via Kamino Multiply
* Maintain liquidity as an LST while earning amplified yield
* Built-in risk management features (auto-deleverage, etc.)

### eMode (Elevation Mode)

eMode raises the LTV cap for correlated asset pairs (SOL and LST), enabling higher leverage.

| Mode     | LTV Cap | Max Leverage |
| -------- | ------- | ------------ |
| Standard | 75%     | \~4x         |
| eMode    | 90%     | \~10x        |

Since SOL and LST are fundamentally the same asset with correlated pricing, eMode application is justified.

## Risks

### Borrow Rate Volatility

**Risk**: SOL borrow rates fluctuate with market conditions. If the borrow rate exceeds staking yield, returns decrease. Prolonged periods could push the collateral ratio below the liquidation threshold, resulting in principal loss.

**Mitigation**: Kamino's SOL borrow market has deep liquidity and rates are generally stable. Since this is a SOL-to-SOL borrow structure, liquidation can only occur if borrow rates significantly exceed staking yield for an extended period — a scenario that has never occurred historically.

### Smart Contract Risk

**Risk**: Vulnerabilities may exist in the DeFi protocol's smart contracts.

**Mitigation**: Kamino has completed multiple independent security audits and is a major protocol in the Solana ecosystem with a long operational track record. A bug bounty program is continuously maintained.

**Audit History (K-Lend)** ([full list](https://github.com/Kamino-Finance/audits)):

* [Certora](https://github.com/Kamino-Finance/audits/blob/master/kamino_lend_certora.pdf) — Formal verification proving mathematical safety
* OtterSec — Solana-specialized security audit
* [Sec3](https://github.com/Kamino-Finance/audits/blob/master/kamino_klend_sec3.pdf) — Automated Solana program security analysis
* Ackee Blockchain — Fuzz testing security verification
* [OSec](https://github.com/Kamino-Finance/audits/blob/master/kamino_lend_osec_formal_verification.pdf) — Formal verification
* RX Auditors — Security audit

**Bug Bounty**: Up to [$1.5M reward program on Immunefi](https://immunefi.com/bug-bounty/kamino)

### LST Depeg Risk

**Risk**: If dawnSOL's market price deviates from its theoretical price (depeg), collateral value drops and liquidation risk increases.

**Mitigation**: dawnSOL is issued through Sanctum and can be redeemed for SOL at theoretical price at any time. Sanctum is one of Solana's largest LST infrastructure providers with a stable operational track record. Kamino's auto-deleverage feature further mitigates risk during collateral ratio deterioration.

## Risk Management

Kamino provides multiple built-in risk management features:

* **Auto-Deleverage**: Automatically unwinds collateral and debt when LTV deteriorates, maintaining safe levels without manual intervention
* **Partial Liquidation**: When LTV exceeds the threshold, only \~2% of collateral is liquidated — unlike full liquidation in typical protocols, minimizing impact on principal
* **KRAF (Kamino Risk Assessment Framework)**: Comprehensive risk assessment framework performing volatility measurement, stress testing, and real-time monitoring


# Overview

Dawn Vault is a **validator-native yield vault** on Solana, built by Dawn Labs — an active Solana validator operator.

## Concept

Most DeFi yield vaults sit on top of protocols as users. Dawn Vault starts at the infrastructure layer and extends into DeFi:

```
Traditional Vault:    DeFi Protocols → Yield
Dawn Vault:           Validator Infrastructure → DeFi Protocols → Yield
```

Validator revenue provides structural alpha unavailable to pure DeFi aggregators:

* **dawnSOL staking rewards** — The long leg of the delta-neutral strategy earns \~7% staking rewards on top of funding rate income
* **Yield Smoothing Reserve** — Validator commission-derived reserve stabilizes APY during unfavorable market conditions (Phase 2)
* **Skin in the Game** — Dawn Labs' own capital deployed under the same conditions as depositors

## Two-Layer Architecture

Every Dawn Vault follows a **Base Layer + Alpha Layer** design:

```
Vault (Single Entry Point)
  ├── Base Layer   — Always-on, stable yield (Multiply / Lending / Staking)
  └── Alpha Layer  — Conditional, enhanced yield (activated when profitable)
```

The Base Layer ensures depositors always earn yield. The Alpha Layer activates only when market conditions justify the extra complexity.

## Repository Scope

This open-source repository currently contains the **off-chain operator stack** for Dawn Vault:

* Manager bot and risk controls
* AI support services
* Monitoring dashboard
* Backtest tooling

The on-chain vault program, PDA custody layer, adapter programs, deployed addresses, and multisig governance artifacts are **not included in this repository**. Any claim about on-chain custody or admin separation should therefore be read as product architecture, not as something this repo alone can verify.

## Vault Lineup

|                 | USDC Vault                                          | SOL Vault                | BTC Vault                                         |
| --------------- | --------------------------------------------------- | ------------------------ | ------------------------------------------------- |
| **Base Layer**  | Kamino Multiply (primary) + USDC Lending (overflow) | Validator Staking (6-7%) | cbBTC Lending (1-3%)                              |
| **Alpha Layer** | SOL Delta-Neutral (conditional)                     | LST Loop (10-20%)        | cbBTC collateral → USDC borrow → SOL DN (3.5-11%) |
| **Phase**       | **Phase 1 (Active)**                                | Phase 2                  | Phase 3                                           |

## Why Dawn Vault?

|                         | Dawn Vault                           | Traditional Aggregators | Manual Strategies |
| ----------------------- | ------------------------------------ | ----------------------- | ----------------- |
| **Yield Source**        | Validator infra + DeFi               | DeFi only               | DeFi only         |
| **Risk Management**     | Automated with backtested parameters | Varies                  | Manual            |
| **Transparency**        | Full yield decomposition             | Limited                 | N/A               |
| **Capital Efficiency**  | LST-enhanced (dawnSOL)               | Standard                | Standard          |
| **Downside Protection** | Yield Smoothing Reserve              | None                    | None              |

**Japan Gateway** — First Japanese-language Vault on Solana. Existing validator delegator base serves as initial TVL source, with full Japanese UI, reporting, and support.

## System Architecture

```mermaid
graph TB
    subgraph "User Layer"
        U[Depositor] -->|Deposit USDC| UI[Web App]
    end

    subgraph "On-Chain Layer"
        UI -->|Connect Wallet| VP[Vault Program<br>Deposit / Withdraw / LP / Fees]
        VP --> PDA[PDA Authority<br>Asset Custody / LP Mint]
        VP --> AP[Adapter Programs<br>Protocol Connectors]
    end

    subgraph "Strategy Execution"
        MB[Manager Bot] -->|Rebalance / Hedge| VP
        MB -->|Monitor| RM[Risk Manager<br>Circuit Breaker / Anomaly Detection]
        MB -->|Execute| CEX[Perp Integration<br>Binance / Bulk Trade]
        MB -->|Scan| MS[Market Scanner<br>Pool APY Comparison]
    end

    subgraph "Risk Scoring"
        MRS[Multiply Risk Scorer<br>4 Dimensions] --> MB
        LRS[Lending Risk Scorer<br>5 Dimensions] --> MB
    end

    subgraph "DeFi Protocols"
        AP --> KM[Kamino Multiply<br>ONyc/USDC, USDG/PYUSD]
        AP --> KL[Kamino Lend]
        AP --> Jupiter[Jupiter Lend / Swap]
    end

    subgraph "Validator Infrastructure"
        VS[Dawn Validator] -->|Staking Rewards| dawnSOL[dawnSOL LST]
        VS -->|Commission| YSR[Yield Smoothing Reserve]
    end
```

### Core Components

| Component            | Description                                                                                                                              |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Vault Program**    | On-chain (Voltr SDK): deposits, withdrawals, LP token accounting, fee management, PDA custody                                            |
| **Adapter Programs** | CPI-gated connectors to Kamino (Multiply/Lending) and Jupiter (Lend/Swap). Whitelisted — only approved protocols can access vault assets |
| **Manager Bot**      | Off-chain strategy engine: dynamic allocation, market scanning, rebalancing, hedge management, risk monitoring                           |
| **Risk Scoring**     | Multiply Risk Scorer (4-dimension) + Lending Risk Scorer (5-dimension) — see [Risk & Security](/dawn-vault/risk-and-security)            |

### Security Model

* **Operator Stack in This Repo**: The code here covers monitoring, allocation logic, risk checks, AI support, and dashboard access control.
* **Planned / External Custody Layer**: PDA custody, adapter whitelisting, admin multisig, and locked-profit mechanics belong to the separate on-chain layer and must be verified from deployed program docs and audit material.
* **Production Access Control**: The dashboard and proxy can be protected with `FRONTEND_API_SECRET`, while the bot API requires `API_AUTH_TOKEN` and is intended to stay behind the frontend proxy on localhost.


# USDC Vault

**Status: Live (Phase 1)**

The USDC Vault is Dawn Vault's flagship product. Deposit USDC and earn optimized yield through Kamino Multiply, lending aggregation, and delta-neutral strategies — all managed automatically.

## Overview

| Parameter           | Value                                               |
| ------------------- | --------------------------------------------------- |
| **Deposit Asset**   | USDC                                                |
| **Target APY**      | 9-16% (up to 20% during high FR periods)            |
| **Base Layer**      | Kamino Multiply (primary) + USDC Lending (overflow) |
| **Alpha Layer**     | SOL Delta-Neutral (conditional)                     |
| **Rebalancing**     | Daily to weekly                                     |
| **Decision Metric** | Multiply spread + SOL Funding Rate                  |

## How It Works

```mermaid
graph LR
    D[Deposit USDC] --> V[USDC Vault]
    V --> BL[Base Layer<br>Kamino Multiply + Lending<br>9-16% APY]
    V --> AL[Alpha Layer<br>SOL Delta-Neutral<br>15-20% APY]
    BL --> KM[Kamino Multiply<br>ONyc/USDC ~16%<br>USDG/PYUSD ~9.5%]
    BL --> KL[Kamino Lend]
    BL --> JL[Jupiter Lend]
    AL --> SP[SOL Spot Buy<br>→ dawnSOL]
    AL --> SH[SOL-PERP Short<br>Binance / Bulk Trade]
```

***

## Base Layer — Kamino Multiply (Primary)

Leveraged stablecoin loops via Kamino to earn native collateral yield + borrow rewards.

### Mechanism

1. Deposit a yield-bearing stablecoin as collateral on Kamino
2. Borrow USDC against the collateral
3. Swap borrowed USDC back to collateral and re-deposit
4. Repeat to reach the target leverage multiple
5. Net yield = (Collateral native yield × leverage) − borrow cost

### Active Pools

| Pool                    | Market      | Effective APY  | Leverage | Notes                            |
| ----------------------- | ----------- | -------------- | -------- | -------------------------------- |
| **ONyc/USDC** (Primary) | RWA Market  | \~16% @ 2.5x   | 2.5x     | ONyc native yield via Onre       |
| **USDG/PYUSD** (Backup) | Main Market | \~9.5% @ 5.75x | 5.75x    | Fallback when ONyc/USDC degrades |

### Market Scanner & Pool Switching

The Market Scanner continuously monitors candidate pools and recommends switching only when:

* 24h moving-average APY advantage is large enough to repay estimated switch cost within the configured payback window (7 days)
* The destination candidate clears the live risk gate
* Minimum holding period (3 days) has elapsed

### Multiply Risk Scoring

The **Multiply Risk Scorer** evaluates each pool on **4 dimensions** as a separate risk axis. Risk does not reduce displayed APY — it **gates allocation**, trims oversized positions, and forces exits at explicit score thresholds.

| Dimension                 | Weight | What It Measures                                              |
| ------------------------- | ------ | ------------------------------------------------------------- |
| **Depeg Risk**            | 30%    | Peg deviation + 24h volatility + 7d tail risk                 |
| **Liquidation Proximity** | 30%    | Distance to liquidation at target leverage + stress scenarios |
| **Exit Liquidity**        | 20%    | Swap slippage on emergency exit (via Jupiter)                 |
| **Reserve Pressure**      | 20%    | Reserve utilization + capacity ratios + TVL safety checks     |

**Risk thresholds (live):**

| Score | Action                                                        |
| ----- | ------------------------------------------------------------- |
| < 75  | Normal operation                                              |
| ≥ 75  | Stop new deposits + trim position to dynamic `maxPositionCap` |
| ≥ 90  | Full exit / emergency deleverage                              |

Candidates with score ≥ 75 are excluded from switch targets.

### Deleverage Protection

Multi-stage health rate protection prevents liquidation:

| Health Rate  | Action                                   |
| ------------ | ---------------------------------------- |
| Target: 1.15 | Normal operation                         |
| < 1.10       | Soft deleverage — reduce 20% of position |
| < 1.05       | Emergency full deleverage                |

***

## Base Layer — Lending (Supplementary)

USDC lending on Kamino / Jupiter Lend (3-8%) absorbs capital that cannot be added to Multiply, and enforces diversification.

### Supported Protocols

| Protocol         | Rate Range | Notes                                    |
| ---------------- | ---------- | ---------------------------------------- |
| **Kamino Lend**  | 3-8%       | Established protocol with deep liquidity |
| **Jupiter Lend** | 3-8%       | Growing protocol with competitive rates  |

### Lending Risk Scoring

The **Lending Risk Scorer** evaluates each protocol on **5 dimensions** with APY penalty adjustment:

| Dimension                 | Weight | What It Measures                                                   |
| ------------------------- | ------ | ------------------------------------------------------------------ |
| **TVL Scale**             | 30%    | Protocol total value locked — larger TVL indicates stability       |
| **Protocol Maturity**     | 20%    | Time since launch and operational track record                     |
| **Reserve Utilization**   | 25%    | Borrow utilization rate — high utilization signals withdrawal risk |
| **Deposit Concentration** | 15%    | Depositor concentration — high concentration increases whale risk  |
| **Incident History**      | 10%    | History of hacks, exploits, or operational failures                |

### Protocol Circuit Breaker

Autonomous safety mechanism triggering auto-exit:

| Trigger                    | Action                               |
| -------------------------- | ------------------------------------ |
| TVL crash (-20% in 1 hour) | Immediate withdrawal                 |
| Oracle drift detected      | Pause new deposits + alert           |
| Withdrawal failure         | Immediate withdrawal attempt + alert |

### Protocol Diversification

Maximum **60% allocation cap** per single protocol.

***

## Alpha Layer — SOL Delta-Neutral

A market-neutral strategy that captures SOL funding rate payments while maintaining zero directional exposure.

### Mechanism

1. Split USDC 50/50: half for spot, half for margin
2. Buy SOL spot → convert to **dawnSOL** (Dawn Labs' LST, \~7% staking yield)
3. Open equal-sized SOL-PERP short (1x leverage — margin = position size)
4. Net SOL exposure = 0: spot long cancels out perp short
5. Collect funding rate payments (when positive) + staking rewards

**No leverage is used.** For a $20,000 allocation: $10,000 buys SOL spot → dawnSOL, $10,000 serves as margin for SOL-PERP short. Liquidation risk is effectively zero.

**Perp venue:** Currently **Binance Futures** (default). A **Bulk Trade** connector is implemented and under testnet evaluation — Bulk is a Solana-native on-chain perp DEX that would eliminate CEX counterparty risk. Production migration is planned after Bulk's mainnet launch and security audit.

### Entry / Exit Logic (Live Config)

| Signal             | Condition                          | Action                   |
| ------------------ | ---------------------------------- | ------------------------ |
| **Entry**          | SOL FR > 10% annualized for 3 days | Allocate up to 70% to DN |
| **Exit**           | SOL FR < 0% annualized for 3 days  | Close positions          |
| **Emergency Exit** | SOL FR < -10% annualized           | Immediate full close     |

A "day" means one complete UTC day with all 3 expected 8-hour funding samples recorded. Partial days are ignored. Emergency exit keys off the latest funding print and does not wait for a full day.

### Yield Composition

| Source               | Estimated APY | Condition                                         |
| -------------------- | ------------- | ------------------------------------------------- |
| Funding Rate (net)   | 8-23%         | When FR is positive                               |
| dawnSOL Staking      | \~7%          | Always-on while position is held                  |
| **Weighted Average** | **15-20%**    | During favorable FR periods (allocation-weighted) |

### Backtest Reference

See [Backtest](/dawn-vault/backtest) for full methodology, results, and how to run it yourself.

***

## Dynamic Allocation

The vault automatically adjusts the split between Base and Alpha layers using a state machine:

```
BASE_ONLY ←→ BASE_DN
```

| From       | To              | Condition                                      |
| ---------- | --------------- | ---------------------------------------------- |
| BASE\_ONLY | BASE\_DN        | SOL FR > 10% annualized for 3 consecutive days |
| BASE\_DN   | BASE\_ONLY      | SOL FR < 0% annualized for 3 days              |
| BASE\_DN   | EMERGENCY\_EXIT | SOL FR < -10% annualized (no time condition)   |

### Base Layer Internal Allocation

Within the Base Layer, capital flows in a **Multiply-first / Lending-second** mode:

1. `CapitalAllocator` sends deployable USDC to Kamino Multiply first
2. `BaseAllocator` manages lending across Kamino / Jupiter for overflow, diversification, and withdrawal buffer
3. Wallet buffer (5%) is preserved before deployment

***

## Performance

| Metric                | Value                          |
| --------------------- | ------------------------------ |
| **Annualized Return** | 14.04%                         |
| **Sharpe Ratio**      | 27.01                          |
| **Max Drawdown**      | 0.23%                          |
| **Test Period**       | Jan 2024 — Apr 2026 (821 days) |

Multiply generates 79% of total returns. DN contributes a smaller but consistent positive amount during favorable funding rate periods.

For full methodology, scenario analysis, and limitations, see [Backtest](/dawn-vault/backtest).

***

## Risk Management

| Layer                        | Mechanism                                           | Trigger                                                                           |
| ---------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Circuit Breaker**          | Auto-exit from Lending layer                        | TVL crash (-20%/1h), oracle drift, withdrawal failure                             |
| **Multiply Risk Scorer**     | Separate risk axis for candidate / position scoring | 4 dimensions: depeg risk, liquidation proximity, exit liquidity, reserve pressure |
| **Multiply Risk Policy**     | Score-based rebalance rules                         | < 75 → normal, 75-89 → stop adds + trim, ≥ 90 → full exit                         |
| **Lending Risk Scorer**      | APY penalty adjustment                              | 5 dimensions: TVL, maturity, utilization, concentration, incidents                |
| **Protocol Diversification** | Max 60% allocation cap                              | Single-protocol lending exposure limit                                            |
| **Multiply Deleverage**      | Staged health rate protection                       | Target 1.15, < 1.10 → soft deleverage (20%), < 1.05 → emergency full deleverage   |
| **DN Risk Manager**          | FR reversal detection + auto-exit                   | FR < -10% annualized → immediate close                                            |
| **Guardrails**               | Kill switch, SOL balance, price freshness           | Prevents tx fee exhaustion and stale data decisions                               |

For comprehensive risk information, see [Risk & Security](/dawn-vault/risk-and-security).


# Backtest

Backtesting validates the USDC Vault's strategy using historical market data before deploying real capital.

## Methodology

* **Data**: Binance SOL-PERP 8-hour funding rates + OHLCV
* **Period**: January 2024 — April 2026 (821 days)
* **Initial Capital**: $10,000
* **Assumptions**: Multiply and Lending APYs are held constant (see [Limitations](#limitations)). DN entry/exit uses the same parameters as the live bot.

### Parameters

| Parameter           | Value                       |
| ------------------- | --------------------------- |
| Multiply APY        | 13% (fixed)                 |
| Lending APY         | 5% (fixed)                  |
| dawnSOL Staking APY | 6.8%                        |
| DN Allocation Cap   | 70% of NAV                  |
| FR Entry Threshold  | > 10% annualized for 3 days |
| FR Exit Threshold   | < 0% annualized for 3 days  |
| FR Emergency Exit   | < -10% annualized           |

## Results: Current Strategy

Multiply-first + Lending overflow + conditional DN — the live production configuration.

| Metric                | Value      |
| --------------------- | ---------- |
| **Final NAV**         | $13,439.01 |
| **Total Return**      | 34.39%     |
| **Annualized Return** | 14.04%     |
| **Sharpe Ratio**      | 27.01      |
| **Max Drawdown**      | 0.23%      |
| Days in BASE\_ONLY    | 584        |
| Days in BASE\_DN      | 237        |
| DN Entries / Exits    | 3 / 3      |

### Yield Breakdown

| Source              |        Amount |    Share |
| ------------------- | ------------: | -------: |
| Multiply Yield      |     $2,784.87 |    79.1% |
| Funding Rate Income |       $535.38 |    15.2% |
| dawnSOL Staking     |       $200.22 |     5.7% |
| **Total Gross**     | **$3,520.47** | **100%** |
| Fees (deducted)     |       -$69.86 |          |
| **Net Profit**      | **$3,439.01** |          |

Multiply generates the vast majority of returns. The DN layer contributes a smaller but consistent positive amount across 3 entry/exit cycles ($736 gross from funding + staking).

### DN Active Periods

| #         | Period                  |            Days | Avg FR (annualized) |
| --------- | ----------------------- | --------------: | ------------------: |
| 1         | 2024-01-03 — 2024-07-05 |             185 |               18.4% |
| 2         | 2024-11-11 — 2024-12-20 |              40 |               20.0% |
| 3         | 2025-07-22 — 2025-08-02 |              12 |                6.4% |
| **Total** |                         | **237 (28.9%)** |           **18.0%** |

### Benchmarks

| Strategy                              | Total Return |
| ------------------------------------- | -----------: |
| **Current (Multiply + Lending + DN)** |   **34.39%** |
| Multiply Only                         |       31.64% |
| Lending Only                          |       11.60% |
| SOL Buy & Hold                        |      -18.31% |

## Known Limitations

### 1. Fixed Multiply / Lending APY

The largest constraint. Multiply (13%) and Lending (5%) are held constant for the entire period. In practice, rates fluctuate significantly (Multiply: 8-20%, Lending: 2-8%). This means:

* **Sharpe Ratio is overstated** — volatility comes only from fee events, not from APY fluctuations
* **Max Drawdown is understated** — Multiply APY drops and depeg-driven drawdowns are not modeled
* **DN's relative value is hidden** — DN becomes more valuable when Multiply APY drops, but this flexibility cannot be evaluated under fixed assumptions

Improvement: ingest historical APY time-series from Kamino/Jupiter APIs and apply variable rates per tick.

### 2. Multiply Risk Not Modeled

* **Depeg risk**: No NAV loss if ONyc depegs from USDC
* **Liquidity risk**: Exit slippage during forced withdrawals not reflected
* **Liquidation risk**: Deleverage costs from Health Rate drops not included
* **Pool capacity**: Assumed unlimited, but real capacity depends on TVL

With these factors, Max Drawdown would likely be materially higher than 0.23%.

### 3. Short Data Period (2 years)

Only data from January 2024 onward is used. Different market cycles (bear markets, low-volatility regimes) are not tested. Binance FR data is available from 2021, but Kamino Multiply only launched in 2024 — longer backtests would require stronger APY assumptions.

### 4. Instant DN Transitions

In production, DN entry/exit involves multiple steps (lending withdrawal → CEX transfer → position construction) taking minutes to tens of minutes. The backtest assumes instant transitions, ignoring price movement risk during execution.

### 5. Static Fee Model

* Swap slippage is fixed at 0.1%, but actual slippage depends on pool liquidity and trade size
* Binance fees vary by tier (down to 0.02% at VIP levels)
* Solana priority fees spike during congestion

### 6. Only FR Uses Real Data

Funding rates are the only real market data driving both DN entry/exit decisions and DN revenue. Base Layer yield (Multiply/Lending) uses fixed assumptions. This creates uneven simulation fidelity across the portfolio — the backtest is most reliable for evaluating DN signal quality, less so for absolute return projections.

{% hint style="warning" %}
Backtest results do not guarantee future performance. Past market conditions may not repeat. See [Risk & Security](/dawn-vault/risk-and-security) and [Disclaimer](/legal/disclaimer).
{% endhint %}

## Run It Yourself

The backtest engine is open source. You can reproduce these results or test your own parameters.

### Setup

```bash
git clone https://github.com/DawnLabsTech/vault.git
cd vault/backtest
npm install
```

### Basic Usage

```bash
# Run with default parameters (matches live bot config)
npm run backtest

# Show all available options
npm run backtest -- --help
```

### CLI Options

| Flag             | Description                             | Default    |
| ---------------- | --------------------------------------- | ---------- |
| `--start`        | Start date                              | 2021-01-01 |
| `--end`          | End date                                | 2026-03-01 |
| `--capital`      | Initial capital (USDC)                  | 10000      |
| `--multiply-apy` | Fixed Multiply APY (%)                  | 13         |
| `--multiply-cap` | Max USDC in Multiply                    | unlimited  |
| `--lending-apy`  | Fixed Lending APY (%)                   | 5          |
| `--dawnsol-apy`  | Fixed dawnSOL APY (%)                   | 6.8        |
| `--entry-fr`     | FR entry threshold (%)                  | 10         |
| `--exit-fr`      | FR exit threshold (%)                   | 0          |
| `--emergency-fr` | Emergency exit threshold (%)            | -10        |
| `--confirm-days` | Confirmation days                       | 3          |
| `--dn-alloc`     | DN allocation ratio                     | 0.7        |
| `--output`       | Output format: `table` / `csv` / `json` | table      |
| `--fetch-only`   | Fetch data only, skip simulation        | —          |

### Examples

```bash
# Reproduce the published results
npm run backtest -- --start 2024-01-01 --end 2026-04-01

# Export as JSON for further analysis
npm run backtest -- --output json

# Fetch funding rate data without running simulation
npm run backtest -- --fetch-only --start 2020-01-01 --end 2026-04-01
```

Funding rate data is fetched from Binance on the first run and cached locally in SQLite. Subsequent runs reuse the cache.


# AI Support

Dawn Vault includes two AI-assisted operator tools:

* **AI Advisor**: an event-driven advisory layer that evaluates the vault and produces recommendations
* **Vault AI Chat**: an interactive chat interface that answers questions about the live vault state and can run read-only support tools

Both features are **non-executing**. They can observe, summarize, explain, and simulate, but they cannot place trades or override the rule-based system.

## Overview

| Feature           | Primary Role                                   | Access Point                                              | Output                         |
| ----------------- | ---------------------------------------------- | --------------------------------------------------------- | ------------------------------ |
| **AI Advisor**    | Push-style monitoring and recommendations      | Dashboard sidebar, Telegram notifications, stored history | Structured recommendations     |
| **Vault AI Chat** | Pull-style operator Q\&A and scenario analysis | Dashboard chat widget, `/api/chat` SSE endpoint           | Streaming plain-text responses |

This design keeps AI in the support layer. The worst case for an AI mistake is an irrelevant suggestion or a low-quality explanation, not an unauthorized on-chain or exchange action.

## Access Control

* The dashboard / proxy layer can be protected with `FRONTEND_API_SECRET`
* The bot API is intended to stay behind the frontend proxy and requires `API_AUTH_TOKEN`
* Chat requests are validated for body size, message length, and session format before reaching the model
* Rate limits apply both per session and per client, so rotating session IDs alone should not bypass throttling

## AI Advisor

The AI Advisor continuously monitors the vault's state and produces actionable recommendations for the operator.

### How It Works

```
Bot Internal State (positions, FR, APY, risk scores, health rates, events)
    ↓
Context Builder → Structured summary for the LLM
    ↓
Claude API → Analyzes context, produces recommendations
    ↓
Store (SQLite) + Notify (Telegram) + Dashboard (sidebar)
```

1. The context builder gathers the bot's current state: portfolio positions, funding rate history, APY across protocols, Multiply health rates, risk scores, recent events, and daily PnL.
2. Claude receives this structured context along with a system prompt describing the vault's strategy rules, then returns a JSON array of recommendations.
3. Recommendations are stored in SQLite for history and accuracy tracking, sent via Telegram, and displayed on the monitoring dashboard.

### When It Runs

| Trigger              | Condition                                         | Frequency           |
| -------------------- | ------------------------------------------------- | ------------------- |
| **Periodic**         | Every 6 hours                                     | Scheduled           |
| **SOL price move**   | >= 5% change since last advisor run               | Checked every 5 min |
| **Risk score spike** | Composite score crosses 50 from below             | Checked every 5 min |
| **FR regime change** | Funding rate sign flip or >= 10% annualized swing | Checked every 5 min |

All event-based triggers enforce a **30-minute cooldown** to prevent excessive API calls.

### Recommendation Format

Each recommendation includes:

* **Category**: `rebalance`, `dn_entry`, `dn_exit`, `risk_alert`, or `param_adjust`
* **Confidence**:
  * `high` — data-backed and directly verifiable from the numbers
  * `medium` — reasonable inference that depends on near-term assumptions
  * `low` — speculative; rarely issued
* **Urgency**:
  * `immediate` — something is broken or a threshold is being breached
  * `next_cycle` — should be addressed within 6–12 hours
  * `informational` — awareness only
* **Override flag** — `true` when the AI recommends a different action than the rule-based system would take

### Surfaces

* Dashboard sticky sidebar
* Telegram notifications
* SQLite recommendation history with outcome tracking

### Safety Guarantees

* **No execution authority**: the advisor cannot trigger trades, rebalances, or parameter changes
* **Graceful degradation**: if the API key is missing or the API is unreachable, the bot continues with rule-based logic only
* **Cost control**: daily API call limit, 30-minute event cooldown, compact context
* **Accuracy tracking**: recommendations are stored with an `outcome` field for post-hoc review

## Vault AI Chat

Vault AI Chat is the operator-facing conversational interface for Dawn Vault. It answers questions using the current vault context and recent session history.

### How It Works

```
User question
    ↓
Current vault context + recent AI Advisor recommendations + session history
    ↓
Claude chat model
    ↓
Streaming answer in dashboard chat widget or `/api/chat`
```

On first message, the chat injects the latest vault context directly into the conversation. On later turns, it keeps short session memory and continues answering against the latest known vault state.

### What It Can Do

* Explain current positions, allocation, performance, and risk posture
* Answer in Japanese or English depending on the operator's language
* Stream responses token-by-token in the UI
* Store per-session chat history in SQLite
* Use built-in support tools when the question requires more than plain Q\&A

### Built-in Support Tools

| Tool                  | Purpose                                                                                                          |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `run_backtest`        | Run "what if" simulations for APYs, funding rate thresholds, allocation ratios, date ranges, and initial capital |
| `get_advisor_history` | Retrieve recent AI Advisor recommendations and 7-day accuracy statistics                                         |

These are **chat tools**, not separate AI products. They extend the chat's ability to answer operator questions with simulations and historical advisory context.

### Access Points

* Floating chat widget on the monitoring dashboard
* `/api/chat` SSE endpoint for streaming responses

### Limits and Safety

* **No execution authority**: chat cannot place trades or mutate live strategy state
* **Requires API key**: if `ANTHROPIC_API_KEY` is not configured, chat remains disabled
* **Operator-only surface**: do not expose chat publicly without frontend and bot auth configured
* **Rate limits**: 30 user messages per hour by default, enforced per session and per client
* **Input validation**: request body size, session ID shape, and message length are restricted before model execution
* **Read-only support scope**: analysis, explanation, and backtests only


# Risk & Security

Dawn Vault is an experimental DeFi product. All deposits are subject to risk.

## Repository Scope

This repository is the **off-chain operator stack** for Dawn Vault. It includes the strategy bot, monitoring dashboard, AI support services, and backtest tooling.

It does **not** include the on-chain vault program, PDA custody implementation, deployed program addresses, or multisig governance configuration. As a result:

* this repo can verify operator-side controls, not on-chain custody guarantees by itself
* any on-chain security claim requires separate deployed-program documentation or audit evidence
* "open source" for this repo should not be read as proof that every production component is published here

## Smart Contract Security

### Non-Custodial Design

The intended product architecture is non-custodial, with vault assets held in **Program Derived Accounts (PDAs)** controlled by the on-chain vault program rather than by an individual operator.

However, the on-chain custody code and deployed addresses are not part of this repository, so that statement must be validated from separate on-chain documentation and audits.

### Permission Separation

| Role        | Permissions                                                      | Holder            |
| ----------- | ---------------------------------------------------------------- | ----------------- |
| **Admin**   | Add/remove adapters, change fees, replace manager, calibrate HWM | Multisig (Squads) |
| **Manager** | Execute rebalances, harvest fees, manage positions via adapters  | Manager Bot       |

The Manager Bot cannot add new adapters, change fee parameters, withdraw to arbitrary addresses, or bypass adapter whitelisting.

This repository only demonstrates the off-chain manager side. It does not by itself prove the deployed on-chain permission model.

### Adapter Whitelisting

External protocol interactions are gated through Adapter Programs. Only whitelisted adapters can access vault funds, and adding a new adapter requires Admin (multisig) approval.

### Voltr Framework

Built on **Voltr** (Ranger Finance) — battle-tested with multiple vaults in production. Includes LP token accounting, fee management, HWM tracking, and locked profit mechanism.

### Anti-MEV Protections

* **Locked Profit**: Yearn V2-style linear release prevents sandwich/frontrun attacks
* **Redemption Fee**: 0.1% makes sandwich attacks unprofitable
* **Priority Fee Management**: Critical transactions use elevated priority fees

### Audit Status

* The off-chain operator stack in this repository is [open source on GitHub](https://github.com/DawnLabsTech/vault)
* Kamino has public third-party audits
* Any audit claim for the separate on-chain vault / custody layer must reference the actual deployed program and its audit reports
* A dedicated third-party audit for the full product stack remains planned

## Risk Disclosures

### 1. Smart Contract Risk — Medium

Vault interacts with multiple on-chain programs (Voltr, Kamino adapters, Jupiter adapters). Any could contain bugs or vulnerabilities.

**Mitigations:** Audited frameworks, adapter whitelisting, non-custodial PDA architecture.

### 2. Multiply / Leverage Risk — Medium

Kamino Multiply uses leveraged stablecoin loops (2.5x-5.75x). Collateral depeg, borrow rate spikes, or high utilization could impact positions.

**Mitigations:** Multiply Risk Scorer evaluates pools on 4 dimensions (depeg risk, liquidation proximity, exit liquidity, reserve pressure). Multi-stage deleverage: target health 1.15, soft deleverage at < 1.10, emergency at < 1.05. Active positions stopped at risk score ≥ 75, fully exited at ≥ 90.

### 3. Funding Rate / Market Risk — Medium

Delta-neutral strategy depends on positive SOL funding rates. Rapid FR reversal may cause losses before positions close.

**Mitigations:** Entry requires FR > 10% for 3 days. Emergency exit at FR < -10% (no delay). Base Layer continues generating yield during FR downturns.

### 4. Liquidation Risk — Low

DN uses 1x leverage (margin = position size) — liquidation risk effectively zero. Multiply positions protected by staged deleverage.

### 5. Exchange / Counterparty Risk — Medium

Delta-neutral currently uses Binance for perpetual futures. Exchange insolvency, API outages, or regulatory actions could affect margin funds held on the CEX.

**Mitigations:** Position size limits, minimum on-chain balance maintained. A **Bulk Trade** connector (Solana-native on-chain perp) is under testnet evaluation — if moved to production, it would eliminate CEX custody risk entirely. Migration is contingent on Bulk's mainnet launch and security audit completion.

### 6. Oracle Risk — Low-Medium

Price data used by the operator stack and underlying protocols may be delayed, manipulated, or stale.

**Current repo mitigations:** bot-side stale-data alerts, protocol circuit-breaker checks for large USDC price deviation, and protocol-specific risk scoring. This repository does not, by itself, prove a full multi-oracle consensus design.

### 7. Operational Risk — Low-Medium

Manager Bot is a critical off-chain component.

**Mitigations:** internal scheduler health monitoring, Docker health checks, retry wrappers, externalized configuration, kill switch and guardrails.

### 8. Liquidity Risk — Low

Large withdrawals may require unwinding positions.

**Mitigations:** Buffer maintained (5%), redemption fee (0.1%), locked profit mechanism.

### 9. Protocol / Composability Risk — Low-Medium

Failure in any composed protocol (lending, Multiply, DEX) could cascade.

**Mitigations:** Protocol diversification (max 60% per protocol), circuit breaker (auto-exit on TVL crash, oracle drift, withdrawal failure), lending risk scorer tracks incident history.

### 10. Regulatory Risk — Unknown

DeFi regulations are evolving. Vault operates under non-custodial architecture to reduce regulatory exposure.

### 11. Solana Network Risk

Network outages, congestion, or consensus issues could prevent operations.

**Mitigations:** conservative leverage, transaction retry / confirmation logic, and post-failure operator monitoring. Exact on-chain recovery behavior depends on the separate custody layer.

## Summary Risk Matrix

| Risk                | USDC Vault |
| ------------------- | ---------- |
| Smart Contract      | Medium     |
| Multiply / Leverage | Medium     |
| Market / FR         | Medium     |
| Liquidation         | **Low**    |
| Exchange            | Medium     |
| Oracle              | Low-Med    |
| Operational         | Low-Med    |
| Liquidity           | Low        |
| Protocol            | Low-Med    |
| Regulatory          | Unknown    |

## Capacity Management

Alpha strategies have limited capacity. Without caps, yield degrades as TVL grows.

| Mechanism              | Description                                                   |
| ---------------------- | ------------------------------------------------------------- |
| **Hard Cap**           | Maximum TVL enforced at the smart contract level              |
| **Soft Cap**           | Warning threshold; new deposits monitored for yield impact    |
| **Dynamic Adjustment** | Caps adjusted based on market liquidity and strategy capacity |

> We prioritize quality of yield over quantity of AUM. We would rather run a $5M vault at 15% APY than a $50M vault at 6% APY.

{% hint style="warning" %}
**Please do not deposit more than you can afford to lose.** Past performance does not guarantee future results. See our [Disclaimer](/legal/disclaimer) for important legal information.
{% endhint %}


# Emergency Response

This document defines Dawn Vault's emergency response framework — the policies, procedures, and communication channels for responding swiftly and appropriately when asset-impacting risks arise, such as protocol exploits, collateral crashes, or network outages.

## A. Detection

Catch anomalies as early as possible. Multiple detection layers run in parallel to eliminate single points of failure.

### A1. Protocol Anomaly Detection (Partially Implemented)

Monitor contracts of utilized protocols (Kamino, Jupiter, etc.) for abnormal large transfers or permission changes. Integration with external security feeds (Hypernative, Forta Network, etc.) is also under consideration as a longer-term complement.

**Phase 1 — Upgrade Authority Monitoring (Live since 2026-04-25).** The Kamino Lending program's upgrade authority is the highest-signal change to watch: any change here means a new code path could be deployed against existing user funds, so detecting it within seconds is critical.

| Trigger                                         | Threshold                                 | Action                                             |
| ----------------------------------------------- | ----------------------------------------- | -------------------------------------------------- |
| Kamino Lending program upgrade authority change | Any change (or transition to/from frozen) | Critical Telegram alert + `ANOMALY` event recorded |

**Currently watched (on-chain, publicly verifiable):**

| Field                                      | Value                                          |
| ------------------------------------------ | ---------------------------------------------- |
| Program ID                                 | `KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD`  |
| ProgramData PDA (BPF Loader Upgradeable)   | `9uSbGW1y9H5Av6H5TKxQ1wnFApSq2t3oEpfF2YfjDQGA` |
| Baseline upgrade authority (as of go-live) | `GzFgdRJXmawPhGeBsyRCDLx4jAKPsvbUqoqitzppkzkW` |

**How it works.** The bot derives the BPF Loader Upgradeable **ProgramData PDA** for the Kamino Lending program (this is the on-chain account that stores the `upgrade_authority` field) and monitors it through two parallel channels:

1. **Helius webhook (primary, low latency).** A webhook configured against the ProgramData PDA address fires whenever that account is touched (which only happens on program upgrades — normal program invocations do not load the PDA into a transaction's account keys). The webhook hits a dedicated `POST /webhook/helius` endpoint authenticated by a separate `HELIUS_WEBHOOK_AUTH` bearer (independent of the dashboard auth token), and triggers an immediate check.
2. **Scheduled polling (fallback, every 1 hour).** Even if the webhook is misconfigured or Helius is degraded, a polling task in the orchestrator's scheduler runs the same check. This bounds detection latency to at most \~1 hour in the worst case.

In both cases the detection logic is identical and intentionally **does not parse the webhook payload** — instead, the bot re-fetches the ProgramData account directly via `getAccountInfo`, parses the `upgrade_authority` field from the bincode-serialized account data, and compares it against the baseline persisted in a SQLite `anomaly_baseline` table. The baseline is seeded once at bot startup. On divergence:

* A critical-level Telegram alert is fired with both the previous and current authority pubkeys (or `<frozen>` if the program transitioned to having no upgrade authority).
* An `ANOMALY` event is recorded in the events ledger with `metadata.action = 'anomaly_upgrade_authority_change'` so it appears in the dashboard separately from generic alerts.
* The baseline is then updated to the new value so subsequent checks don't re-fire on the same change. Operator follow-up is expected to investigate whether the change was legitimate (e.g. announced Kamino upgrade) or hostile.

This payload-agnostic design means the system continues to work even if Helius changes its webhook payload format or if the watched address starts receiving unrelated traffic.

**Roadmap for A1**

| Phase   | Detection                                                                                                            | Status            |
| ------- | -------------------------------------------------------------------------------------------------------------------- | ----------------- |
| Phase 1 | Kamino Lending program upgrade authority change                                                                      | Live (2026-04-25) |
| Phase 2 | Large transfers from Kamino USDC reserve / ONyc collateral vaults (>20% of reserve in 1h = warning, >40% = critical) | Planned           |
| Phase 2 | Reserve config changes (LTV, oracle source, liquidation bonus)                                                       | Planned           |
| Phase 3 | Jupiter Lend program coverage                                                                                        | Planned           |
| Phase 3 | Anomaly event timeline in the frontend dashboard                                                                     | Planned           |

### A2. Borrow Rate Spike Detection (Implemented)

Borrow rates are sampled every 5 minutes and evaluated against three independent conditions. Each condition emits an alert and feeds the deleverage policy (see B3).

| Condition                                       | Default Threshold   | Severity | Resulting Action            |
| ----------------------------------------------- | ------------------- | -------- | --------------------------- |
| Negative spread (effective APY below threshold) | `effective APY < 0` | Critical | Full emergency deleverage   |
| Rate of change (1-hour window)                  | `+500 bps / hour`   | Warning  | Soft deleverage (-20% size) |
| Absolute borrow APY                             | `> 20% annualized`  | Warning  | Soft deleverage (-20% size) |

**How it works.** Each Multiply position's APY breakdown (base borrow / base supply / effective / native yield / leverage) is recorded into a SQLite `borrow_rate_history` table at the same 5-minute cadence as the Multiply health check, deduplicated by 5-minute window. On every sample, the monitor evaluates the three conditions in order of severity (negative spread first) and returns at most one alert. The 1-hour rate-of-change is computed from the oldest sample within the trailing hour vs. the newest sample. Duplicate alerts are suppressed by a 30-minute cooldown per `(label, severity)` key, so the same warning will not re-fire within the cooldown window even while the condition persists; critical alerts always fire when re-detected. Samples older than `sampleRetentionDays` (default 7) are pruned. Thresholds and retention are configurable under `borrowRateSpike` in `config/default.json`.

Detection currently fires on the latest single sample; a "sustained for N minutes" gate is not yet implemented and may be added to suppress one-off transient spikes.

### A3. Protocol Circuit Breaker (Implemented)

Automatically exit positions from a protocol when any of the following conditions are met:

| Trigger                            | Threshold     | Action                                 |
| ---------------------------------- | ------------- | -------------------------------------- |
| TVL crash                          | -20% / 1 hour | Full withdrawal from affected protocol |
| Consecutive balance-check failures | 3 times       | Disable affected protocol              |

After exit, a 24-hour cooldown period applies before automatic re-enablement is attempted.

**How it works.** A scheduled task runs every 60 seconds across all active lending protocols (currently Kamino and Jupiter Lend) and performs two checks per cycle:

1. **TVL** — fetched from the Kamino market metrics endpoint (or Jupiter's earn-tokens endpoint as a proxy). Each cycle's TVL is appended to a rolling history bounded by the 1-hour window; if the oldest sample in-window is ≥20% above the latest, the protocol is tripped.
2. **Withdrawal health** — the protocol's `getBalance()` is called as a liveness probe. Each failure increments a per-protocol counter; success resets it. Three consecutive failures trip the protocol on the assumption that withdrawals are unlikely to succeed either.

Oracle anomaly detection — previously a third check inside the circuit breaker — has been split out into a dedicated monitor (see A5) that uses multi-source cross-checks rather than a single price feed.

When tripped, the breaker invokes an `onTrip` callback (wired by the orchestrator to the protocol's emergency withdrawal), records an `ALERT` event, and adds the protocol to a disabled set so subsequent cycles skip it. The 24-hour cooldown is checked on every cycle: once elapsed, the protocol is removed from the disabled set, the failure counter is cleared, and monitoring resumes. A public `trip(name, reason)` entry point lets external monitors (e.g. A5) request a circuit-breaker trip through the same code path. A manual `enableProtocol()` override is also available for operator intervention.

### A4. Kill Switch (Implemented)

A manual last-resort mechanism for humans to immediately halt all operations. Detected on the next health check (every 5 seconds), triggering the full emergency exit sequence for all positions.

**How it works.** The bot's 5-second health-check loop calls `checkKillSwitch()` first, before any other guardrail. The check is a simple file existence test against `/tmp/vault-kill` (overridable via the `VAULT_KILL_SWITCH_PATH` env var) — operators activate it by SSH-ing into the host and running `touch /tmp/vault-kill`. When the file is detected: a critical alert is fired, an `EMERGENCY_EXIT` action with `reason: 'kill_switch'` is dispatched (which unwinds the base delta-neutral position), the orchestrator stops scheduled tasks, and the process exits with code 1 so the supervisor (Docker / systemd) does not auto-restart. A file-based trigger was chosen over an API endpoint or env var so the path is reachable even when the bot's internal state machine or HTTP server is wedged.

### A5. Oracle Anomaly Detection (Implemented)

Detects when the prices Kamino uses for liquidation diverge from independent reference sources. The dangerous case is the oracle silently over-pricing the collateral relative to actual market depth — health-rate readings look fine, but the real liquidation buffer is much smaller than reported.

| Check                                 | Source comparison                                          | Default threshold    | Severity / Action                                                                                                                      |
| ------------------------------------- | ---------------------------------------------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Stable depeg                          | Kamino reserve oracle vs $1.00                             | ≥ 50 bps / ≥ 100 bps | Warn / Critical → trip all protocols + emergency-deleverage every Multiply position                                                    |
| Cross-source divergence               | Kamino implied collateral/debt ratio vs Jupiter swap quote | ≥ 50 bps / ≥ 100 bps | Warn / Critical → emergency-deleverage the affected market                                                                             |
| Collateral over-pricing (directional) | Kamino oracle > Jupiter quote                              | ≥ 75 bps             | Critical → emergency-deleverage the affected market (tighter than the symmetric threshold because this direction is the dangerous one) |
| Kamino stale cache                    | Reserve `stored` vs `oracle` price                         | ≥ 100 bps            | Warning only (observability — points to refresh delay)                                                                                 |
| Pyth staleness                        | Hermes `publishTime`                                       | > 60 s old           | Warning only                                                                                                                           |
| Pyth confidence                       | Pyth `conf / price`                                        | > 1.0 %              | Warning only                                                                                                                           |

**Sustained gate.** Critical actions only fire after the condition has held for **3 consecutive samples** (≈15 minutes at the default 5-minute cadence). A single sample produces a critical event (visible in logs and event ledger) but its `sustained` flag is false until the gate is satisfied; the orchestrator gates trip / deleverage dispatch on `sustained === true`. Transient fetch failures (Jupiter / Pyth API hiccups) preserve the counter rather than resetting — only a cycle that successfully evaluates the condition and finds it OK clears the counter. Warning-tier events still emit on the first sample, so operators see the situation immediately even though automated action waits.

**How it works.** A scheduled task runs every 5 minutes (aligned with `kamino-multiply-health`) and, for each Multiply market, reads the on-chain Kamino reserve state for both collateral and debt: `getOracleMarketPrice()` (the fresh oracle price) and `getReserveMarketPrice()` (the cached price Kamino uses for liquidation math until the next refresh). Each market then runs four checks:

1. **Stable depeg** — for any side whose mint is a known $1.00-pegged stablecoin (USDC, USDT, PYUSD, USDG), the Kamino oracle is compared to the peg.
2. **Kamino stored vs oracle** — the stored/oracle delta. A wide delta means Kamino's internal cache hasn't caught up to a moving oracle, so health-rate calc is running on a stale price.
3. **Cross-source divergence** — for non-stable collateral, Jupiter is asked for a real swap quote (\~$100 of collateral → debt token). The Kamino-implied ratio (`collOracle / debtOracle`) is compared to the Jupiter quote. The directional check (Kamino over-prices vs DEX) uses a tighter threshold because that's the failure mode that silently inflates health rate.
4. **Pyth health (optional)** — for any mint with a configured Pyth Hermes price feed (`ORACLE_PYTH_PRICE_IDS` env), staleness and confidence-interval width are checked as independent oracle health signals.

Action dispatch lives in the orchestrator. `stable-depeg` events are NAV-wide (the borrow leg of every position is suspect) so they trip the circuit breaker for all protocols and emergency-deleverage every Multiply adapter. `cross-source-dev` events are market-specific. Pyth and stale-cache warnings are alert-only — they're early-warning signals, not action triggers, since acting on them automatically would create false-positive churn.

**Configuration.** All thresholds and the cadence live under `oracleMonitor` in `config/default.json`; the bot picks up changes via the file-watcher hot reload. Pyth Hermes monitoring is opt-in via the `ORACLE_PYTH_PRICE_IDS` environment variable, set to a comma-separated `mint:priceId` list (e.g. `EPjFWdd5...:0xeaa020c6...,DAwNds...:0xabc...`). When the env is unset or empty, Pyth checks are skipped while Kamino-internal and Jupiter cross-source checks continue unaffected.

| Key                                         | Default              | Meaning                                                                         |
| ------------------------------------------- | -------------------- | ------------------------------------------------------------------------------- |
| `checkIntervalMs`                           | 300\_000 (5 min)     | Cycle cadence — aligned with `kamino-multiply-health`                           |
| `sustainedSamples`                          | 3                    | Consecutive samples a critical condition must hold before automated action      |
| `usdcDeviationWarnBps` / `...CriticalBps`   | 50 / 100             | Stable depeg thresholds                                                         |
| `kaminoStaleStoredBps`                      | 100                  | Stored-vs-oracle delta that flags a stale Kamino cache                          |
| `onycCrossSourceWarnBps` / `...CriticalBps` | 50 / 100             | Symmetric cross-source divergence thresholds                                    |
| `onycOverpriceCriticalBps`                  | 75                   | Tighter directional threshold for Kamino over-pricing collateral                |
| `pythStalenessSec`                          | 60                   | Maximum tolerated `publishTime` age                                             |
| `pythConfidencePct`                         | 1.0                  | Maximum tolerated `conf / price` ratio                                          |
| `alertCooldownMs`                           | 1\_800\_000 (30 min) | Suppresses repeat Telegram alerts for the same `(kind, market, mint, severity)` |

## B. Decision

Pre-define what to do and in what order after detection.

### B1. Dependency Map

A relationship diagram of protocols, assets, and infrastructure that vault positions depend on. Makes explicit what breaks when each component fails.

```
ONyc/USDC Multiply Position
│
├── Kamino Protocol
│   ├── Smart Contract → Hack / Bug
│   ├── Multiply SDK → Loop execution failure
│   └── Market Config (RWA Market) → Parameter change / Freeze
│
├── Collateral Asset: ONyc
│   ├── Issuer: Onre → Operations halt / Redemption freeze
│   ├── Native Yield (~10.25%) → Yield decline / Stop
│   ├── Depeg → Direct liquidation risk (Multiply Risk Scorer + A5 cross-source)
│   └── DEX Liquidity (ONyc/USDC) → Exit impossible (A5 cross-source picks up the gap between Kamino oracle and DEX)
│
├── Borrowed Asset: USDC
│   ├── Oracle (Pyth/Switchboard) → Price feed anomaly (A5)
│   ├── Borrow Rate → Spike causing negative carry (A2)
│   └── USDC Depeg → NAV-wide impact (A5 stable-depeg)
│
├── Infrastructure
│   ├── Solana RPC (Helius) → TX submission failure
│   ├── Solana Network → Congestion / Halt
│   └── Jupiter (swap route) → Swap failure during deleverage
│
└── External Contagion Scenarios
    ├── Other protocol hack → Kamino TVL crash / Rate spike
    ├── Solana-wide DeFi panic → Liquidity evaporation
    └── Stablecoin uncertainty → Impact on both USDC and ONyc
```

#### Response Table by Failure Point

| Failure Point               | Impact                               | Detection                                                                    | Response                                                                               |
| --------------------------- | ------------------------------------ | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Kamino contract hack        | Loss of deposited assets             | A1, A3 (TVL crash)                                                           | Kill switch → Notify Kamino                                                            |
| ONyc depeg (>2%)            | Health rate decline → Liquidation    | Multiply Risk Scorer + A5 (cross-source)                                     | Staged deleverage; A5 sustained critical → emergency deleverage                        |
| ONyc DEX liquidity vanishes | Unable to swap during deleverage     | C1 (periodic simulation) + A5 cross-source (Kamino oracle vs DEX gap widens) | Split withdrawal, raise slippage cap                                                   |
| USDC depeg                  | NAV-wide impact (every borrow leg)   | A5 stable-depeg                                                              | Sustained critical → trip all protocols + emergency deleverage every Multiply position |
| Onre operations halt        | ONyc unredeemable, yield stops       | Manual monitoring, contact Onre                                              | Full exit                                                                              |
| Borrow rate spike           | Negative carry erodes NAV            | A2 (spike detection)                                                         | Auto deleverage                                                                        |
| Pyth oracle anomaly         | Incorrect liquidation or misjudgment | A5 (multi-source cross-check, staleness, confidence)                         | Sustained critical → emergency deleverage / circuit breaker trips                      |
| Helius RPC outage           | TX submission failure                | Guardrails (consecutive failure detection)                                   | Failover to backup RPC                                                                 |
| Jupiter swap route down     | Unable to deleverage                 | C4 (periodic dry run)                                                        | Alternative route or wait                                                              |

### B2. Withdrawal Priority Order (Planned)

Pre-define which positions to exit first based on liquidity depth. Exit illiquid positions first while liquidity remains, rather than attempting a single bulk withdrawal.

### B3. Negative Carry Auto-Deleverage (Implemented)

Borrow rate spikes are routed through the same staged deleverage policy used for health and risk-score breaches, prioritized by severity:

* **Critical (negative spread)** — when effective APY drops below the threshold (default 0, i.e. borrow yield exceeds collateral yield), the position is fully unwound via `emergencyDeleverage()`.
* **Warning (rate of change / absolute threshold)** — position size is reduced by 20%; if a health-rate or risk-score reduction is also active, the largest of the three reductions is taken (not summed).

**How it works.** On every Multiply health-check cycle, the orchestrator (a) records the latest borrow/supply APY into the borrow-rate history, (b) asks the spike monitor for a current alert level, and (c) feeds that level alongside health rate and risk score into a single policy function (`determineMultiplyRiskAction`). The policy resolves to one of three outcomes:

* `emergency` if any input is at critical level (borrow-rate spike is critical *or* health < emergency threshold *or* risk score ≥ emergency score) — full `emergencyDeleverage()` is dispatched.
* `reduce` if any input is at warning level — three candidate reduction amounts are computed (20% for borrow-rate warning, 20% for health < alert, `currentBalance - riskCap` for risk-score breach) and the **maximum** of the three is taken as the actual reduction. This avoids over-reducing when multiple warnings overlap (a 20% borrow-rate cut plus a 20% health cut should not stack to 40%).
* `none` otherwise.

The `reason` attached to the action records which input dominated, so the alert message and event log can attribute the action correctly. Borrow-rate-driven actions are tagged `borrow_rate_spike_emergency` / `borrow_rate_spike_soft`.

Caveat: detection is based on the latest sample with a 30-minute alert cooldown. A sustained-period gate (e.g. negative carry held for N consecutive samples) is not yet implemented — see A2.

### B4. NAV Freeze Criteria (To be implemented at Strata migration)

Define conditions under which NAV calculation is frozen and Instant Redemption is disabled. Prevents information-advantaged LPs from front-running exits, which would unfairly socialize losses onto remaining participants.

## C. Execution

Ensure positions can actually be closed after a decision is made.

### C1. Liquidity Depletion Simulation (Planned)

Periodically test whether Multiply deleverage can complete when ONyc/USDC DEX liquidity is extremely thin.

### C2. Staged Withdrawal Logic (Planned)

Split withdrawals into tranches rather than attempting a single bulk exit, executing while liquidity remains available.

### C3. TX Failure Retry Enhancement (Partially Implemented)

Automatic priority fee escalation during Solana network congestion. Jito bundle submission is not yet integrated.

**How it works.** The shared transaction sender wraps every on-chain action with up to 3 send/confirm attempts. On each attempt for a self-built (legacy) transaction, the priority fee is estimated per writable account — using Helius's `getPriorityFeeEstimate` (recommended tier) when available, otherwise the 75th percentile of `getRecentPrioritizationFees` — and clamped to `[1,000, 1,000,000]` µLamports/CU. A `ComputeBudgetProgram.setComputeUnitPrice` instruction is prepended along with a CU limit of 300k, the latest blockhash is refreshed, and the tx is re-signed before each send. If the confirm window (default 60s) expires or the send throws, the fee is multiplied by `1.5` and the next attempt fires after a linearly-growing backoff (500ms × attempt). For externally-built versioned transactions (e.g. Jupiter swap routes whose fee can no longer be modified), the same retry/backoff applies but without fee bumping. Transactions whose blockhash has expired are not retried because re-sending the same tx is futile.

Pending: routing congestion-sensitive transactions (emergency deleverage, swap legs) through Jito bundles for tip-prioritized landing. This is the "partially" qualifier — fee escalation alone is insufficient when block space is auctioned via tips rather than fees.

### C4. Emergency Exit Dry Run (Planned)

Periodically execute small-amount withdrawals and re-deposits in the production environment to verify that exit routes remain functional.

## D. Communication

### D1. Internal Escalation

```
Detection (Bot auto Telegram notification)
  │
  ├─ Immediate: Telegram alert to Yutaro
  │
  ├─ Within +5 min: Initial impact assessment
  │
  └─ Within +10 min: Response decision (full exit / partial reduction / monitor)
```

### D2. External Notification Targets

| Target           | When to Notify                        | Purpose                              |
| ---------------- | ------------------------------------- | ------------------------------------ |
| **Kamino**       | Collateral, oracle, or market anomaly | Information sharing / Freeze request |
| **Jupiter**      | Swap / Lending anomaly                | Route verification / Status sharing  |
| **Helius**       | RPC anomaly / Solana outage           | Infrastructure status check          |
| **Onre (ONyc)**  | ONyc depeg / Redemption halt          | Redemption availability check        |
| **LP Investors** | When NAV is impacted                  | Status report / Policy communication |


# Transparency

Dawn Vault fully decomposes and discloses the source of every basis point of yield. We believe depositors deserve to know exactly **where their returns come from**.

## Yield Provenance

Many DeFi yield products advertise an APY number without explaining its composition. Dawn Vault provides a full breakdown by source.

### USDC Vault Yield Decomposition

| Component            | Source                                                                 | Typical Range | Risk Level |
| -------------------- | ---------------------------------------------------------------------- | ------------- | ---------- |
| **Multiply Yield**   | Leveraged stablecoin loops via Kamino Multiply (ONyc/USDC, USDG/PYUSD) | 9-16%         | Low-Medium |
| **Lending Yield**    | Interest from USDC lending (Kamino, Jupiter)                           | 3-8%          | Low        |
| **Funding Rate PnL** | Net payments received from SOL-PERP shorts                             | 8-23%         | Medium     |
| **Staking Yield**    | dawnSOL staking rewards on spot leg                                    | \~7%          | Low        |
| **Borrowing Cost**   | Interest paid on borrowed assets (Multiply borrow leg)                 | -(0-3%)       | N/A        |
| **Execution Cost**   | Swap slippage, gas fees, position entry/exit costs                     | -(0.1-0.5%)   | N/A        |
| **= Net Vault APY**  | Weighted average across allocations                                    | **9-20%**     | —          |

### Example: Base Layer Only (Current Mode)

```
Multiply Yield:    +14.2%   (ONyc/USDC @ 2.5x, majority allocation)
Lending Yield:      +6.1%   (Kamino USDC, supplementary)
Funding Rate PnL:   +0.0%   (DN strategy inactive)
Execution Cost:     -0.0%   (minimal rebalancing)
─────────────────────────
Net Vault APY:     ~12-16%  (Multiply-dominant)
```

### Example: Base + Alpha (High FR Period)

```
Allocation:  Multiply 30% / Lending 20% / DN 50%

Multiply Yield:    14.2% × 0.30 =  +4.3%
Lending Yield:      5.2% × 0.20 =  +1.0%
Funding Rate PnL:  18.4% × 0.50 =  +9.2%
Staking Yield:      7.1% × 0.50 =  +3.6%
Execution Cost:                     -0.3%
─────────────────────────────────────────
Net Vault APY:                     ~17.8%  (weighted average)
```

> We will never report a blended APY number without providing its full decomposition.

## Proof-Based Reporting

Dawn Vault publishes structured performance reports at regular intervals.

### What We Report

| Data Point                            | Frequency   | Verification                        |
| ------------------------------------- | ----------- | ----------------------------------- |
| **Yield Breakdown** (by source)       | Every epoch | On-chain transaction data           |
| **Hedge Ratio** (spot vs. short)      | Every epoch | On-chain + CEX position data        |
| **Allocation Split** (base vs. alpha) | Every epoch | On-chain vault state                |
| **Reserve Balance**                   | Every epoch | On-chain account balance            |
| **Share Price**                       | Continuous  | On-chain LP token accounting        |
| **Cumulative PnL**                    | Daily       | Dashboard + historical data         |
| **Drawdown Metrics**                  | Daily       | Calculated from share price history |

### Independent Verification

Depositors can independently verify:

* **Share price**: Query the on-chain vault program directly
* **LP token balance**: Check their wallet
* **Vault TVL**: On-chain total assets visible to anyone
* **Protocol positions**: On-chain adapter positions are public

Important scope note: this repository currently exposes the off-chain operator stack, not the on-chain vault program itself. Independent on-chain verification therefore depends on Dawn Vault publishing the deployed program addresses, vault addresses, and proof/report endpoints separately.

### Skin in the Game

Dawn Labs deploys its own capital under the **exact same conditions** as depositors — same vault, same strategy, same fee structure. No preferential treatment or separate accounts.

## Yield Smoothing Reserve

The Yield Smoothing Reserve (YSR) is a stabilization mechanism funded by Dawn Labs' validator commission revenue.

### How It Works

```mermaid
graph LR
    VC[Validator Commission<br>Revenue] --> YSR[Yield Smoothing<br>Reserve]
    YSR -->|FR Negative Period| SUB[Subsidize<br>Vault Yield]
    YSR -->|FR Positive Period| ACC[Accumulate<br>Reserve]
```

1. **Accumulation**: Validator commission revenue flows into the Reserve
2. **Stabilization**: When funding rates turn negative, the Reserve supplements vault yield to reduce APY dips
3. **Recovery**: When conditions improve, the Reserve replenishes

This mechanism is only possible because Dawn Labs operates a Solana validator — the commission revenue is an external income stream that doesn't come from depositor funds.

{% hint style="info" %}
The Yield Smoothing Reserve is a **stabilization mechanism**, not a guarantee. It does not guarantee any minimum APY, does not insure against losses, and reserve size may be insufficient during prolonged adverse conditions.
{% endhint %}

The Reserve balance is disclosed in every epoch report. Depositors can track current balance, utilization rate, and accumulation vs. distribution history.


# Fees & How to Use

## Fee Schedule

| Fee                 | Rate        | Description                                  |
| ------------------- | ----------- | -------------------------------------------- |
| **Performance Fee** | 20%         | Charged on profits above the High Water Mark |
| **Management Fee**  | 1% per year | Annual fee on total assets under management  |
| **Deposit Fee**     | 0%          | No fee on deposits                           |
| **Redemption Fee**  | 0.1%        | Small fee on withdrawals                     |

### Performance Fee (HWM)

The performance fee is only charged on **new profits** using a High Water Mark system:

```
Share Price History:

$1.00 → $1.10 → $1.05 → $1.15
       ↑ Fee      No fee  ↑ Fee
       (on $0.10)         (only on $0.05,
                           i.e. $1.15-$1.10)
```

* Fee is only charged when share price exceeds the previous HWM
* If the vault loses money and recovers, no fee until the previous high is surpassed
* Calculated using LP token dilution model — depositor share prices reflect fees automatically

### Locked Profit Mechanism

Profits are locked and released linearly over a configurable duration (Yearn V2 model). This prevents frontrunning — you can't deposit right before a profit event and withdraw immediately after.

All fee parameters are set on-chain and visible to anyone.

***

## How to Deposit

### Prerequisites

* A Solana wallet (Phantom, Solflare, or Backpack recommended)
* USDC on Solana (SPL token)
* A small amount of SOL for transaction fees (\~0.01 SOL)

### Steps

1. Visit the Dawn Vault web app and **Connect Wallet**
2. Select the **USDC Vault** and review details (current APY, TVL, remaining capacity)
3. Enter the amount of USDC to deposit
4. Review the transaction summary (deposit amount, LP tokens to receive, estimated APY)
5. Click **Deposit** and approve the transaction in your wallet
6. After confirmation, LP tokens appear in your wallet and yield begins accruing immediately

### What Happens After Deposit

* Your USDC is transferred to the vault's PDA (non-custodial)
* You receive LP tokens representing your share of the vault
* The Manager Bot allocates your capital according to the current strategy
* Yield auto-compounds — no claiming or harvesting needed

***

## How to Withdraw

### Steps

1. Connect your wallet and navigate to the USDC Vault page
2. Click **Withdraw** and enter the amount of LP tokens to redeem (or "Max" for full withdrawal)
3. Review: LP tokens to burn, USDC to receive (after 0.1% redemption fee)
4. Click **Confirm Withdrawal** and approve the transaction
5. USDC appears in your wallet

**Your withdrawal amount = LP tokens × current share price**

### Processing Time

* **Standard**: Processed immediately on-chain
* **Large withdrawals**: May take additional time if positions need to be unwound

### Important Notes

* No lock-up period — withdraw anytime
* Yield is reflected in the share price (no separate "claim" step)
* Performance fees are already deducted from the share price — what you see is what you get
* Deposits may be rejected if the vault has reached its TVL cap


# FAQ & Glossary

## FAQ

### General

**What is Dawn Vault?**

A yield-generating vault on Solana built by Dawn Labs, an active Solana validator operator. It combines Kamino Multiply, lending aggregation, and delta-neutral strategies for optimized risk-adjusted returns.

**What makes Dawn Vault different?**

(1) **Validator-native alpha** — dawnSOL adds staking rewards on top of strategy returns; (2) **Full transparency** — every source of yield is decomposed and disclosed; (3) **Yield Smoothing Reserve** — validator commission revenue stabilizes returns.

**Is Dawn Vault custodial?**

The intended product architecture is non-custodial, with assets held by the on-chain vault program rather than by an individual operator.

This repository, however, contains the off-chain operator stack only. It does not include the on-chain custody program or deployed addresses, so that guarantee must be verified from separate on-chain documentation.

**Who operates Dawn Vault?**

Dawn Labs, a Solana operations partner based in APAC. We run validator infrastructure and operate the vault with our own capital alongside depositors.

### Yield

**Where does the yield come from?**

* **Kamino Multiply** — Leveraged stablecoin loops (ONyc/USDC \~16%, USDG/PYUSD \~9.5%)
* **Lending interest** — USDC lent to Kamino and Jupiter
* **Funding rate payments** — SOL-PERP perpetual futures (when active)
* **Staking rewards** — dawnSOL \~7% APY (when DN is active)

See [Transparency](/dawn-vault/transparency) for full details.

**What APY can I expect?**

9-16% from the Base Layer (Kamino Multiply + Lending). During high SOL funding rate periods, up to 20% when the Alpha Layer is active.

**Is the APY guaranteed?**

No. APY depends on market conditions and is variable. The Yield Smoothing Reserve helps stabilize but does not guarantee any minimum.

**How is yield distributed?**

Auto-compounded into the vault. No claiming or harvesting. LP token share price increases as the vault earns yield.

### Deposits & Withdrawals

**What assets can I deposit?**

USDC (SPL token on Solana).

**Is there a lock-up period?**

No. Withdraw at any time.

**What are the fees?**

Performance: 20% (HWM-based), Management: 1%/year, Deposit: 0%, Withdrawal: 0.1%. See [Fees & How to Use](/dawn-vault/fees-and-usage).

### Risk

**Can I lose money?**

Yes. Strategies minimize risk, but loss is possible due to smart contract bugs, market events, or other factors. See [Risk & Security](/dawn-vault/risk-and-security).

**How is risk managed?**

Multi-layered system: Multiply Risk Scorer (4 dimensions: depeg risk, liquidation proximity, exit liquidity, reserve pressure), Lending Risk Scorer (5 dimensions), Protocol Circuit Breaker, staged deleverage protection, DN risk manager, guardrails and kill switch.

**Is the smart contract audited?**

The open-source portion in [github.com/DawnLabsTech/vault](https://github.com/DawnLabsTech/vault) is the off-chain operator stack. Kamino has public audits. Audit claims for the separate on-chain vault / custody layer should be checked against the actual deployed program and its audit reports. A dedicated third-party audit for the full product remains planned.

**Is the code open source?**

Yes for the off-chain operator stack: bot, backtest engine, dashboard, and AI support services are open source in [github.com/DawnLabsTech/vault](https://github.com/DawnLabsTech/vault). That does not, by itself, prove that the separate on-chain custody layer is published in this same repository.

***

## Glossary

| Term                              | Definition                                                                                                                                       |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **APY**                           | Annual Percentage Yield — annualized return including compounding                                                                                |
| **Base Layer**                    | Always-on yield strategy (Kamino Multiply + Lending)                                                                                             |
| **Alpha Layer**                   | Conditional yield strategy (delta-neutral) — activates only during favorable conditions                                                          |
| **Circuit Breaker**               | Autonomous safety mechanism: auto-exit on TVL crash, oracle drift, or withdrawal failure                                                         |
| **dawnSOL**                       | Dawn Labs' Liquid Staking Token — represents staked SOL with Dawn Labs' validator                                                                |
| **Delta-Neutral (DN)**            | Equal long spot + short perp positions, eliminating directional exposure while earning funding rates                                             |
| **Funding Rate (FR)**             | Periodic payment between long/short traders in perpetual futures to keep perp prices aligned with spot                                           |
| **High Water Mark (HWM)**         | Highest-ever share price — performance fees only charged on new profits above HWM                                                                |
| **Kamino Multiply**               | Leveraged stablecoin loop strategy on Kamino — deposit collateral, borrow, swap, re-deposit                                                      |
| **LP Token**                      | Liquidity Provider Token — represents a depositor's proportional share of a vault                                                                |
| **LST**                           | Liquid Staking Token — represents staked assets usable in DeFi while earning staking rewards                                                     |
| **Manager Bot**                   | Off-chain automated system executing vault strategies, managing positions, monitoring risk                                                       |
| **Market Scanner**                | Monitors Kamino Multiply pool APYs and recommends switching when economics justify                                                               |
| **Multiply Risk Scorer**          | 4-dimension evaluation: depeg risk (30%), liquidation proximity (30%), exit liquidity (20%), reserve pressure (20%)                              |
| **Lending Risk Scorer**           | 5-dimension evaluation: TVL scale (30%), protocol maturity (20%), reserve utilization (25%), deposit concentration (15%), incident history (10%) |
| **PDA**                           | Program Derived Account — Solana account owned by a program, used for non-custodial asset custody                                                |
| **Share Price**                   | Value of one LP token in the vault's base asset. Increases as the vault earns yield                                                              |
| **TVL**                           | Total Value Locked — total assets deposited in a vault or protocol                                                                               |
| **Voltr**                         | Vault framework by Ranger Finance on which Dawn Vault is built                                                                                   |
| **Yield Provenance**              | Practice of decomposing and disclosing every source of vault yield                                                                               |
| **Yield Smoothing Reserve (YSR)** | Reserve funded by validator commission that stabilizes vault APY during unfavorable conditions                                                   |


# Roadmap

## Phase 1: USDC Vault (Current)

**Status: Active**

The flagship vault establishing Dawn Vault's core infrastructure and track record.

* **Base Layer**: Kamino Multiply (ONyc/USDC \~16%, USDG/PYUSD \~9.5%) + USDC Lending (Kamino, Jupiter, 3-8%)
* **Alpha Layer**: SOL delta-neutral with dawnSOL enhancement (15-20% APY)
* **Target APY**: 9-16%+

### Milestones

* [x] Strategy backtest (821 days, Sharpe Ratio 27.01)
* [x] Manager Bot development
* [x] Live deployment with own capital
* [ ] Public deposits
* [ ] Performance reporting system
* [ ] Documentation site

***

## Phase 2: Strata — Tranched Vault

**Status: Planned**

Split the USDC Vault into Senior and Junior tranches, enabling institutional investors to participate with defined risk/return profiles.

|                   | Senior Vault                       | Junior Vault               |
| ----------------- | ---------------------------------- | -------------------------- |
| **Return**        | 8% fixed                           | Variable (residual upside) |
| **Loss priority** | Protected (last to absorb)         | First-loss buffer          |
| **Withdrawal**    | Instant                            | 7-day lock                 |
| **Target**        | Institutions, stable-yield seekers | High-yield seekers         |

Underlying strategy remains the same as Phase 1. Risk separation is enforced via an on-chain Accounting Waterfall (Anchor program) built on Ranger Finance infrastructure.

> *"Stop losing sleep over hacks. Take the Senior tranche."*

***

## Phase 3: Japan Institutional Access

**Status: Planned**

Expand access to Japanese institutional investors and qualified investors (適格投資家) through regulatory alignment and JPY-native on-ramps.

* **Regulatory & audit compliance**: Structured reporting and audit trails meeting Japanese financial regulations
* **JPY stablecoin integration**: Enable vault participation via JPY stablecoins (e.g., JPYC, progmat coin) to remove FX friction for domestic investors
* **KYC/AML layer**: Permissioned deposit flow for compliance with Japanese fund regulations
* **Localized reporting**: Performance reports and risk disclosures in Japanese, aligned with domestic institutional requirements

***

*Timelines are indicative and subject to change based on market conditions and development progress.*


# Strata — Phase 2

> *"Stop losing sleep over hacks. Take the Senior tranche."*

Strata is Dawn Labs' next product: a tranched yield vault on Solana designed for institutional depositors. By splitting a single underlying strategy into Senior and Junior tranches, Strata structurally separates risk and return — putting institutions into the protected tier and risk-tolerant LPs into the high-yield tier.

***

## Why Now

Since the Drift hack (2025), institutional capital has largely stayed out of DeFi vaults. The common objection: *"We can't get internal approval when total-loss risk exists."* Strata answers this directly. Junior depositors absorb losses first; Senior depositors are protected until Junior NAV reaches zero. This is the on-chain equivalent of a CLO (Collateralized Loan Obligation) — a structure that has worked in traditional finance for decades.

***

## Two Layers

### Layer 1 — Risk: Senior / Junior Tranche

|                   | Senior Vault                       | Junior Vault                          |
| ----------------- | ---------------------------------- | ------------------------------------- |
| **Return**        | 8% fixed (capped)                  | Variable — all residual upside        |
| **Loss priority** | Last to absorb                     | First-loss buffer                     |
| **Withdrawal**    | Instant                            | 7-day lock                            |
| **Target**        | Institutions, stable-yield seekers | High-yield seekers, risk-tolerant LPs |

**Accounting Waterfall (exit priority):**

```
Senior payout = user_senior_share × min(total_nav, senior_total_deposits)
Junior payout = user_junior_share × max(total_nav - senior_total_deposits, 0)
```

* **Profit scenario**: Senior receives 8% fixed first → remaining distributed to Junior
* **Loss scenario**: Junior NAV is drawn down first → Senior is protected until Junior is fully wiped

### Layer 2 — Strategy: Base / Alpha / DN

|                | Base Layer        | Alpha Layer        | DN Layer                           |
| -------------- | ----------------- | ------------------ | ---------------------------------- |
| **Strategy**   | Kamino Lending    | Kamino Multiply    | SOL Delta-Neutral                  |
| **Yield**      | \~5–7% (stable)   | \~14–16% (primary) | Variable (funding rate dependent)  |
| **Activation** | Always (overflow) | Always (primary)   | SOL funding rate > 10% for 3+ days |
| **Risk**       | Low               | Medium (leveraged) | Medium (hedged)                    |

Capital allocation priority: concentrate in Alpha (Multiply) → overflow excess into Base (Lending) → activate DN conditionally.

***

## Architecture

```
[Dawn Senior Vault]     [Dawn Junior Vault]
        │                       │
        └───────────┬───────────┘
                    ▼
        Dawn Tranche Program (Anchor)
        · NAV tracking
        · Waterfall accounting
        · Withdrawal priority enforcement
                    │  (single capital pool)
                    ▼
        Ranger Vault (execution layer)
        ├─ Kamino Multiply adaptor  (Alpha Layer / primary)
        └─ Kamino Lending adaptor   (Base Layer / overflow)
```

**Tech stack:**

* **Anchor** (Dawn Tranche Program): Issues Senior-LP / Junior-LP tokens, applies waterfall math at withdrawal
* [**Ranger Finance**](https://docs.ranger.finance/) (Vault-as-a-Service infrastructure)
  * `withdrawal_waiting_period` natively implements the 7-day Junior lock
  * CPI: `deposit_vault` / `request_withdraw_vault` / `withdraw_vault` / `instant_withdraw`
* **Kamino Finance**: Multiply + Lending adaptors

**Key design insight:** Ranger manages a single asset-per-share ratio across all LPs in a vault. The Tranche Program sits between Ranger and end users — it holds Ranger LP tokens as an intermediary, then applies its own waterfall math at withdrawal to distribute unequally to Senior vs. Junior depositors. Senior gets the protected slice; Junior gets what's left.

***

## Junior Bootstrap

Initial Junior capital is provided by **Dawn Labs itself**.

* Puts Dawn Labs' own money at first-loss, signaling skin-in-the-game to Senior LPs
* As track record accumulates, external Junior LPs seeking high yield can be onboarded
* At hackathon demo stage, Dawn Labs capital fully covers the Junior tranche

***

## Competitive Landscape

### TradFi Precedents

* **CDO / CLO**: Mortgages and leveraged loans tranched into AAA (Senior) through Equity (Junior). Strata is the on-chain CLO equivalent.
* **Real estate preferred/subordinate structures** (common in Japan): Priority investor (principal protected) / subordinate investor (absorbs losses first, captures upside). Identical structure.

### Crypto Precedents (Failed)

* **Barnbridge** (Ethereum, 2021): SMART Yield split Compound yields into Senior/Junior. $178M TVL → collapsed when low interest rates made the fixed Senior rate unsustainable.
* **Saffron Finance** (Ethereum, same era): Same structure, same failure mode.

### Direct Solana Competitor

* **Kormos** (Cypherpunk Sep 2025, DeFi 2nd place, C4 accelerator)
  * Structure: Liquid depositor (Junior-like) / Locked depositor (Senior-like)
  * Narrative: "Fractional reserve banking on DeFi"
  * Key difference: **Locked = first-loss** — the tranche direction is inverted. Not targeting institutions or explicit total-loss protection.

### Strata's Differentiation

1. **Narrative**: Directly responds to the Drift-hack-era "total-loss risk kills institutional approval" pain point
2. **Target customer**: Institutions in the Senior tranche — designed to pass internal investment committees
3. **Yield headroom**: Kamino Multiply (\~16%) provides enough raw yield for Senior 8% fixed to be sustainable — the failure mode of Barnbridge
4. **Operating track record**: Dawn Labs runs Phase 1 Vault on live capital; strategy and risk management credibility already exists

***

## Open Questions / Todo

* [ ] Anchor program detailed design — how much NAV calculation lives on-chain vs. off-chain
* [ ] Ranger Vault Owner registration and adaptor configuration steps (to confirm with Ranger team)
* [ ] CPI routing feasibility — can a single Anchor program hold Ranger LP tokens for two separate depositor pools?
* [ ] Resolve potential conflicts: locked profit degradation timing vs. Senior 8% payout, HWM fee accrual vs. Tranche-side accounting
* [ ] Junior external onboarding: timing, eligibility, and minimum size design
* [ ] Pitch deck creation


# Ranger Build-A-Bear Hackathon

This page is the submission hub for Dawn Vault's Ranger Build-A-Bear Hackathon entry. It gathers the key materials judges need to review the strategy, implementation, and live build progress in one place.

## Dawn Vault in One Paragraph

Dawn Vault is a validator-native yield strategy being developed for Ranger Earn. The current implementation focuses on strategy logic, risk management, and backtest tooling, with future on-chain deployment planned to integrate Ranger's vault framework and protocol adapters. Instead of relying on a single DeFi primitive, it combines a stable **Base Layer** (Kamino Multiply + lending) with a conditional **Alpha Layer** (SOL delta-neutral with dawnSOL staking) so the vault can pursue higher yield without depending on directional SOL exposure.

## Submission Materials

### 🎥 Demo / Pitch Video (max 3 min)

**Link:** <https://youtu.be/DzEyZj0fc5g>

### 📄 Strategy Documentation

* [Overview](/dawn-vault/overview)
* [USDC Vault](/dawn-vault/usdc-vault)
* [Backtest](/dawn-vault/backtest)
* [AI Support](/dawn-vault/ai-support)
* [Risk & Security](/dawn-vault/risk-and-security)
* [Transparency](/dawn-vault/transparency)

### 📊 Live Dashboard

**Link:** [Dawn Vault Dashboard](https://frontend-sand-six-69.vercel.app/)

### 💻 Code Repository

**Link:** [DawnLabsTech/vault](https://github.com/DawnLabsTech/vault)

### 🔗 On-chain Verification

**Wallet / Vault Address:** `3S1kvQuLYLisn8KxHNiCoqTgtZNJQAxJi4oyGLxeeYVT`

* [View on Solscan](https://solscan.io/account/3S1kvQuLYLisn8KxHNiCoqTgtZNJQAxJi4oyGLxeeYVT)

## Judging Criteria

### Strategy Quality & Edge

* Validator infrastructure is part of the yield stack, creating a source of edge that pure aggregators do not have
* The vault combines stable base carry with conditional alpha instead of forcing one strategy across all market regimes
* The delta-neutral layer targets funding rate income while keeping net directional SOL exposure near zero

### Risk Management

* Multiply allocation is gated by a dedicated risk scorer covering depeg risk, liquidation proximity, exit liquidity, and reserve pressure
* Lending exposure is diversified and monitored with protocol-level circuit breakers
* The delta-neutral layer uses explicit entry, exit, and emergency exit thresholds based on funding conditions

### Technical Implementation

* The current implementation centers on strategy logic, backtest tooling, monitoring, and production-oriented operational controls
* The operator stack includes AI Advisor and Vault AI Chat for read-only monitoring, explanation, and support workflows
* This submission validates the allocation logic, risk controls, and execution design before vault-framework integration
* Ranger vault framework integration and protocol adapters are planned as the next step toward production deployment

### Production Viability

* The strategy is designed around existing Solana liquidity venues and operationally realistic execution paths
* The base layer can continue to earn while the alpha layer is inactive, which supports more stable deployment behavior
* Capacity, monitoring, and operational safeguards are considered from the beginning rather than treated as future work

### Novelty & Innovation

* The submission connects validator economics, LST yield, DeFi carry, and automated vault logic into one product
* It adds an AI support layer for operator-facing recommendations, vault-state interpretation, and scenario analysis without execution authority
* It frames the vault as infrastructure-first yield, not just APY routing
* The Yield Smoothing Reserve concept extends validator revenue into yield stabilization for depositors


# Raiku

A reference guide for enterprises evaluating **Raiku** — a Solana coordination layer that replaces probabilistic priority-fee bidding with deterministic block-space reservations.

{% hint style="warning" %}
**Status (April 2026)**: Raiku is **pre-mainnet**. v2 SDK rollout is expected late 2025, mainnet launch targeted for 2026. All pricing figures in this document are modeled from existing Solana priority-fee data and are **not observed Raiku rates**.
{% endhint %}

***

## What Raiku Is

Raiku is a **block-building coordination layer** for Solana. Rather than competing in Solana's per-block priority-fee auction (where higher bids probabilistically get faster inclusion), Raiku lets applications **pre-book or instantly purchase blockspace** from participating validators.

|                         | Traditional Solana                   | Raiku                                                |
| ----------------------- | ------------------------------------ | ---------------------------------------------------- |
| **Inclusion model**     | Probabilistic (priority fee bidding) | Deterministic (reserved or auction-won)              |
| **Slot targeting**      | No — "best effort"                   | Yes — specific future slot (AOT)                     |
| **Pre-confirmation**    | No                                   | Sub-50ms                                             |
| **Claimed reliability** | Varies widely under load             | 99.9%+ within Raiku-controlled slots                 |
| **Pricing**             | Market-driven priority fee           | Auction (AOT) or priority fee × 1.05 + routing (JIT) |

***

## How It Works

Raiku operates within slots led by **Raiku-opted-in validators**. Non-Raiku slots remain under the normal Solana / Jito flow — Raiku has no control there.

### Two Execution Models

**AOT — Ahead-of-Time**

* English-style sealed-bid auction for a **specific future slot**
* Auction runs roughly 36 seconds (\~100 slots) before the target, closes \~90 slots prior
* Winners receive an **inclusion signal** — a pre-confirmation that the transaction will land
* Use cases: scheduled settlements, oracle updates, liquidations, arbitrage on known events

**JIT — Just-in-Time**

* First-price sealed-bid auction for the **current leader's block**
* **Minimum price = current priority fee × 1.05 + routing fee**
* Sub-second execution when the current leader is Raiku-enabled
* Falls back to Jito / priority fees when the current leader is non-Raiku
* Use cases: opportunistic MEV, HFT, reactive trades

### Raiku Stake Coverage Constraint

Raiku can only operate during slots led by opted-in validators. Because Solana's leader schedule is fixed per epoch, the percentage of network stake opted in to Raiku directly determines coverage.

| Raiku stake | Raiku slots / min | Avg gap between Raiku windows |
| ----------- | ----------------- | ----------------------------- |
| 10%         | \~15              | 14.4 s                        |
| 30%         | \~45              | 4.7 s                         |
| 50%         | \~75              | 1.6 s                         |

During gaps, JIT falls back to Jito / priority fees. AOT is only usable for slots a Raiku validator will lead.

***

## Cost Analysis

### Scenario-Based Pricing (modeled from Solana data)

Raiku's own simulator uses four scenarios, each derived from historical priority-fee + MEV-tip data (not Raiku bids).

| Scenario                  | Modeled fee/CU | Source methodology                              |
| ------------------------- | -------------- | ----------------------------------------------- |
| **Current Market**        | 0.10 lam/CU    | 30-day p25 of active payers + 0.10 floor (n=83) |
| **Last 12 Months**        | 1.50 lam/CU    | 30-day CU-weighted non-base mean (n=117)        |
| **Last 24M + Congestion** | 2.00 lam/CU    | 30-day CU-weighted total-fee mean (n=117)       |
| **Bull Case**             | 3.50 lam/CU    | 30-day p75 of active payers (n=83)              |

### Per-Transaction Cost (200,000 CU typical)

At SOL = $100:

| Scenario                | Fee/CU   | Per-tx cost |
| ----------------------- | -------- | ----------- |
| Current Market          | 0.10 lam | \~$0.002    |
| Last 12 Months          | 1.50 lam | \~$0.030    |
| Elevated / Congestion   | 2.00 lam | \~$0.040    |
| Bull Case (at $250 SOL) | 3.50 lam | \~$0.175    |

Traditional Solana priority fees typically land in **$0.00025–$0.001** during normal periods and can spike to **several dollars** during acute congestion. Raiku's predictability matters most during spikes.

### Key Pricing Insight

**JIT is always at least 5% more expensive than the prevailing priority fee** — Raiku JIT is never cheaper than Jito for the same slot.

**AOT pricing depends on auction dynamics** — can be lower than priority fees (if demand is thin), equal, or higher (if multiple bidders compete for the same slot). Raiku's "AOT discount" marketing is not guaranteed.

**Raiku's value is certainty, not raw cost reduction.** Enterprises paying the \~5% premium are buying inclusion guarantees, not cheaper execution.

***

## Execution Certainty

### Claimed Metrics

* **99.9%+ inclusion rate** within Raiku-controlled slots
* **Sub-50ms pre-confirmation** via the coordination engine
* **Atomic execution** — transactions succeed as a unit or not at all
* **No drops under congestion** for pre-reserved AOT transactions

### Realistic Limitations

* These guarantees apply **only to slots led by Raiku validators**
* During non-Raiku slot gaps, applications still depend on Jito or priority fees
* Network-wide coverage scales with Raiku validator adoption

***

## Who Should Consider Raiku

### Raiku's Stated Target Segments

Raiku's public positioning targets use cases that demand **predictable, low-latency execution**:

* **High-frequency trading platforms**
* **AI / ML coordination systems**
* **Decentralized physical infrastructure (DePIN)**
* **Gaming applications requiring real-time state updates**

### Dawn Labs' Analysis — Practical Fit

Layering Raiku's positioning against observed Solana fee data, we see three tiers of practical fit:

**Strong fit** — execution failure is expensive:

* MEV / arbitrage — timing-critical, high fee tolerance
* Perpetuals liquidations — failed liquidations cascade into protocol risk
* Oracle updates — specific-slot delivery required
* NFT launches — launch-time inclusion is the product
* Institutional settlement — predictable execution windows for accounting

**Marginal fit**:

* DEX / AMM swaps — useful during volatility, priority fees fine in normal conditions
* Lending routine operations — only liquidation paths benefit materially

**Poor fit**:

* Retail payments / transfers — Raiku premium not economically justified
* Bulk batch processing with loose timing — priority fees remain cheaper

### Customer Category Positioning

Historical Solana data shows clear stratification in fee-per-CU willingness. AOT auctions favor high-fee-tolerant categories; lower-tolerance categories risk being outbid.

| Category (from Solana data)         | Typical non-base fee/CU | AOT positioning                                     |
| ----------------------------------- | ----------------------- | --------------------------------------------------- |
| Proprietary AMM / MEV               | 7.25 lam/CU             | Top of auction — reliably wins slots                |
| Lending (with liquidations)         | \~2.0 lam/CU            | Competitive                                         |
| Payments                            | \~1.08 lam/CU           | Mid-tier — risks being outbid in competitive blocks |
| DEX / Perps / Bridge / NFT / Gaming | < 1 lam/CU              | Bottom — likely outbid during congestion            |

Enterprises should benchmark their current priority-fee spend against this distribution before committing to AOT strategy.

***

## Decision Framework for Enterprises

Before engaging with Raiku, answer these questions:

1. **What is the cost of one failed transaction?** If low ($1–10), Raiku's premium is hard to justify. If high (lost MEV, cascading liquidation, broken SLA), Raiku may be cheap insurance.
2. **Do you need specific-slot execution?** Only AOT can deliver this. If "soon" is fine, JIT or regular priority fees suffice.
3. **How congestion-sensitive are you?** Raiku's biggest advantage appears during spikes — when priority fees 10x, AOT locked at auction price stays fixed.
4. **Can you absorb a 5–15% fee premium?** If margins are thin (payments, retail), no. If margins are fat (MEV, trading), yes.
5. **Where does your fee profile sit in the distribution?** Check Category Explorer or your own on-chain data. If your typical fee/CU is below 1 lamport, AOT auctions may consistently outbid you.

***

## Integration Path

| Phase                | Status      | Action                                              |
| -------------------- | ----------- | --------------------------------------------------- |
| **Testnet / devnet** | Ongoing     | Build against published SDK, benchmark in simulator |
| **Mainnet**          | 2026 target | Production deployment                               |

***

## Limitations & Caveats

* **All pricing is pre-launch.** There are no observed AOT bid prices — every figure is a proxy from Solana priority-fee history.
* **The simulator is a scenario tool, not a price guarantee.** Run your own sensitivity analysis with conservative assumptions.
* **Non-Raiku slot fallback remains necessary.** Any production integration needs a Jito / priority-fee path for gaps.
* **JIT pricing floor (priority fee × 1.05) means Raiku is never cheaper than Jito for the same slot.** Cost advantages come from AOT discounts or avoided congestion-spike exposure.

***

## Resources

| Resource                  | URL                                                                                                     | Purpose                   |
| ------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------- |
| Raiku main site           | [raiku.com](https://www.raiku.com/)                                                                     | Product overview          |
| Documentation             | [docs.raiku.com](https://docs.raiku.com/)                                                               | Technical specs, SDK docs |
| Revenue Simulator         | [raiku-protocol.github.io/raiku-simulator](https://raiku-protocol.github.io/raiku-simulator/index.html) | Scenario modeling         |
| Simulator guide           | [raiku-simulator/guide.html](https://raiku-protocol.github.io/raiku-simulator/guide.html)               | Methodology, data sources |
| Slot Marketplace overview | [raiku.com/technology/slot-marketplace](https://www.raiku.com/technology/slot-marketplace)              | Auction mechanics         |

***

## How Dawn Labs Can Help

For enterprises evaluating Raiku, Dawn Labs can:

* **Collaboratively assess Raiku's fit for your use case** — working through your execution requirements, fee profile, and volume together to determine whether AOT, JIT, or traditional priority fees best serve each workflow
* **Facilitate Raiku BD engagement** and early-access discussions
* **Integrate Raiku SDK paths** into existing Solana operations once mainnet lands

***

{% hint style="info" %}
**Last reviewed**: April 2026. Figures and Raiku status may change as mainnet approaches — re-verify with Raiku's official channels before making commitments.
{% endhint %}


# DoubleZero

A reference guide for enterprises evaluating **DoubleZero Edge** — a dedicated high-performance network that delivers Solana raw market data to latency-sensitive trading operations.

{% hint style="info" %}
**Status (April 2026)**: DoubleZero Edge is **live and generally available** with permissionless onboarding. Performance figures below reflect DoubleZero's published claims; no third-party audited SLA is currently published.
{% endhint %}

***

## What DoubleZero Edge Is

DoubleZero is a permissionless high-performance network built on otherwise-unused private fiber capacity. **DoubleZero Edge** is its first productized service: it distributes **raw Solana block data (shreds)** from validators to subscribers over a dedicated multicast network — bypassing the public internet and traditional relay trees.

The mental model is **traditional finance market data distribution**, applied to Solana:

* Publisher (validator) sends once → network fans out to all subscribers simultaneously
* No gossip propagation, no CDN caching, no peer-to-peer relay hops
* Deterministic path over dedicated fiber, not best-effort internet

|                      | Public Solana Infrastructure         | DoubleZero Edge                   |
| -------------------- | ------------------------------------ | --------------------------------- |
| **Delivery network** | Public internet, gossip propagation  | Dedicated fiber, multicast        |
| **Data type**        | Structured RPC / streaming responses | Raw shreds (pre-parse)            |
| **Fanout model**     | Peer-to-peer relay                   | Publisher → network → subscribers |
| **Pricing**          | Subscription to managed API          | Per-epoch USDC seat, regional     |
| **Target user**      | Broad developer base                 | Latency-sensitive trading         |

***

## Business Positioning

DoubleZero Edge is **not a general-purpose infrastructure product**. It is narrowly engineered for use cases where **milliseconds of read-path advantage translate into measurable P\&L**.

### What DoubleZero Edge is NOT

* **Not an RPC replacement** — cannot read wallet balances, program state, or account data
* **Not a transaction submission service** — optimizes data arrival, not transaction landing (Jito / Helius Sender still required for write-path)
* **Not a managed SaaS** — no API-key-to-endpoint onboarding
* **Not a dApp developer product** — general application teams gain little from raw shred access

### What it augments

* Sits **alongside**, not instead of, QuickNode / Alchemy / Helius / Triton — firms retain those for RPC and structured streaming, and add DoubleZero as the primary low-latency read path
* Most direct comparison in the Solana ecosystem is Jito ShredStream (raw shred feed for trading)

***

## Use Case Fit

### Strong fit — where Edge delivers material value

| Use case                                     | Why Edge matters                                                                          |
| -------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **High-frequency trading on Solana**         | Earlier access to leader-produced shreds translates into fill rate and slippage reduction |
| **Market makers / proprietary AMMs**         | Earlier view of order flow tightens quoting and reduces adverse selection                 |
| **Quantitative / algorithmic trading firms** | Deterministic, low-jitter feed improves backtest-to-production parity                     |
| **MEV searchers**                            | Earlier mempool-equivalent data widens the extractable opportunity window                 |
| **Cross-exchange arbitrage desks**           | Reduces Solana-side latency inside a multi-venue latency budget                           |

Launch subscribers announced by DoubleZero include Jito Labs, Harmonic, Staking Facilities, and Triton One — all latency-sensitive infrastructure operators.

### Poor fit — where Edge is misaligned or overkill

* **Wallet apps, consumer dApps, marketplaces** — public RPC is sufficient; raw shred handling is operational overhead without benefit
* **Indexers and analytics platforms** — structured streaming APIs (Helius LaserStream, QuickNode Yellowstone) are purpose-built for this and more cost-efficient
* **Transaction submission optimization** — Edge does not improve write-path; Jito / Helius Sender / premium RPC remain the answer
* **Thin-margin transaction flow** — seat pricing is calibrated to trading economics, not retail or payments volume

### Evaluation heuristic

Ask: **"Would 10–30 milliseconds of earlier market data change a trade decision we make today?"**

* If yes → Edge is worth evaluating
* If no → incremental latency will not justify the integration burden

***

## What Adopters Get

### Published performance claims

* **\~28 ms faster shred delivery at p95**, measured across 50,000 slots against a public-internet baseline
* **\~90 % win rate** in slots where a DoubleZero-connected validator is the leader (official figure)
* **30+ metros globally**, regionally priced
* **\~45 % of Solana stake** publishing to Edge; **\~52 %** connected to DoubleZero network overall

### Economic model

* **Per-seat, per-epoch, per-device** pricing in USDC
* **Dynamic and regional** — prices vary by metro and device, recalculated each epoch
* **Permissionless onboarding, no minimum commitment**
* **Seat tenure depends on escrow** — funding monitoring is an operational requirement

### What's in the feed

* Raw Solana shreds — pre-parse, pre-dedup
* Subscribers run on-prem infrastructure to receive, deduplicate, and decode
* Feed is license-restricted to internal use; retransmission or resale is not permitted

***

## Integration Reality

DoubleZero Edge is **infrastructure-grade, not application-grade**. Adoption requires:

* **Network engineering capability** — public IPv4, dedicated tunnels, routing configuration, firewall exceptions
* **Linux host operations** — daemon process integrated into kernel networking
* **On-chain wallet operations** — seat purchase, renewal, and tenure monitoring
* **Custom receive pipeline** — organizations build their own shred ingestion, dedup, and decode stack; reference examples exist but there is no turnkey SDK

Organizations with existing low-latency trading infrastructure (co-located servers, dedicated network ops, packet-level processing) will find Edge a natural extension. Organizations accustomed to managed cloud APIs face a significant operational lift.

**Recommended deployment pattern**: Add Edge as a **parallel read-path** alongside existing RPC / streaming. Existing infrastructure continues to serve RPC queries and transaction submission; Edge delivers the latency-critical market data feed into the strategy engine.

***

## Maturity & Risk Considerations

Decision-makers should weigh the following before committing:

* **No published SLA** — operational dashboards exist, but no formal uptime guarantee, service credits, or remediation terms
* **Limited public audit trail** — no formal third-party security audit of Edge-specific components currently published
* **Roadmap vs. shipping features** — the DoubleZero whitepaper describes programmable edge filtration, DDoS mitigation, state sync, and MEV support; Edge today ships the raw Solana shred market data feed. Evaluate against what is live, not what is planned
* **New vendor dependency** — a dedicated network provider on a critical data path should be reflected in business continuity planning

### Signaled expansion

DoubleZero has indicated intent to extend Edge beyond Solana shreds to:

* Other blockchain feeds
* Centralized exchange (CEX) market data
* Prediction market data
* Traditional exchange order-by-order feeds

If realized, Edge repositions itself as a **cross-market data distribution platform** rather than a Solana-specific product. Enterprises with multi-venue trading operations should track this trajectory.

***

## Decision Framework for Enterprises

1. **Is sub-100 ms Solana data latency a revenue-linked constraint?** If no, Edge is not the product
2. **Do we have in-house network engineering?** If no, integration cost likely exceeds benefit
3. **Can we absorb a read-path-only product?** Edge solves one layer — RPC procurement and transaction submission infrastructure are still required
4. **What is our Solana leader / stake exposure?** Higher exposure amplifies Edge's value on the publisher side
5. **Are we comfortable without a formal SLA today?** Mission-critical use typically wants contractual uptime guarantees; Edge does not yet publish them

***

## Resources

| Resource        | URL                                                      | Purpose                    |
| --------------- | -------------------------------------------------------- | -------------------------- |
| DoubleZero Edge | [doublezero.xyz/dz-edge](https://doublezero.xyz/dz-edge) | Official Edge product page |

***

## How Dawn Labs Can Help

For enterprises evaluating DoubleZero Edge, Dawn Labs can:

* **Assess use case fit** — working through your trading workflow, latency sensitivity, and read-path architecture to determine whether Edge delivers material value
* **Benchmark against existing infrastructure** — measure current data-path latency and model Edge's delta in the context of your strategy P\&L
* **Facilitate DoubleZero engagement** — subscriber onboarding, seat procurement, and validator publisher setup
* **Operate the receive stack** — deploy and monitor the DoubleZero daemon, tunnel, and shred ingestion pipeline alongside existing Solana infrastructure

***

{% hint style="info" %}
**Last reviewed**: April 2026. Figures and roadmap items may change; re-verify with DoubleZero's official channels before making commitments.
{% endhint %}


# Disclaimer

**Last updated: March 2026**

## General Disclaimer

Dawn Vault is an experimental decentralized finance (DeFi) product operated by Dawn Labs. By using Dawn Vault, you acknowledge and accept the following:

### No Investment Advice

Nothing in this documentation or on the Dawn Vault platform constitutes financial, investment, legal, or tax advice. The information provided is for informational purposes only. You should consult with qualified professionals before making any investment decisions.

### No Guarantee of Returns

* Past performance does not guarantee future results
* Advertised APY figures are estimates based on historical data and current market conditions
* Actual returns may be higher or lower than projected
* Loss of deposited funds is possible
* The Yield Smoothing Reserve does not guarantee any minimum return

### Risk Acknowledgment

By depositing into Dawn Vault, you acknowledge that you understand and accept the risks described in our [Risk & Security](/dawn-vault/risk-and-security), including but not limited to:

* Smart contract vulnerabilities
* Market and funding rate risk
* Liquidation risk
* Exchange and counterparty risk
* Oracle manipulation risk
* Operational and infrastructure risk
* Liquidity risk
* Regulatory risk
* Solana network risk

### Experimental Software

Dawn Vault is experimental software. The smart contracts, while built on audited frameworks, may contain bugs or vulnerabilities. You should not deposit more than you can afford to lose.

### Non-Custodial Nature

Dawn Vault operates on a non-custodial basis. While this provides security benefits, it also means:

* You are solely responsible for the security of your wallet and private keys
* Lost private keys cannot be recovered
* Transactions on the Solana blockchain are irreversible

### Regulatory Status

Dawn Vault is not registered with or approved by any financial regulatory authority. The regulatory status of DeFi products is uncertain and evolving. Users are responsible for ensuring their use of Dawn Vault complies with applicable laws in their jurisdiction.

### Limitation of Liability

To the maximum extent permitted by law, Dawn Labs and its contributors shall not be liable for any direct, indirect, incidental, special, consequential, or exemplary damages arising from:

* Use of or inability to use Dawn Vault
* Loss of funds deposited in Dawn Vault
* Unauthorized access to or alteration of your data
* Any third-party conduct or content

### Changes

Dawn Labs reserves the right to modify vault parameters, strategies, fee structures, and these terms at any time. Significant changes will be communicated through official channels.

### Jurisdiction

Some jurisdictions may restrict access to DeFi products. It is your responsibility to ensure you are legally permitted to use Dawn Vault in your jurisdiction.

***

*By using Dawn Vault, you acknowledge that you have read, understood, and agree to this disclaimer.*