Summary
The JLP allows users to swap between various tokens, helping maintain the balance of each pool in relation to its target allocations. This mechanism was initially designed to stabilize pool sizes but will also play a critical role in enabling seamless conditional orders in the future. The smooth execution of these orders relies heavily on maintaining well-calibrated fees.
Optimizing swap fees within the Jupiter Liquidity Pool is critical for providing the best user experience without discouraging transactions and protecting the pool from larger trades. Our analysis draws on historical trade data from September 2024, covering both stablecoin and non-stablecoin transactions. By leveraging the Edge Oracle price feed, we estimated realized fees and derived insights to guide our recommendations. These recommendations focus on improving the user experience, enhancing liquidity pool balance, and significantly penalizing larger trades.
Alternatively, we recommend implementing a simplified fee structure that prioritizes trade size over initial imbalance. This approach would foster more stable trading fees over time, penalize larger trades, and minimize the impact on smaller ones.
Recommendations
| Non Stable Base Fee | Non Stable Tax Fee | Stable Base Fee | Stable Tax Fee | |
|---|---|---|---|---|
| Step 1 | 50 → 10 | 120 → 500 | 20 → 2 | 20 → 50 |
| Step 2 | 10 → 8 | 500 | 2 | 50 |
Historical Data
We analyzed all trades made in September 2024 that were routed through Jupiter. To estimate the fees paid, we utilized the Edge Oracle price feed to determine the value of both the input and output tokens. While this method does not directly reflect the fees charged by other protocols, it accounts for price oracle deviations, which Jupiter’s pool needs to be protected against—factoring in both fees and price discrepancies.
During the analysis, we observed that several trades incurred negative fees, a phenomenon expected due to price oracle deviations and arbitrageurs’ actions. Below is a summary of aggregated data for trades involving JLP assets, WBTC, SOL, WETH, USDC, and USDT.
The following table displays weighted percentiles for trades above and below $1 million. This metric was selected because standard percentiles consider only the count of trades that paid a particular fee. In contrast, weighted percentiles factor in transaction size, offering a more representative view of the overall fee distribution.
| 10th Weighted Percentile (bps) | 50th Weighted Percentile (bps) | 90th Weighted Percentile (bps) | |
|---|---|---|---|
| Non Stable | -1.21 | 2.12 | 9.56 |
| Non Stable (>1M) | 11.77 | 18.51 | 22.11 |
| Stable Swaps | -0.57 | 0.68 | 1.90 |
| Stable Swaps >1M | 0.79 | 0.94 | 3.02 |
At first glance, it is clear that the fees charged by other protocols are significantly lower than the base fees on Jupiter Perps, which are set at 20 basis points (bps) for stablecoins and 50 bps for non-stablecoins. This discrepancy partially explains the low volume of swaps being routed through the JLP pool.
For non-stablecoin trades, we observe that a fee range of 2 to 10 basis points (bps) is generally acceptable for smaller trades. However, for trades exceeding $1 million, fees typically rise above 18 bps. Implementing similar fee structures in the JLP pool may not always be feasible, as they depend heavily on the level of imbalance within the pool. Therefore, we will analyze potential fee values under different conditions.
For stablecoins, liquidity is generally more concentrated, leading to similar fees for trades above $1 million as those charged in other stablecoin-focused swaps. We are considering parameters that would result in fees ranging from 0.5 to 2 bps for smaller trade sizes, while fees for trades exceeding $1 million would be set at over 3 bps.
Swapping Mechanism Overview
Before discussing the recommendations, it’s essential to understand the mechanism behind Jupiter’s swap fees. The fee structure differs between stablecoin swaps and non-stablecoin swaps and is determined by two key constants: the base fee and the tax fee.
In Jupiter’s contracts, the fees are calculated based on the initial and final imbalances of the liquidity pools involved in the trade. For each pool, the contract compares the initial difference from the target pool size to the final difference after the swap, and the fee is adjusted accordingly.
Fee Calculation Logic:
-
initialDiff = targetAmount - currentAmount
finalDiff = initialDiff + tradeSize
-
If |initialDiff| > |finalDiff| then:
- If |initialDiff| < |finalDiff| then
- Finally, the fee is computed as:
Key Properties of the Fee Mechanism
- Tax Fee as Price Impact Protection: The tax fee safeguards against large price imbalances by imposing higher fees when there is a significant deviation from the target pool size, helping to reduce drastic imbalances in the liquidity pools.
- Imbalance and Fee Relationship: For the fee to be lower than the base fee, both pools must improve their imbalances. Even if the overall system imbalance improves, the fee will remain above the base fee if one of the pools worsens. As a result, most trades tend to incur fees higher than the base fee.
Current Parameters
| Base Fee (bps) | Tax Fee (bps) | |
|---|---|---|
| Non Stable | 50 | 120 |
| Stable | 20 | 20 |
Analysis
Non Stable Swaps
The impact of the base fee is relatively straightforward; we believe that a range between 8 and 12 basis points (bps) is the most appropriate for protecting the pool while still maintaining acceptable trading fees.
In the initial analysis, we will use a 10 bps base fee. To assess the impact of an 8 bps base fee, we can subtract 2 bps from all relevant values.
We will start by examining a perfectly balanced pool.
png)
We observed that even with a tax fee of 1000, larger trades will not generate the high fees we desired. However, as we will examine in subsequent scenarios, further increasing the fee may not be feasible.
In the Solana pool, the $1 million trade fee remains significantly lower than expected. However, it is important to note that the final fee paid reflects the maximum imbalance created. Thus, a $1 million trade on a perfectly balanced pool will incur a minimum fee of the Base Fee + 2.1 bps (assuming the trade is from SOL to USDC).
Next, we will analyze how these values shift as pool imbalance increases. To define imbalance, we adopted an intuitive approach: for example, if the Distance from Target is 0.5, the Solana weight would be adjusted to 44% + 0.5% = 44.5%. A positive trade representing the sale of Solana to the pool would result in a higher fee.
We also show the expected fees for the JLP pool at the time of writing (December 3rd).
From the previous plots, we can observe that unless the imbalance remains small, fees will vary substantially depending on the trade direction. In the future, this could have an additional impact for limit orders, as users do not have complete control over the exact timing of their trades. Consequently, if there is a significant shift in pool weights between the creation and execution of an order, the fee paid may differ significantly from the initial expectation.
Reducing the fees will help facilitate normal flow from the Jupiter DEX aggregator, which would eventually rebalance the pool. To evaluate this impact, we need to make some assumptions.
Let’s assume that any time a route through JLP incurs a fee of less than 2 bps (the 50th percentile), transactions would be routed through JLP, thus helping to balance the pool. Additionally, given the high volume passing through JLP, this would substantially affect JLP weights. From this, we can estimate an approximate upper bound for the imbalance in each pool as:
| Fees (base - tax) | 10 - 100 | 10 - 500 | 10 - 1000 |
|---|---|---|---|
| SOL | 3.52% | 0.704% | 0.352% |
| WBTC | 0.88% | 0.176% | 0.088% |
| WETH | 0.8% | 0.16% | 0.08% |
| USDC | 2.08% | 0.416% | 0.208% |
| USDT | 0.72% | 0.144% | 0.072% |
We can see that a higher Tax Fee may attract more volume to the JLP Pool and significantly improve its balance as it provides better discounts for smaller imbalances.
Assuming sufficient flow to maintain pool balance, these fees are paid at equilibrium.
This data demonstrates that, under equilibrium assumptions, all Tax Fee levels perform similarly since bigger Tax fees offer better discounts for rebalancing, so it expects a tighter balance at equilibrium. However, it’s important to recognize that various unbalancing factors (such as traders’ P&L, deposits, and withdrawals) may make maintaining a consistently tight balance challenging, especially for higher tax fees, where the computed expected equilibrium is less than 0.5%.
After reviewing all possibilities, we conclude that, with the current fee structure, pool size alone makes it challenging to ensure fees scale appropriately with trade size.
For non-stable swaps, a fee of 10 bps—already higher than the 90th percentile of fees paid in trades routed through the Jupiter DEX aggregator—sits at the higher end of the acceptable range. Thus, we do not see a need to initiate the transition with higher values. However, the fee could be reduced to 8 bps in the future if desired.
Additionally, we recommend implementing a tax fee of 500. A higher tax fee would not meaningfully increase fees for larger trades but would disproportionately impact smaller trades when the pool is imbalanced.
- Step 1: Base Fee 10, Tax Fee: 500
- Step 2: Base Fee 8, Tax Fee: 500
Stable Swap
For stable swaps, a similar logic applies; however, the equilibrium level will likely be more influenced by non-stable swap fees than by the stable swap fee. Also, stablecoin liquidity is typically more concentrated, meaning that even large trades often incur competitive fees.
We are considering parameters that would result in fees ranging from 0.5 to 2 bps for smaller trade sizes and exceeding 3 bps for trades larger than $1 million.
We recommend a base fee of 2 bps, which is slightly higher than the 90th percentile of fees paid in trades routed through the Jupiter DEX aggregator. Next, we will examine how fees vary based on trade size, imbalance, and tax fee to determine the most suitable tax fee structure.
A tax fee 10 appears to work better for the current imbalance; however, it results in lower fees than desired for larger trades. For this reason, we recommend setting the tax fee at 50.
- Base Fee: 2, Tax Fee: 50
Recommendations with Mechanism adjustment
To address the issue that swap fees heavily depend on the initial imbalance, and with pool sizes constantly increasing, we cannot substantially increase the Tax Fee without causing even small swaps in a slightly imbalanced pool to incur excessively high fees. We propose a simple, easy-to-implement solution that can be readily adjusted if the pool size changes in the future.
We suggest to use a virtual trade size to compute the finalDiff by using a multiplier:
vTradeSize = multiplier\times tradeSize.
finalDiff = initialDiff + vTradeSize
The rationale behind these changes is to use the multiplier to give more weight to the trade size relative to the initial pool imbalance. This value can be easily adjusted in the future if there are significant changes in the pool size.
Another key advantage of this mechanism is that it only penalizes trades that disrupt the pool’s balance. Since we can decrease the Tax Fee, it will reduce the overall discounts.
There is one minor downside, although it could be addressed with a more extensive change to the smart contract. With these adjustments, it’s possible that a trade could improve the pool balance; however, using the vTradeSize instead of the actual size may result in initialDiff > vFinalDiff, leading to the trader paying above the base rate.
However, this would only impact significantly larger trades, improving the imbalance on both sides of the transaction.
Recommendation: Non Stable-swap
Multiplier = 100
With this change in place, we can review the same data as before but with a reduced Tax Fee. After some analysis, we believe a multiplier of 100 is appropriate for the current pool size:
With these changes, we can more effectively protect the pool from larger trades while ensuring that fees for smaller trades are less dependent on the pool size.
- Step 1: Base Fee: 10, Tax Fee: 100, Multiplier: 100
- Step 2: Base Fee: 8, Tax Fee: 100, Multiplier: 100
Recommendation: Stable-swap
Multiplier = 100
By introducing the same multiplier, we could achieve better protection against larger trades and maintain more stable fees independent of the pool imbalance
With the introduction of the multiplier, we can observe that the recommendation of 2 base fee and a 5 Tax Fee performs as desired in most situations.
- Base Fee: 2 bps, Tax Fee: 5 bps, Multiplier: 100