AMM Fee Enhancements

[hoos]

Introduction

This amendment proposes significant enhancements to the Automated Market Maker (AMM) fee system on the XRP Ledger (XRPL). The current system allows the top 8 liquidity providers (LPs) to vote on a single trading fee that applies uniformly to all operations, with a maximum cap of 1%. This structure lacks the granularity needed for LPs to effectively manage their liquidity and respond to changing market conditions.

The proposed changes would allow LPs to exercise greater control over how their provided liquidity is utilised by implementing operation-specific fees that can directly influence the pool's exchange rate dynamics. This enhancement aims to create more sophisticated incentive structures, enabling LPs to better manage risk and potentially increase the overall efficiency and attractiveness of AMM pools on the XRPL.

Proposed Changes

1. Increase Fee Cap from 1% to 2.5% - Raise the maximum allowable fee that LPs can vote to implement.

2. Operation-Specific Fee Structure - Replace the current single-fee model with distinct fee categories based on operation type, namely Single Sided deposits and withdrawals :

   • XRP Deposits Fee
   • XRP Withdrawals Fee
   • Token Deposits Fee
   • Token Withdrawals Fee

3. Enhanced LP Voting Mechanism - Modify the voting system to accommodate the new multi-dimensional fee structure.

4. Blackholed Wallet Exclusion - Exclude blackholed wallets from LP voting calculations to prevent fee stagnation.

5. Backward Compatibility and Migration Strategy - Ensure existing pools can transition smoothly to the new fee structure.

6. Lower the cost of the AMM Auction Slot - This feature simply isn't being used probably because of its prohibitive costs.

Detailed Changes and Rationales

1. Fee Cap Increase to 2.5%

Current Implementation

The current AMM implementation on XRPL caps the trading fee at 1%, which LPs vote on collectively. This single fee applies to all operations within the pool.

Proposed Implementation

This amendment would increase the maximum allowable fee from 1% to 2.5%.

Rationale

A higher fee cap provides several benefits:

• Strategic Flexibility: LPs gain greater latitude to implement fee strategies that reflect their risk tolerance and market outlook.
• Market Adaptation: Higher potential fees allow pools to adjust more effectively during periods of high volatility or unusual market conditions.
• Competitive Fee Structure: While the cap increases, competition between AMMs will naturally keep fees at efficient levels, as excessively high fees would drive users to more attractively priced pools.
• Enhanced Risk Management: LPs can better protect themselves against impermanent loss and other risks by having access to a wider fee range.

The 2.5% cap strikes a balance between giving LPs more control while ensuring that fees remain reasonable enough to maintain trading volume and pool viability.

2. Operation-Specific Fee Structure

Current Implementation

Currently, a single fee applies to all operations within an AMM pool, regardless of whether the operation is a swap, a single-sided deposit, or a withdrawal.

Proposed Implementation

This amendment would replace the single-fee model with six distinct fee categories:

1. XRP Deposits Fee - Applied when users add only XRP to the pool
2. XRP Withdrawals Fee - Applied when users remove only XRP from the pool
3. Token Deposits Fee - Applied when users add only the paired token to the pool
4. Token Withdrawals Fee - Applied when users remove only the paired token from the pool

Each fee would be independently configurable up to the 2.5% cap, with the top 8 LPs voting on each fee separately.

Rationale

Operation-specific fees provide numerous advantages:

• Directional Liquidity Control: LPs can create economic incentives to encourage or discourage specific operations based on desired pool composition.
• Exchange Rate Management: By applying different fees to different operations, LPs can indirectly influence the effective exchange rate offered by the pool, making it more attractive for specific types of trades.
• Capital Efficiency: More granular fee structures allow LPs to optimize how their capital is employed within the pool.
• Market-Responsive Pools: Pools can better adapt to changing market conditions by adjusting specific fees rather than applying blunt, across-the-board fee changes.

Example scenarios where this would be beneficial:

• To encourage XRP inflows during periods when the pool is token-heavy: Set low fees for XRP deposits (e.g., 0.1%) while maintaining higher fees for XRP withdrawals (e.g., 1.5%).
• To manage volatility in the paired token: Set higher fees for token-to-XRP swaps during periods of token depreciation to prevent pool depletion of XRP.

3. Enhanced LP Voting Mechanism

Current Implementation

The voting mechanism currently allows the top 8 LPs by liquidity share to vote on a single fee parameter.

Proposed Implementation

The enhanced voting system would:

1. Maintain the principle that the top 8 LPs by liquidity share control fee decisions
2. Extend voting rights to each of the six fee categories independently
3. Implement a weighted voting system where each LP's vote is proportional to their share of the liquidity pool
4. Require periodic re-voting on fees (suggested: every 2 weeks or when LP composition changes significantly)

Additionally, special provisions would allow:

• Token issuers to have a vote on fees related to XRP inflows to their token's pools, potentially with a veto right on excessive fees that would discourage XRP liquidity
• Mechanisms to prevent rapid fee oscillations that could confuse or frustrate traders

Rationale

An enhanced voting mechanism ensures that:

• Democratic Control: The system remains governed by those with the most at stake.
• Specialised Strategies: Different pools can implement widely different fee strategies based on their specific LP preferences and token characteristics.
• Issuer Protection: Token issuers retain some influence over how their token's liquidity pools operate, particularly regarding XRP accessibility.
• Market Stability: The mechanics of fee changes are structured to prevent extreme volatility in fee structures.

4. Blackholed Wallet Exclusion

Current Implementation

Currently, all LP positions contribute to voting power regardless of whether the wallet controlling those positions is active or has been "blackholed" (i.e., the wallet's private keys have been deliberately destroyed, making the wallet effectively immutable).

Proposed Implementation

This amendment would exclude blackholed wallets from LP voting calculations. Specifically:

1. Wallets identified as blackholed (through standard XRPL blackholing techniques like setting the regular key to the account's address or to an all-zeros address) would not be counted among the top 8 LPs for voting purposes.
2. Their liquidity would still earn fees and contribute to the pool's overall functionality but would have no voting power.
3. The voting power would be distributed among the top 8 non-blackholed LPs.

Rationale

Excluding blackholed wallets from voting provides several benefits:

• Prevents Fee Stagnation: Without this exclusion, significant LP positions in blackholed wallets could permanently lock in specific fee values, as these positions cannot change their votes.
• Ensures Adaptability: AMM pools need to adapt to changing market conditions. Blackholed wallets, by definition, cannot respond to these changes.
• Protects Token Issuers: Many tokens have significant portions of their supply in blackholed wallets for various reasons (e.g., token burns). Including these wallets in voting could disproportionately influence fee structures in ways that harm the token's ecosystem.
• Maintains Active Governance: This ensures that only active participants in the ecosystem can influence fee structures, promoting responsive and responsible governance.

5. Backward Compatibility and Migration Strategy

Current Implementation

The current XRPL AMM implementation uses a single fee structure that is coded into the ledger's AMM objects.

Proposed Implementation

This amendment would handle backward compatibility through a phased approach:

1. Phase 1: Dual-Mode Operation

   • Existing AMM pools would continue to operate under the old fee structure initially
   • New pools created after the amendment activation would use the new fee structure
   • A migration flag would be added to the AMM object to indicate which fee structure a pool is using

2. Phase 2: Opt-In Migration

   • AMM pool owners would be provided with a new transaction type: AMMFeeMigrate
   • This transaction would convert a pool from the old fee structure to the new one
   • During migration, the current single fee would be applied to all six new fee categories as a starting point
   • The migration would require a majority vote from the top 8 non-blackholed LPs

3. Phase 3: Mandatory Migration

   • After a grace period (suggested: 6 months after amendment activation)
   • All remaining pools using the old fee structure would be automatically migrated
   • This ensures that all pools eventually benefit from the new features

Rationale

This phased migration approach offers several advantages:

• Minimal Disruption: Existing pools can continue to operate without immediate changes
• Controlled Transition: Pool participants can prepare for and manage the transition at their own pace
• Testing Opportunity: Early adopters can test the new fee structure while others observe the results
• Eventually Consistent: All pools will eventually use the same mechanism, simplifying the codebase and user experience
• Prevents Technical Debt: Avoiding the need to maintain two parallel AMM implementations indefinitely

6. Lower the cost of the AMM Auction Slot

The The AMM Auction Slot simply isn't being used. The cost of bidding for this slot is prohibitively expensive expensive and the fact that pool fees are capped at 1% means that arbitrageurs simply have no incentive to use it. Allowing LPs to increase the fees to the proposed 2.5% cap and reducing the cost of the auction slot will incentivise the use of this powerful feature.

Technical Implementation Considerations

1. Ledger Entries: The AMMFee object in the ledger would need to be expanded to store multiple fee values instead of just one.

2. Transaction Types: The AMMVote transaction would need modification to specify which fee type is being voted on.

3. Fee Application Logic: The AMM's core logic would need updates to apply the appropriate fee based on operation type.

4. User Interface Considerations: Wallet providers and interfaces would need to update to display the various fees applicable to different operations.

5. Blackholed Detection: The code would need to implement reliable detection of blackholed wallets based on standard XRPL blackholing patterns.

6. Migration Tracking: The ledger would need to track which fee structure version each AMM pool is currently using.

Conclusion

The AMM Fee Enhancement Amendment represents a significant evolution in how liquidity providers can manage their participation in XRPL's AMM system. By providing more granular control through operation-specific fees, a higher fee cap, and improved voting mechanics that exclude blackholed wallets, this amendment would enable more sophisticated liquidity strategies, potentially attracting greater participation in the XRPL DEX ecosystem.

The changes strike a balance between giving LPs more control while maintaining the user-friendly and efficient character of the XRPL AMM implementation. With the proposed backward compatibility and migration strategy, the transition to this enhanced system can occur smoothly with minimal disruption to existing users.

If adopted, these enhancements would position the XRPL AMM feature as one of the most flexible and LP-friendly automated market maker implementations in the blockchain space, while ensuring that active participants maintain proper governance control over pools.

[KhaledElawadi]

Ok, so whilst I'm not opposed in principle I think you have to be both realistic and cautious when it comes to applying AMM fees.

Those percentages sound way too high and could well do damage when it comes to attracting new customers.

Would you be in favour of AI controlled Smart AMMs I wonder, where you hand over the fee strategy to an AI designed to maximise returns?

[hoos]

I think it's best to leave it up to liquidity providers to vote for the fees and for other participants to decide if they made the right decision. If LPs and participants want to delegate those decisions to AI, so be it.

[KhaledElawadi]

Are you suggesting that a bunch of LPers would be able to make better up to the second decisions about applying variable fee rates than AI?

Also, what if 10,000 LPers providing upto 90% of the assets in the pool want 0.1% and just 8 LPers providing less than 10% want 2.5%.

How can just 8 unelected people make that kind of decision especially if there is only one pool possible for each pair?

[hoos]

The proposal doesn't consider AI while acknowledging that LPs could delegate their decision making to AI. It is a moot point.

The proposal simply argues that a fee of 2.5% gives LPs more flexibility than 1% and doesn't comment on the number of voting slots or changing the voting process.

[KhaledElawadi]

I'd argue it would be open to abuse and just give front runners/fraudsters the opportunity to rip more people off when it's time for them to cash in their chips.

[hoos]

More open to abuse than it is now I suppose? It's odd that giving the liquidity providers more control of their liquidity opens them up to front runners/fraudsters. You're arguing to give gangsters guns, while taking them away from the shop owners.

[AussieXRP]

Hoos, Your proposal for the AMM fee system enhancement on the XRP Ledger is outstanding and thoughtfully designed. By introducing operation-specific fees, raising the fee cap to 2.5%, and refining the voting mechanism, this amendment empowers well-informed liquidity providers to act in the collective interest of all pool participants. The granular fee structure enables LPs to strategically manage liquidity flows, stabilize exchange rates, and adapt to market dynamics, fostering a balanced and efficient pool. Excluding blackholed wallets ensures active governance, preventing stagnation and aligning decisions with the broader ecosystem’s benefit. The phased migration strategy further demonstrates a commitment to seamless adoption, enhancing trust and participation. This forward-thinking approach not only strengthens the XRPL AMM’s competitiveness but also promotes a collaborative environment where informed decisions uplift the entire pool. Excellent work, well done.

[poor-d3v]

@hoos let's turn this up a knotch, what say you?

XRPL Amendment Proposal: Dynamic Fee Model for AMM Pools

Title: Dynamic Fee Model with Volatility-Based Surge Pricing for XRPL AMMs
Proposed By: @poor_xrpl
Date: April 25, 2025
Category: AMM Protocol Enhancement

1. Introduction

This proposal introduces a Dynamic Fee Structure for XRPL AMMs. The aim is to improve capital efficiency, reward liquidity providers (LPs) during volatile conditions, and reduce exploitability through micro-transaction manipulation. The model uses a Base Fee plus a Variable Fee, where the variable component depends on real-time market volatility and swap behavior.

2. Fee Structure Overview

Each AMM swap on XRPL will incur a Total Swap Fee (fs):

fs = fb + fv

Where:

• fb: Base Fee (fixed component)

• fv: Variable Fee (depends on market volatility and swap path)

Fees are calculated per bin and distributed to LPs proportionally.

3. Base Fee (fb)

The Base Fee is configured when the pool is created and calculated as:

fb = B × s

Where:

• B: Base Factor (adjustable)

• s: Bin Step (fixed price interval per bin)

This provides predictable minimum compensation for LPs.

4. Variable Fee (fv)

The Variable Fee accounts for market volatility and the number of bins a swap crosses:

fv(k) = A × (va(k) × s)²

Where:

• A: Variable Fee Control Parameter

• s: Bin Step

• va(k): Volatility Accumulator for bin k

This ensures that:

• Larger swaps (spanning more bins) incur higher fees

• Increased volatility increases va(k), which in turn increases fv

5. Bin-Based Swap Fee Iteration

For a swap crossing n bins (0 ≤ k ≤ n), the variable fee is computed per bin using:

k = binID - activeID

• Positive k indicates an upward price move

• Negative k indicates a downward price move

Example:

• Active bin: ID = 1000, price = $100

• Buy order pushes price to $102

• Bins crossed: 1000 (k=0), 1001 (k=1), 1002 (k=2)

Each bin has a unique va(k), resulting in a different fv(k).

6. Volatility Accumulator (va)

The Volatility Accumulator va(k) captures price movement intensity during and between swaps:

va(k) = vr + |ir - (activeID + k)|

Where:

• vr: Volatility Reference (decays over time)

• ir: Index Reference (anchor for introduced volatility)

• activeID: Bin ID before the swap

• k: Current bin offset

7. Volatility Reference (vr)

Volatility memory decays based on time t since the last swap.

Let:

• tf: Filter period (e.g., 1 second)

• td: Decay period (e.g., 5 seconds)

• R: Decay factor (e.g., 0.5)

Then:

• If t < tf: vr = previous va (no decay)

• If tf ≤ t < td: vr = R × previous va

• If t ≥ td: vr = 0

This ensures:

• High frequency trades maintain accumulated volatility

• Low frequency trading resets volatility to zero

8. Index Reference (ir)

Used to prevent fee manipulation through small swap spam.

• If t < tf: ir = previous ir

• Else: ir = activeID (pre-swap)

By freezing ir during high-frequency activity, the model avoids artificially inflating va(k) through noise.

9. Final Fee Formula

For each bin k crossed:

fee(k) = swapAmount(k) × (fb + fv(k))

Fees are stored and claimable per-bin by LPs.

10. Volatility Accumulator Example

Parameters:

• tf = 1 second, td = 5 seconds, R = 0.5, initial activeID = 100

Swap 1: Crosses +3 bins (100 to 103)

• vr = 0, ir = 100

• va(k) = 0 + |100 - (100 + k)| = |k|

• Final va = 3

Swap 2: 4 seconds later, crosses +5 bins (103 to 108)

• t = 4, so vr = 0.5 × 3 = 1.5, ir = 103

• va(0) = 1.5 + |103 - 108| = 6.5

• va(1) = 1.5 + |103 - 109| = 5.5

• Final va = 6.5

Swap 3: 0.3 seconds later, crosses -2 bins (108 to 106)

• t = 0.3 < tf, so vr = 1.5, ir = 103

• Bins: 108 (k=0), 107 (k=-1), 106 (k=-2)

• va(0) = 1.5 + |103 - 108| = 6.5

• va(-1) = 1.5 + |103 - 107| = 5.5

• va(-2) = 1.5 + |103 - 106| = 4.5

• Final va = 4.5

11. Protocol Fee

A fixed percentage of the total dynamic fee (fs) is retained by the protocol:

• Standard Pools: 5%

• Bootstrapping Pools: 20%

12. Liquidity Strategies Enabled

By allocating different amounts of tokens at different price points, LPs can build customized liquidity shapes using the Dynamic Fee model that align with their risk tolerance, market outlook, and rebalancing strategy.

The bin-based system allows precise control over liquidity placement.

Strategy Types:

• Spot: Uniform distribution across bins. Flexible and suitable for any market. Great for beginners and low-maintenance LPs.

• Curve: Concentrates liquidity toward the center of a price range. Ideal for stablecoin pairs.

• Bid-Ask: Capital at both ends of the price range. Designed for volatile markets or DCA strategies.

• Spot-Concentrated: Focuses on 1--3 bins around the current price. Useful for narrow-range trading.

• Spot-Spread: Wider range across 20--30 bins. Good for trending or volatile markets.

• Spot-Wide: Covers 50+ bins. Long-term passive strategy with minimal upkeep.

Strategy Use Cases:

• Spot: Best for general-purpose LPing and rebalancing

• Curve: Optimized for stable pairs

• Bid-Ask: Captures breakout volatility

• DCA & Limit Orders: Enabled through Bid-Ask and single-sided bin setups

Advanced Use Cases Include:

• Ranged Limit Orders

• Dollar-Cost Averaging (DCA) While Earning

• Sell/Buy Walls

• Ladder Orders

• De-Peg Bets

13. Implementation Notes

• Introduce the fee engine as an optional parameter for pools

• Requires:

  • Per-bin fee tracking

  • Adjustments to swap logic

  • Time-aware volatility memory

This model can coexist with current flat-fee pools.

14. Backward Compatibility

• Existing pools are unaffected

• New pools can opt into the dynamic model

• LPs can use multiple strategies across pool types

15. Conclusion

This amendment provides a robust, incentive-aligned, and manipulation-resistant fee model for XRPL AMMs. By scaling fees based on market volatility and rewarding LPs proportionally, it enhances liquidity efficiency and market responsiveness.

[KhaledElawadi]

Poor, some interesting ideas there concerning fee structure.

However, I think you've fallen into the liquidity trap by prioritising LPs.

If you haven't already noticed the fee margins are getting tighter and tighter on the big centralised exchanges and the more you exchange the less of a percentage you pay not more.

We have to be the cheapest, there's simply no alternative. Everything is trustless, decentralised, performed automatically onchain requiring no additional security engineers or shareholders to pay which must be reflected in the overall cost of using our swap service. No point in having a technological advantage if you're not going to make it count.

Btw, what do you think about the idea of redesigning the AMMs to collect and pool swap fees seperately and in RLUSD?

It will become quite obvious then to all users and LPers how much the AMMs are collecting in fees on a weekly, monthly and yearly basis regardless of the exchange rate or varying market price of the assets. It also protects those fees from the same volatility that the assets are subject to.

[ximinez]

Just a couple of quick thoughts:

1. I don't have an opinion on the fee cap increase
2. Operation-specific fee structure:
   1. Right now, IIRC, fees are only charged on swaps. Will that still be true? If I am an LP, and I add or withdraw funds (let's assume proportionally), will I be charged under this new scheme?
   2. Designating them by "XRP" and "Token" may be too limiting. For example, an AMM could be Token / Token, or Token / MPT down the road. I suggest designating them as "Asset 1 fee" and "Asset 2 fee".
3. Re: Enhanced LP Voting Mechanism
   1. I think voting is already weighted such that each LP's vote is proportional to their share of the liquidity pool.
   2. How would you enforce a requirement for periodic re-voting on fees? Would the AMM simply cease to function if some timer expires?
4. The ledger does not currently have a concept of a blackholed account. If you want to introduce one, you need to define it very precisely and carefully such that an account is not locked out if it can still sign transactions. For example, I could set my regular key to "0", disable my master key, and still have a signer list defined that allows me to send transactions. (Also, note it should be impossible to set your regular key to the same value as your master account ID.)
5. How would you enforce and implement mandatory migration? Nothing happens automatically, a ledger object can only be modified by a transaction.

[hoos]

Thanks @ximinez , great feedback. What is the best way to respond, should I edit the original post with my updates, responses?

[ximinez]

You could do that, or integrate the feedback when the discussion moves to be a PR with the "official" spec.

[hoos]

Thanks @ximinez I'll respond from the feedback from yourself and @poor-d3v separately and I'll update the original post with what I hope will end up in the "official" spec. Anything that is uncontroversial, or an elaboration I'll edit into the original post.

The more controversial aspects, we can thrash out in separate posts.

[mvadari]

Note that for an official spec, you'll need to roughly follow the same format that other official specs use - i.e. outlining the specific changes to ledger objects and transactions.

[Panosmek]

Thanks for putting this proposal together, but I think this is a bad idea, and without mentioning the technical complexity as mentioned by @ximinez, I can't see any benefits. Here are my concerns:

1. Fee cap increase to 2.5% is excessive and will deter users from using the DEX:
   Raising the fee cap from 1% to 2.5% is a step in the wrong direction. A 1% trading fee is already very high compared to other AMMs and alternatives (both DEXs and CEXs), where fees are often 0.3% or lower to stay competitive. Most big CEXs have a 0.1% trading fee. No pool or pair on XRPL should have fees this high, and increasing the cap risks making AMMs unappealing to traders. The proposal mentions benefits like LP flexibility and risk management, but this shouldn’t come at the expense of affordability for users. We should be lowering fees to make XRPL AMMs more competitive, not raising them. Not to mention that if AMM pool fees are that high then trades will simply go through the order book which for the big pairs there is liquidity and that means even less profits for liquidity providers and less usage and activity for the AMM.

2. Operation-specific fees for deposits and withdrawals add unnecessary costs:
   Introducing fees for LP deposits and withdrawals is a bad idea. These are basic actions that don’t generate value or profit for LPs the way swaps do, they are just users managing their liquidity. Charging fees on deposits and withdrawals adds extra costs that discourage participation. I haven't seen any DEX charging for these actions because it punishes users for simply interacting with the pool. The proposal says this helps LPs control liquidity, but we should be incentivizing participation through rewards, not penalizing users with extra fees. This approach prioritizes LP profits over user experience, which I believe goes against the priorities we should have as an ecosystem (and as an industry).

3. Higher fees won’t fix the AMM’s real challenges:
   This proposal focuses on fee structures, but that’s not what will make the XRPL AMM better. We need to grow the ecosystem by bringing in more high quality assets (especially stablecoins and RWAs) and increasing active users. Higher fees and new fee categories won’t attract users, they’ll drive them away, especially when other options offer lower costs. We should be onboarding high-quality assets, new users, improving liquidity through that and partnerships, and simplifying the user experience to drive adoption. That’s how we’ll make the AMM a success, not by adding costs and complexity that hurt the average user.

4. Lowering the AMM auction slot cost:
   I agree that the AMM Auction slot isn’t being used enough because of its high cost, and lowering it is a good idea. But tying this to a fee cap increase to 2.5% doesn’t solve the root issue. Even with a lower slot cost, if fees are too high, arbitrageurs and users won’t engage. We need to keep fees low across the board to make the AMM attractive, not just tweak one part while making trading more expensive overall.

I’m all for improving the XRPL AMM, but this proposal misses the mark by focusing on LP profits over user needs. We need solutions that leverage XRPL’s strengths and prioritize adoption, easier onboarding, and user experience.

[hoos]

Thanks Panos, always appreciate your feedback. I'm planning to review and update the main article at the earliest opportunity. Ultimately I think LPs should decide on the fees within some safety limit provided by the protocol to avoid obvious scams.