Liquidity  Pools

Solnet AI on‑boards capital through six sequential Liquidity  Pools. Each pool is an isolated, non‑custodial vault contract with:

• a fixed deposit size (SOL per deposit transaction);

• a target capacity (total SOL that must be locked);

• an auto‑toggle flag; when the capacity is reached, the vault status changes from FILLING to ACTIVE, its liquidity is injected into the AI execution grid, and deposits are redirected to the next pool in line

Example

Pool 1 accepts deposits of exactly 0.10 SOL. Once the on‑chain counter reaches 1 000 deposits (≙ 100 SOL), Pool 1 flips to ACTIVE. The runtime emits an PoolOpened(2) event, and the front‑end automatically switches the default deposit target to Pool 2.

Why Progressive Pools?

Design Goal

Granular risk curves

Smaller pools (< Pool 3) can run tighter leverage and faster re‑hedging; larger pools inherit wider collateral buffers.

Deterministic PnL attribution

Each pool's position set is tracked independently, allowing the accounting module to stream net returns only to the wallets that funded that pool.

Gas‑efficient scaling

New liquidity enters in parallel vaults rather than bloating a single mega‑contract keeping execution costs low as TVL rises.

Fair user flow

Early stakers enjoy first‑mover access without the slippage that oversized trades introduce; later stakers are gated into pools sized for higher liquidity throughput.

State Machine per Pool

Copy

stateDiagram-v2
    [*] --> FILLING
    FILLING --> ACTIVE: capacityReached()
    ACTIVE --> CLOSED: governanceClose()
    CLOSED --> [*]

• FILLING - accepts deposits.

• ACTIVE - deposits locked; liquidity bridged into AI engine; accrues yield.

• CLOSED - (edge‑case) pool can be sunset via DAO vote once all funds are withdrawn.