PulseX fees: where the 0.29 % goes in v1 and v2

Where does the 0.29 % go?

The fee never leaves the pool at the moment of the trade: it stays in the reserves and raises the value of every LP token. Part of that growth is later minted as extra LP tokens to feeTo — the protocol’s fee receiver — but only when someone adds or removes liquidity (_mintFee, PulseXFactory.sol:366-384).

The two pool generations use identical pair code except for this one share. Which generation a pool belongs to therefore decides whether liquidity providers earn trading fees.

How does v2 split the fee?

In v2 the denominator of the fee formula is rootK × 22 / 7 + rootKLast (v2 PulseXFactory.sol:376), which mints LP tokens worth 7/29 of the growth of √k to feeTo; the comment above it says the same (:365). Of 0.29 %, 7/29 is 0.07 % per trade for the protocol and 22/29 is 0.22 % for liquidity providers.

Why does v1 send the whole fee to the protocol?

The v1 comment says the protocol should get one sixth (v1 PulseXFactory.sol:365), but the line that computes it is:

uint denominator = rootK.mul(uint(4998) / uint(10000)).add(rootKLast);

uint(4998) / uint(10000) is integer division in Solidity and equals 0. The denominator is therefore just rootKLast, and feeTo receives LP tokens worth the whole growth of √k since the last liquidity event — the entire 0.29 % fee accrued in that period, not a share of it (v1 :376).

For comparison: had the factor been evaluated as 0.4998, the protocol would have received about two thirds of the growth. The actual mints are about 1.5 times that, i.e. all of it.

How was this checked on the chain?

The fee mints were read on the WPLS/PLSX pair of each generation (v1 0x1b45b9148791d3a104184cd5dfe5ce57193a3ee9, v2 0x149b2c629e652f2e89e11cd57e5d4d77ee166f9f). For each mint, the pair’s LP supply and kLast were read at the block before, the reserves were taken from the pair’s Sync event immediately before the mint in the same block, the expected mint was computed with each formula, and the result was compared with the actual Transfer from the zero address to feeTo in the logs.

The v2 rows confirm that the method reproduces the documented split, so the v1 result is not an artefact of the check. With reserves taken from the end of the previous block instead, the v1 results deviate by up to 0.0087 %, because other trades in the same block came before the mint. Re-checked on 2026-10-17.

Was the v1 behaviour intended?

No official statement has been found that says whether the v1 fee split was intended. The code comment points one way, the arithmetic and the chain the other. This page states what was verified on-chain on 2026-10-17 and does not speculate about intent.

What does this mean for liquidity providers?

Our reading of the code and the check above:

• v2 pools pay liquidity providers 0.22 % of every trade, like a normal Uniswap v2 pool with a protocol fee.
• v1 pools: each time liquidity is added or removed, the protocol mints itself LP tokens worth all the fee growth since the previous such event. Liquidity providers in v1 pools therefore earn no fee income from trades; they keep only the pool position and its price exposure. More PLSX is bought and burned instead.

Before adding liquidity, check whether the pool is a v1 or a v2 pair: the pair contract’s factory value on the explorer is either the v1 factory 0x1715a3E4A142d8b698131108995174F37aEBA10D or the v2 factory 0x29eA7545DEf87022BAdc76323F373EA1e707C523.

What happens to the protocol’s share?

The feeTo address of each factory is a PLSX buy-and-burn contract (v1: 0xd46bd969d995a122ad5b803a45d309021a647b87, v2: 0xd6ca7ee047a6f45d20d2962e4394e070cf27724f, both upgradeable proxies with the same code). It redeems the LP tokens it received for the underlying tokens, swaps them step by step towards WPLS and then PLSX, and burns the PLSX (PLSXBuyAndBurnUpgradeable.sol:192-291).

From each batch of bought PLSX (:253-263):

For a v2 trade this means roughly 0.07 % × 14.29 % ≈ 0.01 % of volume to the developer address and about 0.06 % of volume used to buy and burn PLSX. For v1 pools the same split applies to the whole fee (about 0.04 % and 0.25 %, before the costs of the conversion swaps). Conversions can only be triggered by whitelisted addresses (anyAuth = false, :192-196).

Who can change the buy-and-burn?

One setting deserves a note: the burn amount is only computed inside the bounty branch (:258-263). If the owner set BOUNTY_FEE to 0, PLSX.burn would be called with 0 — burning would stop without any upgrade, the bought PLSX would stay in the contract, and each later conversion would still pay the developer cut out of that balance. On 2026-10-17 the bounty was 10 basis points, so burning works.

These are on-chain powers visible in the verified source; none of them can touch liquidity in the pools. They do mean that what happens to the protocol’s share after the swap — not the 0.29 % itself — depends on single-key owners and on the whitelisted callers. Re-check the current values on the explorer before relying on them.

How much PLSX has been burned?

The contract reports burnedPLSX() as starting supply minus current supply (:90-93). On 2026-10-19 (block 27,837,219): 1,793,575,624,782.03 PLSX burned out of a starting supply of 143,116,599,865,548.70 PLSX — about 1.25 %. More about the token: PLSX.