AMM Variants - Beyond Constant Product

CONSTANT PRODUCT PROPERTIES

Formula: x × y = k

Bonding curve: Rectangular hyperbola
├── Price determined by ratio: P = y/x
├── Liquidity at ALL prices (0 to ∞)
├── Price impact proportional to trade size
└── Slippage = Δx/(x - Δx)

Strengths:
├── Simple to understand and implement
├── No configuration needed
├── Permissionless (anyone can create)
├── Guaranteed liquidity at any price
└── Battle-tested (billions in volume)

Weaknesses:
├── Capital inefficient (liquidity spread infinitely)
├── High slippage for large trades
├── Suboptimal for stable pairs
├── Same IL regardless of pair characteristics
└── No customization options
```

WHERE DOES LIQUIDITY SIT?

Constant product pool example:
├── Pool: 100,000 XRP + 250,000 RLUSD
├── Current price: $2.50
├── Liquidity exists from price = $0 to price = ∞

But most trading happens near current price:
├── 95% of trades within ±5% of current price
├── 99% of trades within ±20% of current price
├── Extreme prices almost never reached
└── Most capital sits unused

Capital efficiency calculation:
├── "Active" liquidity (within 2% of price): ~4% of TVL
├── "Used" liquidity (within 10% of price): ~20% of TVL
├── "Dead" liquidity (far from price): ~80% of TVL
└── Only 1/5 of capital doing useful work

This inefficiency motivated concentrated liquidity.
```

---

CONCENTRATED LIQUIDITY CONCEPT

Instead of spreading liquidity from 0 to ∞:
├── LP chooses a price RANGE
├── All capital concentrated within that range
├── Outside range: No liquidity (not traded)
└── Within range: Much deeper liquidity

Example:
├── Traditional: 100,000 liquidity from $0 to ∞
├── Concentrated: 100,000 liquidity from $2.00 to $3.00
├── Same capital, but ~50× more liquidity in range
└── Dramatically better execution for traders

The trade-off:
├── + Much better capital efficiency
├── + Less slippage for in-range trades
├── - No liquidity outside range
├── - LPs must manage positions
├── - More complex IL dynamics
└── - "Out of range" earns zero fees
```

CONCENTRATED LIQUIDITY MATH

Traditional constant product:
├── Virtual reserves: x, y
├── Price range: 0 to ∞
├── Liquidity: L = √(x × y)

Concentrated liquidity:
├── Price bounds: P_low to P_high
├── Virtual reserves adjusted for range
├── Same x × y = k within range
├── Liquidity multiplier: Based on range width

Efficiency gain:
├── Range ratio: r = P_high / P_low
├── Efficiency multiplier ≈ 1 / (√r - 1)
├── Tighter range = higher multiplier

Example calculations:
├── Range $2.00-$3.00 (r = 1.5): ~3× efficiency
├── Range $2.40-$2.60 (r = 1.08): ~12× efficiency
├── Range $2.49-$2.51 (r = 1.008): ~120× efficiency
└── Extreme concentration = extreme efficiency

But risk increases:
├── Narrower range = higher IL within range
├── Price exits range = position inactive
├── Requires active management
└── Not "set and forget"
```

IL IN CONCENTRATED VS TRADITIONAL

Traditional IL (from Lesson 3):
├── IL% = 1 - 2√r/(r+1)
├── At 2× price change: IL = 5.72%
└── Fixed formula regardless of position size

Concentrated IL:
├── IL multiplied by concentration factor
├── Tighter range = higher IL percentage
├── Can exceed traditional IL significantly
└── Trade-off for higher fee efficiency

Example comparison:
├── Price moves from $2.50 to $3.75 (1.5× increase)
├── Traditional IL: 2.02%
├── Concentrated ($2.00-$3.00 range): ~6% IL
├── Concentrated ($2.40-$2.60 range): ~25% IL (and position went out of range!)
└── Higher fee rate needed to compensate

The optimization:
├── More concentration = more fees per $ of TVL
├── More concentration = higher IL risk
├── Sweet spot depends on:
│ ├── Expected volatility
│ ├── Fee income
│ └── Management capability
└── No universal "right" answer
```

MANAGING CONCENTRATED POSITIONS

Passive approach (wide ranges):
├── Set range like ±50% from current price
├── Check monthly or quarterly
├── Rebalance if price exits range
├── Lower efficiency, lower effort
└── Suitable for long-term holders

Active approach (tight ranges):
├── Set range like ±5% from current price
├── Monitor daily or even hourly
├── Rebalance frequently as price moves
├── Higher efficiency, much higher effort
└── Suitable for sophisticated LPs

Professional approach:
├── Algorithmic position management
├── Auto-rebalancing on price movements
├── Multiple positions at different ranges
├── Gas costs matter (Ethereum)
└── On XRPL: Low fees make active management cheaper

Key insight:
├── Concentrated liquidity shifts AMM from passive to active
├── Professional LPs have advantage
├── Retail LPs may underperform
├── "Democratized market making" becomes specialized
└── Different game than constant product
```

---

WHY STABLECOINS NEED DIFFERENT CURVES

Problem with constant product for stablecoins:
├── USDC/USDT should both be ~$1
├── Price ratio should be ~1.0
├── Constant product assumes price could be anything
├── Provides liquidity at prices like 0.1, 10, etc.
├── Wasteful for stable pairs
└── Also: High slippage even for small trades

What we want:
├── Low slippage when prices are near 1:1
├── Price resistance (hard to move from peg)
├── Efficient capital use near peg
├── Still function if depeg occurs
└── Best of both worlds
```

CURVE'S STABLESWAP INVARIANT

Constant product: x × y = k (hyperbola)
Constant sum: x + y = k (straight line)

StableSwap: Hybrid of both
├── Near peg: Behaves like constant sum (flat curve)
├── Far from peg: Behaves like constant product (curved)
├── Amplification parameter (A) controls transition
└── Higher A = flatter curve = lower slippage near peg

The formula (simplified):
A × (x + y) + x × y = A × k + k²/4

Where:
├── A = Amplification coefficient (typically 50-500)
├── x, y = Token balances
├── k = Related to total liquidity
└── Complex but optimized for stable pairs

Behavior:
├── A = 0: Pure constant product (x × y = k)
├── A = ∞: Pure constant sum (x + y = k)
├── A = 100: Good for stablecoins
└── Higher A = less slippage but more IL risk if depeg
```

STABLESWAP vs CONSTANT PRODUCT (STABLECOIN PAIRS)

Example: Swap $1,000,000 USDC for USDT

Constant product pool ($100M TVL, 0.03% fee):
├── Slippage: ~1%
├── Execution: ~$990,000 USDT
├── Bad for large trades
└── Inefficient use of capital

StableSwap pool ($100M TVL, 0.04% fee):
├── Slippage: ~0.01%
├── Execution: ~$999,600 USDT
├── Excellent for large trades
└── Capital well-utilized

Why this matters:
├── Large stablecoin swaps are common
├── Institutional flows need low slippage
├── StableSwap dominates stablecoin DEX
├── Curve built empire on this innovation
└── $2B+ TVL at peak
```

STABLESWAP FAILURE MODES

The depeg scenario:
├── StableSwap optimized for 1:1
├── If one asset depegs (say, 0.90:1.00)
├── Curve changes shape dramatically
├── LPs can suffer massive IL
└── Worse than constant product in depegs

UST/USDC example (2022):
├── UST depegged catastrophically
├── StableSwap pools lost heavily
├── LPs left holding worthless UST
├── Amplification worked against them
└── Highlighted depeg risk

RLUSD consideration:
├── RLUSD is a new stablecoin
├── Depeg risk exists (however small)
├── StableSwap would multiply losses in depeg
├── Constant product provides some protection
└── Trade-off: Efficiency vs tail risk
```

---

MULTI-ASSET POOLS

Constant product limitation:
├── Only two assets per pool
├── Want ETH-BTC-USDC? Need multiple pools
├── Capital fragmented
└── Multiple hops for some trades

Balancer innovation:
├── Pools with 2-8 assets
├── Custom weights (not just 50/50)
├── Single pool for multiple pairs
└── More flexible LP exposure

Examples:
├── 33/33/33: ETH/BTC/USDC (equal weight)
├── 80/20: ETH/USDC (heavy ETH exposure)
├── 40/40/10/10: Four asset portfolio
└── Any combination totaling 100%
```

WEIGHTED POOL FORMULA

Generalized constant product:
∏(xᵢ^wᵢ) = k

Where:
├── xᵢ = Balance of token i
├── wᵢ = Weight of token i (sums to 1)
├── k = Constant (invariant)
└── ∏ = Product of all terms

Two-asset 50/50 example:
├── x^0.5 × y^0.5 = k
├── Equivalent to (x × y)^0.5 = k
├── Same as x × y = k²
└── Identical to standard constant product

80/20 pool example:
├── x^0.8 × y^0.2 = k
├── Price formula: P = (y/x) × (w_x/w_y)
├── = (y/x) × (0.8/0.2) = 4y/x
├── Higher weight = more exposure, less IL for that asset
└── Different risk/return profile
```

WEIGHTED POOL APPLICATIONS

Index funds:
├── Create diversified exposure
├── Single LP position = multiple assets
├── Auto-rebalancing via arbitrage
├── Example: DeFi index (5 tokens, 20% each)
└── Similar to ETF mechanics

Reduced IL exposure:
├── 80/20 pool reduces IL on the 80% asset
├── If you're bullish on XRP, 80% XRP / 20% stablecoin
├── Less IL than 50/50 if XRP goes up
├── Trade-off: Less fee income (smaller other side)
└── Strategic tool for directional views

Treasury management:
├── Projects can LP their own token
├── Example: 90% project token / 10% USDC
├── Provides trading liquidity
├── Maintains token exposure
└── Used by many DeFi projects

Liquidity bootstrapping:
├── Start with extreme weights (99/1)
├── Gradually shift toward 50/50
├── Creates price discovery mechanism
├── Used for token launches
└── Alternative to traditional ICO/IDO
```

---

CONSTANT SUM: x + y = k

Properties:
├── Perfect 1:1 exchange rate always
├── Zero slippage until depleted
├── But: Vulnerable to arbitrage
├── One asset can be completely drained
└── Rarely used in practice

Why not used:
├── If external price differs from 1:1
├── Arbitrageurs drain cheaper asset
├── Pool becomes single-sided
├── No liquidity for one direction
└── Only works for perfectly pegged assets

Limited applications:
├── Wrapped assets (WETH/ETH bridges)
├── Same-asset cross-chain bridges
├── Very narrow stablecoin ranges
└── Not suitable for general AMM use
```

DODO'S PMM MODEL

Concept:
├── Use oracle for external price
├── Concentrate liquidity around oracle price
├── Adjust bonding curve dynamically
├── More capital efficient than constant product
└── Less IL theoretically

How it works:
├── Oracle provides "fair price"
├── Curve centered on oracle price
├── Tighter than constant product near fair price
├── Wider away from fair price
└── Best of both worlds (in theory)

Trade-offs:
├── + Better capital efficiency
├── + Lower slippage near fair price
├── - Oracle dependency
├── - Oracle can be manipulated
├── - More complex, harder to audit
└── - Less battle-tested
```

COMBINING MODELS

Modern AMMs often combine approaches:
├── Multiple curve types in one protocol
├── Router selects optimal path
├── Different pools for different assets
└── Aggregation across all

Examples:
├── Curve v2: StableSwap + regular pools
├── Balancer v2: Multiple pool types
├── Uniswap v3: Concentrated liquidity (already hybrid)
└── Aggregators: DEX aggregators route across all

Future direction:
├── More specialization by asset type
├── Smart routing across venues
├── Cross-chain aggregation
├── AI-optimized parameters
└── Increasing complexity
```

---

XRPL AMM TODAY

Implementation:
├── Constant product (x × y = k)
├── Same as Uniswap v2
├── Protocol-native (not smart contract)
├── Continuous auction mechanism (unique)
└── Integration with order book

What XRPL doesn't have:
├── Concentrated liquidity
├── StableSwap curves
├── Multi-asset pools
├── Weighted pools
├── Dynamic fees
└── Each would require amendment
```

POSSIBLE FUTURE AMENDMENTS

StableSwap for RLUSD pairs:
├── Use case: RLUSD/USDC, RLUSD/USDT
├── Better efficiency for stable pairs
├── Implementation: New curve type option
├── Complexity: Moderate
├── Likelihood: Medium (if RLUSD grows)

Concentrated liquidity:
├── Use case: All pairs, capital efficiency
├── Major efficiency improvement
├── Implementation: Significant protocol change
├── Complexity: High
├── Likelihood: Lower (major overhaul)

Multi-asset pools:
├── Use case: Index exposure, Treasury management
├── New functionality entirely
├── Implementation: New pool type
├── Complexity: High
├── Likelihood: Lower (limited demand currently)

Dynamic fees:
├── Use case: Fee optimization
├── Adjust fees based on volatility
├── Implementation: Fee mechanism change
├── Complexity: Moderate
├── Likelihood: Medium
```

DOES XRPL NEED THESE VARIANTS?

Arguments for current approach:
├── Simpler is more secure
├── Constant product is proven
├── XRPL ecosystem is small
├── Exotic features need ecosystem scale
├── Order book provides alternative
└── Focus should be on growth, not features

Arguments for enhancement:
├── Compete with other chains
├── Better capital efficiency attracts LPs
├── StableSwap valuable for RLUSD
├── Future-proofing the platform
├── Professional LPs want tools
└── Stay competitive

Honest assessment:
├── Current implementation is adequate
├── Ecosystem growth matters more than features
├── StableSwap for stablecoins makes sense
├── Concentrated liquidity is complex to add
├── Prioritization should be ecosystem > features
└── "Good enough" may be optimal strategy for now
```

---

✅ Concentrated liquidity improves capital efficiency. Uniswap v3 demonstrated 4000× improvement for tight ranges.

✅ StableSwap dominates stablecoin trading. Curve's success proves the model for pegged assets.

✅ Weighted pools enable new use cases. Balancer showed multi-asset pools work for indexes and treasury.

⚠️ Whether XRPL ecosystem needs these variants. Demand depends on ecosystem growth.

⚠️ Implementation complexity on protocol-native AMM. Different from smart contract upgrades.

⚠️ User sophistication for concentrated liquidity. Active management may not suit XRPL users.

📌 Assuming more features = better. Complexity adds attack surface and cognitive load.

📌 Implementing for feature parity. Building what Ethereum has isn't necessarily right for XRPL.

📌 Underestimating depeg risk in StableSwap. Tail risks can be severe.

AMM variants solve real problems but add complexity. XRPL's constant product implementation is functional and proven. Enhancement should be driven by actual ecosystem needs, not feature envy. If RLUSD grows significantly, StableSwap becomes valuable. If LP capital becomes scarce, concentrated liquidity helps. Until then, simplicity has value.

---

Assignment: Create a comprehensive comparison of AMM variants with analysis of XRPL applicability.

Requirements:

1. Constant Product (Uniswap v2, XRPL)
2. Concentrated Liquidity (Uniswap v3)
3. StableSwap (Curve)
4. Weighted Pools (Balancer)
5. PMM (DODO)

• Core formula (mathematical)

• Primary use case

• Key advantages (3-5 bullets)

• Key disadvantages (3-5 bullets)

• Implementation complexity (Low/Medium/High)

• Current TVL/market presence

• Capital efficiency (1-10 score)

• Slippage for small trades (1-10)

• Slippage for large trades (1-10)

• IL risk (1-10, higher = worse)

• LP management complexity (1-10)

• Permissionless creation (Yes/No)

• Multi-asset support (Yes/No)

• Best use case (1-sentence)

• Relevance to XRPL ecosystem (High/Medium/Low)

• Implementation feasibility (High/Medium/Low)

• User demand estimate (High/Medium/Low)

• Recommendation (Implement/Monitor/Skip)

• Rationale (2-3 sentences)

1. XRP/RLUSD trading pair
2. RLUSD/USDC stablecoin pair
3. Multi-asset XRPL DeFi index (hypothetical)

Explain which variant fits best and why.

• Stage 1: What exists + minor improvements

• Stage 2: First major enhancement (which one?)

• Stage 3: Long-term vision

• Timeline estimates and dependencies

• Technical accuracy (25%)

• Comparison completeness (25%)

• XRPL analysis insight (25%)

• Strategic thinking (25%)

Time Investment: 3-4 hours

---

For Next Lesson:
Lesson 7 examines arbitrage, MEV, and market efficiency—how arbitrageurs keep AMMs priced correctly, what MEV extraction looks like, and how XRPL's continuous auction attempts to address these issues.

---

End of Lesson 6

Total words: ~5,500
Estimated completion time: 60 minutes reading + 3-4 hours for deliverable