Enhancing LP Fees Management on xExchange

[xclaudiu]

Currently, on the xExchange platform, the fees earned by liquidity providers (LPs) are directly added to their existing LP positions, increasing the overall value but making it difficult to track profitability separately. To improve transparency and control for LPs, I propose the following enhancements:

1. Separate Fee Accrual: Instead of directly adding fees to the LP position, earned fees should be distributed separately in the form of the two tokens that make up the liquidity pool. For example, if an LP provides liquidity for WBTC-EGLD, their earned fees would be accrued as separate WBTC and EGLD balances, distinct from their primary LP tokens.
2. Fee Claiming Without LP Withdrawal: LPs should have the ability to claim their accrued fees without having to withdraw and break their entire LP position. This could be done periodically, either based on a minimum fee value threshold (e.g., $5 worth of fees) or at regular intervals (e.g., weekly).
3. Consolidated Fee Claiming: A convenient “Claim All Fees” button should be available, allowing LPs to claim all their accrued fees across multiple liquidity pools in a single transaction. This would streamline the process and provide a clear overview of total fees earned.
4. Optional $MEX Conversion: LPs should have the option to convert their claimed fees directly into the platform’s native token, $MEX. This could be achieved by using the claimed fees to purchase $MEX from the market, providing LPs with a seamless way to accrue and accumulate the platform token. The same for Fees Rewards from Energy Holders.

By implementing these enhancements, xExchange would empower LPs with greater transparency, control, and flexibility over their earned fees. The ability to separately track and claim fees would allow for more accurate profitability analysis, while the consolidated claiming process and optional $MEX conversion would introduce convenience and potential incentives for LPs to engage more deeply with the platform’s ecosystem.

These changes would not only improve the user experience for LPs but could also foster increased liquidity provision and stronger alignment with the platform’s goals, creating a more robust and attractive environment for market makers and traders alike.

[lucaswillems]

Hey @xclaudiu , thank you very much for sharing this feedback!

The main difficulty is technical and is due to the design of the smart contracts themselves.

But indeed, such proposed enhancements would bring more clarity on the fees an LP earn. And it would be great to have this improved

[xclaudiu]

Hello Lucas (@lucaswillems),

Thank you for taking the time to review my proposal. I understand that modifying the existing smart contract design presents significant technical challenges, which is why I have attempted to propose an alternative solution that could potentially be implemented without altering the core DEX contract.

After analyzing the current fee distribution mechanism within the contract, here is my understanding of how it operates:

This is my understanding of how the contract works ( I am not a Rust Developper so maybe I am wrong here) :

1. Swap Fee Calculation:

The swap fee is calculated as a percentage of the input token amount. The percentage is determined by the total_fee_percent variable set in the DEX contract.

2. Special Fee Extraction ( the Fee for xMEX holders and MEX burn) :

The special fee is calculated as a percentage of the input token amount after deducting the total fee. The percentage is determined by the special_fee_percent variable.

3. Special Fee Distribution:

The special fee is distributed in two ways:

a)Fees Collector: A portion of the special fee, defined by the fees_collector_cut_percentage, is sent to the Fees Collector Contract => for xMEX holders

b) Fee Destinations: The remaining special fee is divided equally among the configured fee destinations => (MEX Burn)

4. Remaining Fee (Liquidity Providers):

The remaining portion of the total fee (after deducting the special fee) is added to the liquidity pool reserves. This increases the value of the pool and indirectly benefits liquidity providers when they remove their liquidity or when others swap tokens.

Example:

Given the current parameters:

• total_fee_percent: 0.3%
• special_fee_percent: 0.1%
• fees_collector_cut_percentage: 50%

For a 1000 token swap, the fee distribution would be as follows:

• Total fee: 3 tokens (1000 * 0.3%)
• Special fee: 1 token (1000 * 0.1%)
• Fees Collector contract receives (for xMEX holders) : 0.5 tokens (50% of special fee)
• Fee destinations (MEX burn): 0.5 tokens (Remaining special fee)
• Liquidity pool reserves: 2 tokens (Remaining total fee after deducting special fee)

I would like to propose the following changes:

1. Adjust the fee parameters:

• Increase the special_fee_percent to 0.3% to match the total_fee_percent
• Change the fees_collector_cut_percentage to 83.33%

2. Introduce a new “Main Fee Collector” smart contract:

• This contract would receive the 83.33% portion of the special fees from the DEX contract
• It would distribute the collected fees as follows:
  • 20% to the existing Fees Collector contract (for xMEX holders)
  • 80% to a new “LP Fees Collector” contract

3. Implement the “LP Fees Collector” contract:

• This new contract would accumulate the special fees received from the Main Fee Collector
• It would track LP token balances to determine each owner’s share of the accumulated fees, achieved through either periodic snapshots or event-based tracking of token transfers
• A “claim” function would allow LP owners to withdraw their share of the accumulated fees periodically (e.g., weekly) or upon reaching a certain threshold

With the proposed changes, using the same 1000 token swap example, the fee distribution would be as follows:

• Total fee: 3 tokens (1000 * 0.3%)
• Special fee: 3 tokens (1000 * 0.3%)
• Main Fee Collector contract receives: 2.5 tokens (83.33% of special fee)
  • Fees Collector contract (20% of 2.5): 0.5 tokens
  • LP Fees Collector contract (80% of 2.5): 2 tokens
• MEX burn: 0.5 tokens (Remaining special fee after fees_collector_cut_percentage)
• Remaining fee added to liquidity pool reserves: 0 tokens

In this scenario, the LP Fees Collector contract would accumulate 2 tokens from the special fee, which LP owners could then claim periodically based on their proportional LP token holdings tracked by the contract.

By implementing these changes, we could provide LPs with a more transparent and flexible way to manage their earned fees, while still ensuring a fair distribution to xMEX holders. The ability to claim fees separately from their LP positions could foster better profitability analysis and potentially encourage increased liquidity provision.

I understand that this proposal may require substantial development efforts, but I believe the potential benefits to the platform’s ecosystem and user experience could be significant. I welcome any feedback or suggestions you may have to further refine or improve upon this proposal.

Thank you for your consideration, and I look forward to continuing this discussion.

[lucaswillems]

@xclaudiu

It would track LP token balances to determine each owner’s share of the accumulated fees, achieved through either periodic snapshots or event-based tracking of token transfers

Hey @xclaudiu !

Thank you for sharing your thoughts further!

This is the very difficult part:

• It would track LP token balances to determine each owner’s share of the accumulated fees, achieved through either periodic snapshots or event-based tracking of token transfers

For example, what happens if the person sends his LP to another person?

[xclaudiu]

Hello Lucas (@lucaswillems ),

Thank you for your continued dialogue on this topic. I’ve refined my proposal further to improve how we track and distribute LP fees on the xExchange platform. Both approaches I propose involve binding fees to the address, rather than to the LP tokens themselves. The key distinction between the two lies in how we determine each owner’s share of the accumulated fees
a) Real-Time Fee Binding with Event-Triggered Snapshots

Proposal: Each time the “LP Fees Collector” receives fees from the “Main Fee Collector,” a real-time snapshot of addresses that hold LP tokens and their proportional share of the fee is taken based on their token amount. If an LP token is transferred to another address, the fees accrued up to that point remain tied to the original address, while new fees start accruing to the new address from the time of the transfer.

Advantages:

• Immediate Clarity and Ownership: Fees are directly linked to addresses, providing immediate transparency for users on their accrued fees.
• Simplicity in Token Transfers: Transferring LP tokens does not complicate fee ownership, making the user experience straightforward.

Challenges:

• Resource Intensity: This approach requires active management and computation each time fees are distributed or tokens are transferred, which might increase the costs and system load.

b) Periodic Fee Binding with Daily Snapshots

Proposal: Implement a daily snapshot system where every 24 hours, the platform captures a snapshot of all addresses that hold LP tokens. This snapshot records each address’s exact LP token balance at that specific time. Over the course of the day, any transactions involving LP tokens—such as transfers, liquidity additions, or withdrawals—are logged by the system.

At the end of each day, the “LP Fees Collector” contract calculates the total fees accrued from swaps. These fees are then distributed among LP token holders based on their proportional ownership as recorded in the daily snapshot. The key steps involved include:

1. Snapshot Capturing: At a predetermined time each day, the system captures the state of LP token balances across all addresses. This serves as the baseline for calculating each holder’s fee entitlement for that day.
2. Transaction Logging: Throughout the day, any change in LP token ownership due to transfers, liquidity additions, or withdrawals is tracked. This ensures that all movements are accounted for in the day’s fee calculations.
3. Fee Calculation and Distribution: Based on the snapshot and the day’s logged transactions, fees collected in the “LP Fees Collector” are apportioned to addresses according to the time-weighted average of their LP token holdings. This means that if an address held tokens for a part of the day, their fee share is calculated proportionally to their holding duration and amount during that 24-hour period.
4. Handling Transfers: If LP tokens are transferred from one address to another, the system calculates the sending address’s entitlement up to the time of transfer and starts accumulating fees for the receiving address from the moment of transfer, based on the remaining part of the day.

Advantages:

• Systematic Fee Allocation: This method ensures a systematic and equitable distribution of fees, as each LP’s fee share is directly proportional to their token holdings and the duration those tokens were held within the day.
• Reduced Operational Complexity: By consolidating fee calculations to once per day, the platform can manage computational and operational complexity more effectively, potentially reducing costs.

Challenges:

• Timing of Fee Updates: The main drawback is the delay in reflecting fee distributions, as updates are only made once per day. This could affect LPs’ decisions regarding their liquidity strategies.

Both proposals aim to enhance transparency and fairness in fee distribution by decoupling fee accrual from LP token ownership, addressing the core issue of tracking and managing LP fees more effectively. I am keen to hear your thoughts on these approaches and any further insights you might have.