Swap fees stay in the pool, where liquidity providers own a proportional claim on them. For a treasury using a constant-product pool for recurring trades, that means fee income is embedded in token balances rather than paid out after each swap.
Each swap increases the pool’s fee-bearing reserves
In a constant-product pool, the contract quotes trades against two reserve balances, x and y, under the rule x × y = k. In a typical V2 design, the trader pays a 0.30% fee; the pool uses the fee-adjusted input to calculate the output, but the full input token amount arrives in the contract.
For example, with 100,000 USDC and 50 WETH in reserve, a 1,000 USDC trade at a 0.30% fee returns about 0.4936 WETH. After the swap, the balances are 101,000 USDC and about 49.5064 WETH: the difference between the full input and fee-adjusted input slightly raises k, while the trader’s output moves the price along the curve.
The Uniswap v2 Core whitepaper describes this balance-based accounting: the pair checks its final balances against the fee-adjusted invariant after a swap. There is no separate fee ledger to claim; the pool’s accounting reflects the trade in its reserves.
Liquidity shares turn reserve growth into a claim
A V2 liquidity provider holds pool tokens representing a fraction of the pool, not an account that accrues a separate fee balance. If the treasury owns 2% of the pool when it withdraws, it receives 2% of each current reserve, subject to any protocol-fee mechanism configured for that pool.
Think of it as owning a fixed fraction of a cash box that receives payments in two currencies: the share count stays fixed, but the box’s contents change. QuickSwap’s V2 documentation describes its typical 0.30% swap fee as added to reserves and realized when liquidity providers burn pool tokens to withdraw; its documentation says a protocol charge is not currently active for that model, though the contracts allow one to be enabled.
That makes QuickSwap crypto a useful example when assessing whether a treasury position can support regular transfers: fees increase the withdrawal claim, but they do not create scheduled cash receipts. The treasury must unwind some liquidity to turn that claim into spendable tokens, and the pool’s token mix at that time may differ from the deposit mix.
Reserve growth is not the same as treasury profit
Fee growth can be outweighed by price movement. If arbitrage trades rebalance a pool after the market price changes, the treasury may withdraw a different mix of assets than it deposited; compare the position’s current value with a hold-the-tokens baseline, net of fees, gas, and any protocol share.
Volume alone is a poor revenue forecast. A 0.30% fee on a trade is shared across all liquidity in that pool, and the treasury earns only its pro-rata portion while its capital is exposed; actual results also depend on turnover, pool depth, price divergence, and the period the position remains open.
Model withdrawals around the pool’s actual state
Before committing treasury assets, identify the chain, pool version, fee tier, fee configuration, and contract address, then confirm the live reserves and total pool-token supply. For QuickSwap V2, use the documented fee model only for the matching V2 pool; do not carry that assumption over to V3, where liquidity ranges and fee collection work differently.
For payouts, set a liquidity withdrawal schedule and retain enough of each required token outside the pool to cover near-term obligations. Model fees as a variable increase in the position’s redeemable reserves, then stress-test lower volume, adverse price moves, and the gas and slippage needed to withdraw; proceed only if the resulting token mix and timing fit the treasury mandate.