Liquidity Pool

The Aureus protocol automatically grows its own AUR/SOL liquidity by seeding a Meteora DLMM pool with protocol revenue. This creates a constantly deepening liquidity floor for AUR, funded entirely by arena activity — no team LPing required.

Architecture

graph TD
  MATCHES["Matches Scored"] -->|"10% protocol cut"| PROTOCOL["Protocol Revenue"]
  PROTOCOL -->|"40%"| LP_FUND["LP Fund<br/>(arena.lp_fund)"]
  LP_FUND -->|"threshold reached"| DEPLOY["DeployLiquidity<br/>(permissionless)"]
  DEPLOY --> WSOL["Vault wSOL ATA"]
  WSOL -->|"syncNative"| SYNC["Balance Updated"]
  SYNC -->|"ExecuteMeteoraLP"| METEORA["Meteora DLMM Pool<br/>AUR/SOL"]
  METEORA -->|"swap activity"| FEES["Trading Fees Accrue"]
  FEES -->|"ClaimPoolFees"| STAKERS["Staker Reward Pool"]

How It Works

1. LP Fund Accumulates

Every scored match routes 40% of the protocol's 10% cut into arena.lp_fund:

Per match: 0.02 SOL × 10% × 40% = 0.0008 SOL added to LP fund

2. Threshold Reached → Deploy

Once lp_fund exceeds the deployment threshold, anyone can trigger deployment. This is fully permissionless — no admin key needed.

3. Multi-Instruction Transaction

Deployment happens as a single atomic transaction with three instructions:

graph LR
  subgraph TX["Single Transaction"]
    IX1["IX 1: DeployLiquidity<br/>(transfer SOL → wSOL ATA)"] --> IX2["IX 2: syncNative<br/>(update wSOL balance)"]
    IX2 --> IX3["IX 3: ExecuteMeteoraLP<br/>(CPI → Meteora add_liquidity)"]
  end

Why three instructions? Solana's runtime prevents mixing direct lamport manipulation with CPIs in a single instruction (UnbalancedInstruction error). Splitting them across instructions in the same transaction keeps atomicity while respecting runtime rules.

4. One-Sided Liquidity

The protocol adds one-sided SOL liquidity — it doesn't need to pair SOL with AUR tokens. This avoids diluting AUR supply and uses all accumulated SOL efficiently:

• SOL goes into bins below the current active price
• When AUR price rises, sell pressure is absorbed by this SOL
• When AUR price drops, the SOL converts to AUR (buying the dip automatically)

5. Fee Collection — Both Tokens

Swap activity on the DLMM pool generates trading fees in both AUR and SOL. Anyone can call ClaimPoolFees (IX 14) to:

1. Update fee accruals — CPI into Meteora's update_fees_and_rewards
2. Claim fees — CPI into Meteora's claim_fee, transferring both tokens to vault ATAs
3. Route by token type:

• wSOL fees → staker_reward_pool (distributed to AUR stakers). If no stakers exist, redirected to T1 SOL jackpot.
• AUR fees → swap_fee_aur_jackpot → added to T1 token jackpot when triggered (transferred from vault ATA, not re-minted)

graph LR
  SWAP["DEX Traders<br/>swap AUR ↔ SOL"] -->|"trading fees"| POS["DLMM Position<br/>(vault PDA owns)"]
  POS -->|"ClaimPoolFees IX"| CPI["CPI: update_fees<br/>+ claim_fee"]
  CPI --> SPLIT{"Token type?"}
  SPLIT -->|"wSOL"| CHECK{"Stakers exist?"}
  CHECK -->|"Yes"| STAKERS["staker_reward_pool"]
  CHECK -->|"No"| JP["T1 SOL Jackpot"]
  SPLIT -->|"AUR"| JACKPOT["T1 token_jackpot"]

Meteora DLMM

The protocol uses Meteora's DLMM (Dynamic Liquidity Market Maker) for concentrated liquidity:

Why DLMM?

• Concentrated liquidity — Capital efficiency far exceeds constant-product AMMs
• On-chain position — The vault PDA owns the position directly, no delegation
• Fee capture — Trading fees flow back to the protocol (and stakers)
• Composable — All interactions are CPIs, fully auditable on-chain

Position Management

InitPoolPosition (IX 12)

Creates a Meteora DLMM position owned by the vault PDA:

Example: lower_bin_id = -35, width = 70
→ Position covers bins -35 to +35 (70 bins around active price)

The position is created via CPI into Meteora's initialize_position with the vault PDA as the owner (signer).

Bin Arrays

Each bin range requires initialized bin array PDAs. The protocol creates these during setup:

graph LR
  BA_NEG["Bin Array -1<br/>(bins -70 to -1)"] --> POS["Position<br/>(bins -35 to +35)"]
  BA_0["Bin Array 0<br/>(bins 0 to +69)"] --> POS

Instructions Reference

DeployLiquidity (IX 11)

Data: [11] — No additional parameters needed.

InitPoolPosition (IX 12)

Data: [12, lower_bin_id_i32_le, width_i32_le]

ExecuteMeteoraLP (IX 13)

Data: [13, amount_u64_le, active_id_i32_le]

ClaimPoolFees (IX 14)

Data: [14] — No additional parameters.

Security Properties

• Trustless — All instructions are permissionless. No admin key can redirect funds.
• Atomic — The 3-instruction deploy TX either fully succeeds or fully reverts.
• Non-custodial — The vault PDA owns the position. Private keys never touch LP funds.
• Front-running resistant — LP deployment uses the accumulated fund, not user tokens.
• No dilution — One-sided SOL liquidity means no extra AUR is minted for LP.

Lifecycle Summary

graph TD
  A["Arena matches<br/>generate protocol revenue"] --> B["40% goes to<br/>lp_fund"]
  B --> C{"lp_fund ><br/>threshold?"}
  C -->|"No"| A
  C -->|"Yes"| D["Anyone calls<br/>DeployLiquidity TX"]
  D --> E["SOL added to<br/>Meteora DLMM pool"]
  E --> F["Trading generates<br/>swap fees"]
  F --> G["Anyone calls<br/>ClaimPoolFees"]
  G --> H1["wSOL fees →<br/>staker_reward_pool"]
  G --> H2["AUR fees →<br/>T1 token jackpot<br/>(transfer-based)"]
  H1 --> I["Stakers earn<br/>more SOL"]
  H2 --> J["Jackpot grows<br/>(1/500 trigger)"]
  I --> A
  J --> A

The result is a self-reinforcing flywheel: more matches → more liquidity → more trading → more fees → stakers earn SOL + jackpot pool grows → more demand for AUR → more matches.