Liquidity Layer

YNP embeds a Dynamic Peg AMM directly into the P2P layer. This serves two purposes: providing internal asset pricing for Elastic Security calculations, and enabling fee abstraction so users can pay fees in any liquid asset.

Pool State

Each pool is stored by the cluster responsible for Hash(Sort(TokenA, TokenB)):

type LiquidityPool struct {
    TokenA        AssetID
    TokenB        AssetID
    ReserveA      uint256
    ReserveB      uint256
    PriceScale    uint256   // P_scale — price where liquidity is thickest
    PriceEMA      uint256   // Exponential moving average of spot price
    VirtualPrice  uint256   // Strictly monotonically increasing LP value metric
    LastSwapTime  uint64    // Unix timestamp of most recent swap (for EMA decay)
    FeeAccA       uint256
    FeeAccB       uint256
}

Key invariants:

• VirtualPrice MUST be monotonically non-decreasing across all state transitions. Any operation that would decrease it MUST be rejected.
• PriceScale is updated only during the epoch cold path, and only when the profit gate is satisfied.
• PriceEMA is updated on every swap using a time-weighted exponential decay.

Self-Contained Dynamic Peg AMM

Unlike constant-product AMMs (x × y = k), the Dynamic Peg AMM concentrates liquidity around an algorithmically managed price peg (P_scale). Trades near P_scale experience minimal slippage; trades far from it experience progressively worse execution.

Swap Execution (Hot Path)

Swap execution is an atomic, single-round BLS process within the pool cluster C_Pool:

1. Reserve update — The pool applies the swap against the concentrated invariant curve.

2. Dynamic fee calculation — The fee scales with price deviation:

Fee_dynamic = Fee_mid + (Fee_out - Fee_mid) × f_distance(P_spot, P_scale)

Parameter	Value	Description
Fee_mid	0.1% (10 bps)	Base fee when P_spot ≈ P_scale
Fee_out	0.4% (40 bps)	Maximum fee at extreme deviation
f_distance	0 → 1	Monotonically increasing function of relative deviation

The dynamic fee acts as a thermodynamic brake — exponentially bleeding attackers of capital before they can meaningfully shift P_EMA.

3. EMA update — After every swap:

P_EMA' = P_EMA × exp(-Δt/τ) + P_spot × (1 - exp(-Δt/τ))

where Δt is elapsed seconds since LastSwapTime and τ = 600 seconds (10-minute half-life).

4. Certify — C_Pool produces a Swap Certificate attesting to the execution, dynamic fee, and updated pool state.

Profit-Gated Repagging (Cold Path)

The mechanism to shift P_scale toward P_EMA runs during the epoch settlement phase, not on the swap hot path:

1. Evaluate — Once per epoch, C_Pool checks divergence between P_scale and P_EMA.
2. Threshold — If |P_EMA - P_scale| / P_scale < ε (where ε = 0.1%), no repagging occurs.
3. Simulate — If divergence exceeds ε, the cluster simulates shifting P_scale toward P_EMA by step size α (50% of divergence per epoch, capped at 5% absolute move).
4. Virtual Price gate — The repag executes only if the new VirtualPrice >= VirtualPrice_current. If the shift would decrease VirtualPrice (algorithmic loss for LPs), it is rejected. Accumulated dynamic fees subsidize the shift.
5. Certify — A Repag Certificate attests to the P_scale update.

Fee Abstraction and Deferred Settlement

Users MAY pay fees in any liquid asset. Fees are accrued in the original asset during the transfer hot path and batch-swapped to YELLOW during the cold path.

Hot Path (Inline with Transfer)

During a transfer (see Phase II):

1. C_Sender calculates the dynamic fee in the transaction asset using P_EMA and current f_distance.
2. The fee is debited from Balances[1010][Asset] and credited to Balances[3010][Asset].
3. No swap occurs. The CreditOp Certificate attests to the fee accrual alongside the transfer.

Cold Path (Batched, Once Per Epoch)

Once per epoch, the cluster settles accrued fees:

1. Aggregate — C_User aggregates all Balances[3010] entries across assets for each user account.
2. Batch swap — C_User sends a single BatchSwap request to C_Pool (e.g., Swap(USDT → YELLOW), Swap(ETH → YELLOW)).
3. Certify — C_Pool executes the swaps and produces one Swap Certificate for the batch.
4. Distribute — The resulting YELLOW is auto-compounded into validator collateral (Balances[1040]):
   • 80% to C_sign validators — distributed equally among the k signing validators
   • 20% to C_watch \ C_sign validators — distributed equally among the r - k replication-only validators

DR  User   / 3010  Accrued Fees          fee_original
  CR  Pool   / 1030  Pool Reserve          fee_original

DR  Pool   / 1030  Pool Reserve          fee_yellow YELLOW
  CR  NodeID:S1..Sk  / 1040  Collateral   fee_yellow × 0.80 YELLOW  (C_sign)
  CR  NodeID:W1..Wr-k / 1040  Collateral  fee_yellow × 0.20 YELLOW  (C_watch \ C_sign)

LP Provisioning

Liquidity is added and removed via two additional operation types:

• AddLiquidityOp — Debits user Balances[1010] for both assets, credits pool Balances[1030], mints LP shares tracked as AssetID = keccak256("LP", TokenA, TokenB).
• RemoveLiquidityOp — Burns LP shares, debits pool Balances[1030], credits user Balances[1010] with proportional reserves.

Both operations produce Certificates and follow double-entry accounting. Initial liquidity for core pairs (USDC/YELLOW, ETH/YELLOW) is seeded by the protocol treasury at genesis.