Xls 30 XRPLs AMM Implementation

XLS-30 SPECIFICATION

Status: Implemented and live on XRPL mainnet (2024)

Core definition:
├── Native AMM functionality for XRPL
├── Constant product formula (x × y = k)
├── Continuous auction mechanism
├── Integration with existing DEX order book
└── Protocol-level implementation

Key components:
├── AMM ledger entry type (new object type)
├── AMM-specific transaction types (7 new types)
├── LP token mechanics (as issued currencies)
├── Voting mechanism for pool parameters
├── Auction slot system
└── Pathfinding integration

Amendment activation:
├── Enabled via XRPL amendment process
├── Required 80% validator support
├── Activated February 2024
└── Now part of all compliant nodes
```

XLS-30 DESIGN PHILOSOPHY

Protocol-native (not smart contract):
├── AMM logic in validator C++ code
├── Same security model as core XRPL
├── No separate audit of contract code
├── Changes require amendment process
├── More rigid but more secure

Constant product formula:
├── Proven model (Uniswap v2 style)
├── Simple, well-understood
├── Not trying to innovate on formula
├── Innovation in other areas (auction)
└── Conservative technical choice

Permissionless creation:
├── Anyone can create AMM pools
├── Any asset pair (with some restrictions)
├── No governance approval needed
├── Pool creator sets initial parameters
└── True decentralization

Integration focus:
├── Works with existing XRPL DEX
├── Pathfinding uses both AMM and order book
├── Not replacing order book—complementing
├── Unified liquidity approach
└── Best execution across venues
```

EXCLUDED FEATURES (INTENTIONAL SIMPLICITY)

Concentrated liquidity:
├── Not implemented
├── Would add significant complexity
├── May come in future amendment
└── Current: Full-range liquidity only

Multi-asset pools:
├── Only two-asset pools
├── No weighted pools
├── No index-style pools
└── Balancer-style not supported

StableSwap curves:
├── Only constant product
├── No special stable pair handling
├── May be less efficient for stablecoins
└── Potential future enhancement

Programmable logic:
├── No hooks or custom code
├── Fixed behavior defined by protocol
├── Can't customize pool behavior
└── Trade-off: Security vs. flexibility

Dynamic fees:
├── Fee can be changed via voting
├── But not algorithmic adjustment
├── No volatility-based fees
└── Manual governance only
```

---

AMM LEDGER ENTRY STRUCTURE

Every AMM pool is an "AMM" ledger entry:

{
"LedgerEntryType": "AMM",
"Account": "rAMMAccountAddress...",
"Asset": {
"currency": "XRP"
},
"Asset2": {
"currency": "USD",
"issuer": "rIssuerAddress..."
},
"AuctionSlot": { ... },
"LPTokenBalance": {
"currency": "03A19...", // LP token currency code
"issuer": "rAMMAccountAddress...",
"value": "1000000"
},
"TradingFee": 500, // 0.5% in basis points
"VoteSlots": [ ... ]
}

Key fields explained:
├── Account: Special AMM-controlled account
├── Asset/Asset2: The two pool assets
├── LPTokenBalance: Total LP tokens outstanding
├── TradingFee: Fee in basis points (0-1000 = 0-1%)
├── AuctionSlot: Current auction state
└── VoteSlots: Fee voting records
```

SPECIAL AMM ACCOUNT

Each pool has an "AMM Account":
├── Generated at pool creation
├── Holds the actual pool assets
├── Issues LP tokens
├── No private key (protocol-controlled)
├── Cannot be used for regular transactions
└── Exists only to manage pool

AMM Account properties:
├── XRP balance: Pool's XRP reserve
├── Trust lines: Pool's issued currency holdings
├── Issues: LP tokens to depositors
├── Special flag: Account marked as AMM
└── Protected: Cannot be deleted while pool exists

Looking up AMM data:
├── Can query AMM object directly
├── Or query account for balances
├── AMM object has computed fields
├── Account has raw balance data
└── Both useful depending on need
```

LP TOKEN IMPLEMENTATION

LP tokens are issued currencies:
├── Currency code: Hash of pool assets
├── Issuer: AMM Account
├── Standard XRPL issued currency mechanics
├── Requires trust line to hold
└── Transferable like any issued currency

Currency code generation:
├── Derived from asset pair
├── Deterministic: Same pair = same code
├── Unique per pool
├── Cannot be faked or duplicated
└── Protocol ensures uniqueness

Trust line requirement:
├── Before depositing, set trust line
├── To AMM Account for LP token currency
├── Wallets usually handle automatically
├── Without trust line, cannot receive LP tokens
└── Standard XRPL behavior
```

---

AMMCREATE - CREATING A NEW POOL

Purpose: Create new AMM pool for a trading pair

Transaction fields:
{
"TransactionType": "AMMCreate",
"Account": "rCreatorAddress...",
"Amount": "1000000000", // 1000 XRP in drops
"Amount2": {
"currency": "USD",
"issuer": "rIssuerAddress...",
"value": "2500" // 2500 USD
},
"TradingFee": 500 // 0.5% = 500 basis points
}

What happens:
├── New AMM ledger entry created
├── New AMM Account created
├── Assets transferred to AMM Account
├── LP tokens minted to creator
├── Initial price set by deposit ratio
└── Pool live and tradeable

Restrictions:
├── Cannot create duplicate pool for same pair
├── Some asset pairs may be restricted
├── Minimum reserve requirements apply
├── Fee must be 0-1000 basis points
└── Both assets must be valid
```

AMMDEPOSIT - ADDING LIQUIDITY

Purpose: Deposit assets to receive LP tokens

Multiple deposit modes:

Mode 1: Two-asset proportional
{
"TransactionType": "AMMDeposit",
"Account": "rDepositorAddress...",
"Asset": { "currency": "XRP" },
"Asset2": { "currency": "USD", "issuer": "r..." },
"Amount": "100000000", // 100 XRP
"Amount2": { "value": "250", ... }, // 250 USD
"Flags": tfTwoAsset // 0x00100000
}

Mode 2: Single asset deposit
├── Deposit only one asset
├── Pool swaps internally to balance
├── Results in slippage/IL on swap portion
└── Convenient but less efficient

Mode 3: LP token amount
├── Specify LP tokens desired
├── Pool calculates required assets
├── Useful for precise share targeting
└── May require more than expected if price moved

What happens:
├── Assets transferred to AMM Account
├── LP tokens minted to depositor
├── Pool balances increase
├── Depositor pool share calculated
└── No voting weight until next epoch
```

AMMWITHDRAW - REMOVING LIQUIDITY

Purpose: Burn LP tokens to receive pool assets

Withdrawal modes:

Mode 1: Two-asset proportional
{
"TransactionType": "AMMWithdraw",
"Account": "rWithdrawerAddress...",
"Asset": { "currency": "XRP" },
"Asset2": { "currency": "USD", "issuer": "r..." },
"LPTokenIn": { "value": "1000", ... }, // LP tokens to burn
"Flags": tfTwoAsset
}

Mode 2: Single asset withdrawal
├── Receive only one asset
├── Pool swaps internally
├── Additional slippage applied
└── Convenience feature

Mode 3: By asset amount
├── Specify assets to receive
├── Pool calculates LP tokens to burn
├── Useful for specific liquidity needs
└── May burn more LP than expected

What happens:
├── LP tokens burned
├── Proportional assets transferred out
├── Pool balances decrease
├── Withdrawal at current ratio (IL realized)
└── Any remaining LP tokens still valid
```

AMMBID - AUCTION SLOT BIDDING

Purpose: Bid for discounted trading rate

Transaction:
{
"TransactionType": "AMMBid",
"Account": "rBidderAddress...",
"Asset": { "currency": "XRP" },
"Asset2": { "currency": "USD", "issuer": "r..." },
"BidMin": { "value": "100", ... }, // Minimum LP tokens to bid
"BidMax": { "value": "150", ... }, // Maximum willing to bid
"AuthAccounts": [ ... ] // Optional: Accounts that can trade at discount
}

Auction mechanics:
├── Bid with LP tokens
├── Win: Get 24-hour discount slot
├── Slot holder: 0% trading fee
├── Displaced holder: Partial refund
├── Bid proceeds: Distributed to LPs
└── Can be outbid at any time

AuthAccounts feature:
├── Slot holder can designate up to 4 accounts
├── Those accounts also get discount
├── Useful for trading operations
├── Or: Leave empty for personal use only
└── Strategic flexibility
```

AMMVOTE - FEE GOVERNANCE

Purpose: Vote on pool trading fee

Transaction:
{
"TransactionType": "AMMVote",
"Account": "rVoterAddress...",
"Asset": { "currency": "XRP" },
"Asset2": { "currency": "USD", "issuer": "r..." },
"TradingFee": 600 // Desired fee: 0.6%
}

How voting works:
├── Each LP can vote once
├── Vote weight = LP token holding
├── Fee = weighted average of votes
├── Maximum 8 vote slots tracked
├── New vote displaces lowest-weight vote
└── Continuous governance, no epochs

Fee bounds:
├── Minimum: 0 (zero fee)
├── Maximum: 1000 basis points (1%)
├── Current fee: Weighted average
├── Changes take effect immediately
└── Significant holder can influence
```

ADDITIONAL AMM TRANSACTIONS

AMMDelete:
├── Remove empty AMM pool
├── Only possible if pool fully drained
├── Rare use case
├── Frees ledger space
└── Requires specific conditions

AMMClawback:
├── Related to clawback-enabled assets
├── Issuer can recover assets
├── Specialized use case
├── Not common in practice
└── For compliance scenarios

Standard transactions affecting AMM:
├── Payment: Can route through AMM
├── OfferCreate: Can interact via pathfinding
├── TrustSet: Needed for LP tokens
└── AMM integrates with XRPL ecosystem
```

---

AMM IN XRPL PATHFINDING

Unified liquidity:
├── XRPL pathfinding considers:
│ ├── Order book DEX offers
│ ├── AMM pools
│ └── Combined paths
├── Automatic best-price routing
├── User doesn't need to choose venue
└── System optimizes execution

Path selection:
├── For each payment/swap request
├── System finds cheapest path
├── May use order book alone
├── May use AMM alone
├── May use combination
├── Or route through intermediate assets

Example:
├── User wants: THB → MXN
├── No direct pair has liquidity
├── Path found: THB → XRP → RLUSD → MXN
├── Each hop uses cheapest venue
├── Order book for THB/XRP, AMM for XRP/RLUSD
└── Optimal composite execution
```

XRPL RESERVE CONSIDERATIONS

Account reserves:
├── AMM Account requires base reserve
├── Created at pool creation
├── Part of pool creation cost
└── Released if pool deleted

LP token trust lines:
├── Each holder needs trust line
├── Standard owner reserve applies
├── Plan for trust line costs
└── Part of LP overhead

Pool asset trust lines:
├── AMM Account has trust lines
├── For non-XRP assets
├── Reserves from pool assets
└── Handled automatically

Practical impact:
├── Creating pool: Reserve for AMM Account
├── Depositing: May need trust line reserve
├── Both: Usually negligible in context
└── But worth understanding
```

COMMON AMM ERRORS

tecAMM_BALANCE:
├── Insufficient balance in pool
├── Usually on empty pool operations
└── Check pool state before transacting

tecAMM_FAILED:
├── Generic AMM operation failure
├── Various causes
└── Check transaction result details

tecAMM_NOT_EMPTY:
├── Trying to delete non-empty pool
├── Withdraw all assets first
└── Then delete if needed

tecNO_AUTH:
├── Not authorized for operation
├── May need auction slot
├── Or other permission issue

tecINSUFFICIENT_FUNDS:
├── Not enough funds for operation
├── Including reserves
└── Ensure adequate balance
```

---

SECURITY ADVANTAGES OF PROTOCOL-NATIVE

No smart contract risk:
├── AMM logic not in user-deployed code
├── Bugs require validator consensus to exist
├── No "reentrancy" attack surface
├── No "flash loan" attack surface
├── Audited as part of rippled code
└── Same security as XRPL itself

Attack surface comparison:
├── Ethereum AMM: Contract code + EVM + consensus
├── XRPL AMM: Protocol code + consensus
├── Fewer layers = fewer potential issues
├── But also: Harder to upgrade/fix
└── Trade-off: Rigidity vs. security

No contract upgrade risk:
├── Ethereum: Contracts can be upgraded
├── Upgrades can introduce bugs
├── XRPL: Changes require amendment
├── Amendment requires 80% validator support
├── Much slower but more secure
└── Deliberate stability
```

LIMITATIONS OF PROTOCOL-NATIVE

Inflexibility:
├── Can't innovate quickly
├── Every change needs amendment
├── Amendment process takes months
├── Can't experiment like Ethereum
└── Slower evolution

Limited programmability:
├── No custom pool logic
├── No hooks or callbacks
├── No composability like DeFi Legos
├── Fixed functionality only
└── Can't build on top easily

Feature parity:
├── Missing concentrated liquidity
├── Missing StableSwap
├── Missing multi-asset pools
├── Each would need amendment
└── Playing catch-up with Ethereum AMMs

Developer experience:
├── Less familiar than Solidity
├── Fewer tools and libraries
├── Smaller community
├── Less documentation
└── Higher barrier to entry
```

PROTOCOL-NATIVE: NET ASSESSMENT

Where XRPL wins:
├── Security (no smart contract exploits)
├── Efficiency (no contract overhead)
├── Simplicity (for end users)
├── Cost (lower than Ethereum)
└── Integration (works with order book)

Where Ethereum wins:
├── Flexibility (any design possible)
├── Innovation speed (permissionless deployment)
├── Composability (DeFi building blocks)
├── Ecosystem (developers, tools, users)
└── Feature breadth (many AMM variants)

Who should care:
├── Security-focused users → XRPL advantage
├── Innovation-focused users → Ethereum advantage
├── Simple AMM needs → XRPL adequate
├── Complex DeFi strategies → Ethereum better
└── Depends on use case

Bottom line:
├── XRPL's approach is valid but different
├── Not "better" or "worse"—different trade-offs
├── Right choice depends on priorities
├── Both approaches can succeed
└── Competition drives improvement
```

---

✅ XLS-30 works as designed. Live on mainnet since 2024, processing transactions correctly.

✅ Protocol-native is more secure. No smart contract exploits possible in XRPL AMM.

✅ Integration with order book functions. Pathfinding successfully uses both venues.

⚠️ Long-term competitiveness. Missing features may matter more as DeFi evolves.

⚠️ Amendment path for improvements. How quickly can XRPL add concentrated liquidity, etc.?

⚠️ Developer adoption. Will developers build around XRPL's more rigid model?

📌 Assuming protocol-native means "no bugs." Implementation bugs can still exist; just no contract bugs.

📌 Expecting Ethereum-style innovation speed. XRPL's amendment process is deliberately slow.

📌 Ignoring feature limitations. Missing features matter for some use cases.

XLS-30 is a competent, secure implementation of basic AMM functionality. It's not cutting-edge, and it's intentionally conservative. For users who prioritize security and simplicity over bleeding-edge features, it's a reasonable choice. For those wanting DeFi innovation, XRPL's AMM may feel limiting.

---

Assignment: Create a 3-page technical brief explaining XRPL AMM to a developer audience.

Requirements:

• What XLS-30 is in one paragraph

• Key differentiators from Ethereum AMMs

• Current status and adoption

• AMM ledger object structure (with field explanations)

• AMM Account concept

• LP token implementation

• Relationship to existing XRPL DEX

• All AMM transaction types

• Key fields for each

• Common use cases

• Code examples (pseudocode or JSON)

• How to query AMM data

• How pathfinding uses AMM

• Key considerations for integrations

• Links to official documentation

• Professional technical documentation style

• Clear headings and structure

• Accurate technical details

• Suitable for developer onboarding

• Technical accuracy (30%)

• Completeness (25%)

• Clarity of explanation (25%)

• Professional presentation (20%)

Time Investment: 2-3 hours

---

For Next Lesson:
Lesson 9 provides a deep dive into XRPL's continuous auction mechanism—the unique feature that attempts to address MEV and improve LP returns. We'll examine the game theory, mechanics, and early observations.

---

End of Lesson 8

Total words: ~5,400
Estimated completion time: 55 minutes reading + 2-3 hours for deliverable