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.

Pool Parameters

Pool ID	Deposit Size (SOL)	Capacity (SOL)	Trigger Action
1	0.10	100	Open Pool 2
2	0.30	150	Open Pool 3
3	0.60	210	Open Pool 4
4	1.20	360	Open Pool 5
5	2.40	480	Open Pool 6
6	4.80	—	Final tier, no further pools

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

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.