Sunswap

Sunswap V1 and V2 charge the same pool fee but distribute it differently

Sunswap V1 and V2 both charge 0.3% per pool swap, with different recipients for that fee. V1 assigns the whole fee to liquidity providers (LPs). V2 assigns 0.25% of swap input to LPs and 0.05% to SUN buybacks and burns. Those V2 allocations add up to 0.3%, so the burn allocation is already included. Comparing complete trades also requires accounting for the pools that a route uses and the TRON resources that execution consumes.

Updated on Tuesday, 13 October 2026

What does the 0.3% swap fee measure?

The 0.3% rate expresses the pool fee as a percentage of the input amount that enters that swap. The fee amount is denominated in the input asset; the rate uses the trade input as its denominator. The rate does not describe a percentage of the output token or the trader's entire wallet. Equal percentage rates can describe charges in different assets, with different quantities and market values.

V2 uses the same input basis for its LP and SUN allocations. Both components belong inside the existing 0.3% charge.

V1 fee income and V2 SUN buybacks

V1 assigns its 0.3% pool fee to LPs, while V2 directs part of that same charge toward buying and burning SUN.

V1 fees for liquidity providers

Liquidity providers collectively receive the V1 fee, with each provider's entitlement following their share of that pool. Trading in one pool generates fee income for its providers. It does not distribute that income among every LP across the protocol. Some V1 pools remain operational, although V1 is a legacy version that is no longer recommended for new pool deployments.

The V2 SUN allocation

V2 allocates 0.05% of each pool swap's input to SUN buybacks and burns. The remaining 0.25% forms the LP allocation. This changes the use of fee revenue without raising the single-pool percentage that the trader pays. Allocating revenue toward SUN purchases also differs from paying SUN rewards directly to traders or LPs. The allocation alone does not establish a completed burn for an individual swap.

The calculation behind the V2 split

The V2 allocation gives LPs five-sixths of the fee and reserves one-sixth for SUN buybacks, using the same input basis. Let A represent a pool swap's input amount. Its total fee is 0.003 × A. The LP allocation is 0.0025 × A, and the SUN buyback allocation is 0.0005 × A. These expressions describe allocations in the input asset's unit; they do not specify how many SUN tokens a later purchase acquires.

Dividing 0.0005 × A by 0.003 × A gives one-sixth of the total fee. In this split, the SUN allocation accounts for 0.05 percentage points of the total 0.3% fee rate. Multiplying 0.05% by the already calculated fee would use the wrong denominator. The corresponding LP fraction is 0.25 divided by 0.3, or five-sixths.

View image file

TRX bridging and fees at each hop

V1 token-to-token swaps pass through TRX before reaching the output token. Each underlying V1 pool pairs TRX with a TRC20 token. The first swap charges 0.3% against its input token amount. The second charges 0.3% against the intermediate TRX amount that enters that pool. Those charges use different assets and input quantities. Applying one 0.3% charge to the original input would leave out the second pool fee.

V2 supports direct pairs between TRC20 tokens, which removes the compulsory TRX bridge from the pool design. A direct pool can therefore provide a single-pool alternative when it has suitable liquidity. Universal Router can also compose paths across multiple pools and versions. V2 support does not mean every V2 route uses one pool, or that a direct path always produces more output. Pool depth and trade size affect that comparison.

Do V1 and V2 have the same total trading cost?

V1 and V2 share the single-pool percentage fee, but complete trading costs can differ with routing, execution prices, and network resource charges.

Charges across the selected pools

Every fee-bearing pool along a path applies its own rule to the amount that it processes. A route-level comparison needs those component charges. The V2 revenue split answers who receives that pool's fee; it does not replace the fees that other pools charge. Adding amounts denominated in different tokens also requires a common valuation basis.

The price that pool reserves produce

V2 calculates swap output from its constant-product pricing rule after deducting the 0.3% fee from the pricing input. Pool reserves determine the exchange amount. Price impact describes the trade's effect on pool pricing and remains distinct from the fee allocation. Two pools with identical percentage fees can therefore quote different output amounts.

TRON execution resources

TRON meters transaction bytes with Bandwidth and smart-contract computation with Energy. Staked or delegated resources can cover these costs. If available Energy covers only part of the caller's execution cost, TRX burning pays the remainder. Bandwidth follows a different rule: an eligible resource source must cover the whole byte cost. Otherwise, TRX burning pays the entire Bandwidth charge. Neither charge changes where V2 allocates its pool fee.

LP tokens and the timing of fee income

V1 and V2 record liquidity ownership through LP tokens, which represent a provider's share of the underlying pool assets. An individual provider receives a proportional interest in the pool's collective LP fee income. The 0.25% V2 allocation belongs to all participating LPs together. It does not mean each provider earns 0.25% on their own deposited balance whenever somebody trades.

V2 fee income for liquidity providers compounds automatically within the pool. Fee accumulation contributes to the assets that LP tokens represent. Providers do not need a separate fee-token deposit in their wallet after every swap. Removing liquidity redeems the corresponding pool assets, including the provider's interest in accumulated fee income. The value of those assets also follows changes in their market prices.

The 0.25% V2 allocation measures a share of traded input. It is not an annual return on deposited liquidity.

Liquidity providers also retain exposure to changes in the pool's asset mix. When token prices diverge, withdrawing a position can produce less value than holding the deposited tokens outside the pool. That difference is impermanent loss. Fee income contributes to the position's value, but a larger LP allocation does not remove this exposure. Trading volume and the provider's pool share determine how much fee income can offset it.

V3 and V4 fees as different comparison inputs

V3 offers pool fee tiers of 0.01%, 0.05%, 0.3%, and 1%, with the creator selecting the tier for that pool. A V3 pool charging 0.3% shares a numerical rate with V1 and V2. That matching number alone does not establish the V2 allocation rule. V3 also uses concentrated liquidity positions, and providers collect their earned fees manually.

V4 supports static fee tiers and dynamic fees through hooks. Its DynamicFeeHook adjusts the fee with price impact and caps that hook's rate at 5%. This limit belongs to that particular hook, rather than every possible V4 hook design. A mixed-version route therefore needs the applicable rule for each pool. The 0.05% V3 tier, for instance, describes a total pool fee; V2's 0.05% figure describes one allocation within a larger fee.

The limits of the fee split

Fee allocation alone cannot establish whether V1 produces more LP income than V2 for a particular pair and observation period. V1 directs a larger fraction of each comparable pool fee to providers. Earned income still requires trades through that pool, and each LP receives only their proportional share. A comparison that ignores actual volume cannot determine which pool generated more provider revenue.

SUN buybacks and burns identify another destination for trading revenue. The allocation does not establish a future SUN price or a fixed number of tokens burned. Purchase prices and the amount of revenue available affect the quantity that a buyback can acquire.

Helpful answers