Global Unified Liquidity Pool — Layer 4

Section 4: Global Unified Liquidity Pool — Layer 4

RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-LP-SPEC-001 v2.0

The Global Unified Liquidity Pool ("Global Pool") is the platform's protocol-owned permanent liquidity infrastructure. A single shared CPMM pool serves all three modules (Equities, Real Estate, CORECM). LP tokens representing the protocol's pool position are burned at inception. The pool is non-extractable: Certora invariant E.3 formally proves no execution path exists by which the pool's reserves can be debited to a withdrawal destination.

---

4.1 Architectural Position and Purpose

The Global Pool occupies Layer 4. It depends on Layer 1 (Solana), Layer 2 (Transfer Hook — every pool interaction is a transfer subject to controls), Layer 3 (Core Protocol PDAs), and Layer 6 (oracle freshness signals). It is consumed by Layer 5 (CEDEX matching/settlement).

Property	Value
Pool design	Single shared CPMM serving all three modules
Stablecoin reserve	USDC + PYUSD aggregate balance
ST22 reserve	Cross-module token-mix (M1 + M2 + M3 mints)
LP tokens	Burned at inception
Withdrawal mechanism	None (Certora E.3)
Self-reinforcement	0.44% of every CEDEX trade adds to permanent locked reserve
Cross-module network effect	Volume in any module deepens liquidity for all modules

---

4.2 Why Protocol-Owned, Permanent Liquidity

4.2.1 The Market-Maker Withdrawal Problem

Conventional ATS / DEX architectures rely on third-party market makers to provide bid/ask liquidity. Market makers can withdraw at any time. Withdrawal is the single largest source of liquidity-collapse risk in tokenized-securities trading. Empirical events:

• Securitize Markets ATS — multiple per-issuer market-maker withdrawal events documented across 2024–2025

• Republic Block ATS (CrowdSafe) — sustained periods of zero bid liquidity for listed issuers

• INX exchange — multiple delistings driven by market-maker exit

• ERC-3643 secondary markets — heavy reliance on issuer-funded liquidity that depletes over time

The platform's architectural answer is: eliminate the market-maker entirely. The Global Pool is the market maker. It cannot withdraw because the LP tokens are burned and there is no withdrawal function.

4.2.2 Certora Invariant E.3 — Pool Non-Extractability

The Certora Prover suite formally proves invariant E.3:

E.3 Statement: For all possible execution traces of the platform's Solana programs, no instruction sequence exists that debits the Global Pool's reserves to any account other than (a) a buyer's wallet receiving ST22 from a swap, or (b) a seller's wallet receiving stablecoin from a swap, both subject to the constant-product invariant x · y ≥ k being preserved post-trade modulo accumulated fees.

The proof covers:

• The liquidity_pool program — verified that no withdraw_lp_tokens instruction exists, and that no instruction debits reserves outside swap-in-fee-out flows

• The amm program — verified that swap math preserves x · y ≥ k

• The governance program — verified that no governance proposal type can mint new LP tokens or create a withdrawal pathway

• Upgrade authority — verified that the program upgrade authority's permitted operations cannot introduce a withdrawal function (program logic that would do so is rejected by the timelock-policy specification)

This is what makes "the pool cannot rugpull" a mathematical guarantee rather than a marketing claim.

---

4.3 Pool Schema and Account Architecture

4.3.1 LiquidityPool PDA

#[account]
pub struct LiquidityPool {
    pub version:                u8,         // 10
    pub authority:              Pubkey,     // 3-of-5 multi-sig (config only — cannot withdraw)
    pub stablecoin_reserve:     u64,        // USDC + PYUSD aggregate, in 1e6 base units
    pub st22_reserve:           u64,        // Aggregate ST22 reserve across modules (in mint-base units)
    pub k_invariant:            u128,       // Last-recorded k = stablecoin_reserve · st22_reserve
    pub permanent_locked_share: u64,        // Cumulative 0.44% locked from all trades
    pub fee_bps_total:          u16,        // 500 = 5.0%
    pub fee_bps_locked:         u16,        // 44 = 0.44%
    pub last_update_slot:       u64,
    pub bump:                   u8,
}

Note: k_invariant is recorded post-trade for monitoring. The CPMM swap path enforces x · y ≥ k at execution; deviation alerts trigger compliance review.

4.3.2 Per-Mint Pool Accounting

The shared pool tracks per-mint position via inner accounting:

#[account]
pub struct PoolMintPosition {
    pub mint:                   Pubkey,
    pub module:                 Module,     // 1, 2, or 3
    pub st22_balance:           u64,        // ST22 of this mint held in pool reserves
    pub cumulative_volume:      u128,       // Lifetime trading volume against this mint
    pub cumulative_fees_locked: u64,        // Cumulative 0.44% locked from this mint's trades
    pub last_update_slot:       u64,
    pub bump:                   u8,
}

Per-mint PoolMintPosition accounts are PDAs seeded by [b"pool-mint", mint.key().as_ref()].

---

4.4 Pool Initialization and Seeding

4.4.1 Seeding Sources

The pool is initialized at platform genesis with seed liquidity from five sources:

Source	Mechanism	Approximate Magnitude
1. Groovy Security Token (STO) proceeds	$20M Reg D raise; net proceeds routed to Solana Treasury → Global Pool	$20M
2. Initial Staking Pool allocation	Designated portion of pre-graduation staking accumulation	Variable
3. CEDEX permanent lock	0.44% of every CEDEX trade from inception	Cumulative; growing
4. Investor secondary sale proceeds	Optional — issuers can route a portion of secondary-sale fees to the pool	Per-issuer election
5. Staking reward reinvestment	2% of staking rewards reinvested into pool depth	Variable

4.4.2 LP Burn at Inception

// Pseudo-code: pool initialization with LP burn
pub fn initialize_pool(
    ctx: Context<InitializePool>,
    initial_stablecoin: u64,
    initial_st22_seed_amounts: Vec<(Pubkey, u64)>,  // (mint, amount) pairs
) -> Result<()> {
    // 1. Validate authority (3-of-5 multi-sig + timelock for governance)
    require!(verify_multisig(...), Error::Unauthorized);

    // 2. Transfer stablecoin reserves into pool PDA
    transfer_stablecoin_to_pool(ctx.accounts.source_stable, ctx.accounts.pool_stable_vault, initial_stablecoin)?;

    // 3. Transfer ST22 seed amounts (per-mint)
    for (mint, amount) in initial_st22_seed_amounts {
        transfer_st22_to_pool(mint, amount)?;
        // Initialize PoolMintPosition for this mint
        init_pool_mint_position(mint, amount)?;
    }

    // 4. Mint LP tokens to platform
    let lp_minted = compute_initial_lp_supply(initial_stablecoin, initial_st22_seed_amounts);
    mint_lp_to(ctx.accounts.platform_lp_account, lp_minted)?;

    // 5. **BURN ALL LP TOKENS**
    burn_lp_tokens(ctx.accounts.platform_lp_account, lp_minted)?;
    // After this point, lp_supply = 0
    // No execution path exists to withdraw reserves — Certora E.3

    // 6. Record invariant
    let pool = &mut ctx.accounts.pool;
    pool.stablecoin_reserve = initial_stablecoin;
    pool.st22_reserve = initial_st22_seed_amounts.iter().map(|(_, a)| *a).sum();
    pool.k_invariant = (pool.stablecoin_reserve as u128) * (pool.st22_reserve as u128);

    Ok(())
}

// CRITICALLY: there is NO `withdraw_liquidity` instruction in the program.
// Removing this instruction from the program is what makes E.3 hold.

---

4.5 CPMM Swap Math (Pool-Specific)

The pool implements the same CPMM math documented in Section 7 (CEDEX) but at the pool-program level. The swap is initiated by CEDEX's amm program; the liquidity_pool program is the counterparty:

// Swap: stablecoin in, ST22 out (buy direction)
pub fn swap_buy(
    ctx: Context<SwapBuy>,
    mint: Pubkey,             // ST22 mint being bought
    stablecoin_in: u64,
    min_st22_out: u64,        // slippage protection
) -> Result<()> {
    let pool = &mut ctx.accounts.pool;
    let pool_mint = &mut ctx.accounts.pool_mint_position;

    // Invariant pre-check
    let x_pre = pool.stablecoin_reserve as u128;
    let y_pre = pool_mint.st22_balance as u128;
    let k_pre = x_pre.checked_mul(y_pre).ok_or(Error::Overflow)?;

    // Fee math
    let fee_factor = 10_000u128 - 500u128; // 9500 (5% total fee deducted)

    let stablecoin_in_u128 = stablecoin_in as u128;
    let numerator = y_pre
        .checked_mul(stablecoin_in_u128).ok_or(Error::Overflow)?
        .checked_mul(fee_factor).ok_or(Error::Overflow)?;
    let denominator = x_pre
        .checked_mul(10_000).ok_or(Error::Overflow)?
        .checked_add(stablecoin_in_u128.checked_mul(fee_factor).ok_or(Error::Overflow)?)
        .ok_or(Error::Overflow)?;
    let st22_out = numerator.checked_div(denominator).ok_or(Error::DivisionByZero)? as u64;

    // Slippage check
    require!(st22_out >= min_st22_out, Error::SlippageExceeded);

    // Execute transfer (subject to Transfer Hook on the ST22 leg)
    transfer_stablecoin(stablecoin_in)?;
    transfer_st22(mint, st22_out)?;  // ← Token-2022 invokes Transfer Hook here

    // Update reserves
    pool.stablecoin_reserve += stablecoin_in;
    pool_mint.st22_balance -= st22_out;

    // Distribute the 5% fee (see Section 7.5.2)
    let fee_total = stablecoin_in.checked_mul(500).ok_or(Error::Overflow)? / 10_000;
    distribute_fees(fee_total, ctx)?;

    // 0.44% portion stays in the pool — this is the permanent lock mechanic
    let locked_portion = stablecoin_in.checked_mul(44).ok_or(Error::Overflow)? / 10_000;
    pool.permanent_locked_share += locked_portion;
    pool_mint.cumulative_fees_locked += locked_portion;

    // Invariant post-check (modulo locked portion)
    let x_post = pool.stablecoin_reserve as u128;
    let y_post = pool_mint.st22_balance as u128;
    let k_post = x_post.checked_mul(y_post).ok_or(Error::Overflow)?;
    require!(k_post >= k_pre, Error::InvariantViolation);

    pool.k_invariant = k_post;
    Ok(())
}

The 0.44% locked-fee portion is mathematically equivalent to "raising k" — it grows the pool's product invariant on every trade, which monotonically deepens liquidity over time.

---

4.6 Self-Reinforcing Growth Mathematics

Let V_t be cumulative trading volume through time t, r = 0.0044 be the locked-fee rate, and L_0 be initial pool liquidity (depth). Then:

L_t ≥ L_0 + r · V_t

The pool depth strictly increases with cumulative volume. Slippage decreases as a function of pool depth, which reduces friction for institutional volume, which deepens the pool further. The dynamic is positively self-reinforcing.

For a pool with constant-product reserves x · y = k, the implied price-impact slope at a trade size Δx is approximately:

slippage(Δx) ≈ Δx / x

Doubling pool depth (x doubles) halves slippage at the same trade size. The 0.44% locked-fee rate has compounding effect over volume horizons measured in years.

---

4.7 Cross-Module Network Effect

Because the pool is shared across all three modules, trading volume in any module deepens liquidity for all modules. Concretely:

• A Module 3 BAE basin tokenization with $50M annual trading volume contributes $220K (0.44%) to the pool's permanent locked share.

• That deepening supports a Module 1 OTC microcap issuer with $500K daily volume by providing more reserve depth against slippage.

• Module 2 SAE real-estate trades benefit from the same shared depth.

This contradicts conventional AMM design, where each token pair has an isolated pool. The contradiction is intentional: it produces a cross-asset-class liquidity network effect that no per-mint or per-product pool architecture can replicate. ERC-3643 platforms (Securitize, Tokeny) and ATS architectures (Securitize Markets, INX) are per-product isolated; they cannot harvest cross-asset-class network effects.

---

4.8 Pool Health Monitoring and Alerts

Metric	Healthy Range	Alert Threshold
Pool TVL (stablecoin reserve)	Growing monotonically	Decreased TVL flag (anomaly only — pool cannot decrease through normal operation; locked-share decrease is impossible)
k_invariant	Monotonically non-decreasing	Decrease flagged → critical compliance alert
Per-mint slippage at 0.5% TVL trade	< 100 bps	> 200 bps → consider pool seeding addition
Cross-module reserve concentration	Diversified	> 80% of ST22 reserve in single mint → concentration alert
Stablecoin / ST22 ratio	Stable around long-run mean	Sharp deviation → market-condition alert
Locked share growth rate	Tracks volume × 0.44%	Deviation → fee-distribution audit

The platform's monitoring (Datadog + PagerDuty per ADR-008) emits metrics at every pool interaction. Anomalies trigger compliance officer review.

---

4.9 Pool and Transfer Hook Interaction

Every pool interaction is a transfer subject to the Transfer Hook:

Pool Action	Transfer Hook Invocation
Buy (stablecoin in, ST22 out)	Transfer Hook fires on ST22 leg from pool to buyer; all 42 controls + applicable module extensions execute
Sell (ST22 in, stablecoin out)	Transfer Hook fires on ST22 leg from seller to pool; all 42 controls + applicable module extensions execute
Initial seeding (LP burn flow)	Transfer Hook fires when ST22 enters pool from platform treasury; controls verify supply integrity

This means: a Module 2 trade against the pool will execute Control CB-21 NAV-deviation variant; a Module 3 trade against the pool will execute Control REG-42 federal-action variant; a Module 1 trade will execute only the 42 core controls. The pool itself does not implement module-aware logic; the Transfer Hook does, and the pool's swap path correctly invokes it.

---

4.10 Pool Adjacency: Staking Rewards Reinvestment

A separate but related mechanism: 2% of staking rewards are reinvested into pool depth. The staking program holds GROO Utility Token stakes; rewards accrue per the staking schedule; 2% of accrued rewards are converted (off-chain or via designated DEX) to USDC and added to the pool's stablecoin reserve. This further deepens the pool independently of CEDEX trading volume.

---

4.11 Comparison vs Alternative Liquidity Architectures

Liquidity Source	Withdrawal Risk	Depth Growth	Cross-Asset-Class	Adopted By
Third-party market maker	High — can exit at any time	Episodic / sporadic	Per-product	Securitize Markets, INX, ERC-3643 secondary markets
Issuer-funded liquidity	Medium — depletes over time	Static	Per-issuer	Tokeny secondary markets
Standard AMM LP-token holders	Medium — LPs can withdraw	Variable; LP-mediated	Per-pair	Raydium, Orca, Uniswap
Protocol-owned LP-burned pool	Zero — Certora E.3	Monotonic via 0.44% lock	Cross-module	RWA Tokens platform

---

4.12 The Liquidity Pool and Category 1 Model B

Category 1 Model B does not directly mandate a particular liquidity architecture. However, the Joint Staff Statement of January 28, 2026 emphasizes "investor protection at every transfer." A trading venue without sustained liquidity exposes investors to:

• Inability to exit positions

• Price discovery failure

• Pseudo-trading without true willingness-to-trade

• Pump-and-dump structural vulnerability

The Global Pool's permanence and Certora E.3 non-extractability eliminate these risks at the architectural level. The pool is one of the components that elevates the platform's investor-protection posture from "policy" to "structure."

---

RWA Tokens Whitepaper V10 — Section 4 — Confidential — Groovy Company, Inc.