The short answer: the swap fee goes to the liquidity providers whose liquidity is active at the moment of the trade, and in some cases a portion goes to the protocol itself. That is the confirmed framing from the Uniswap developer documentation on fees. Everything else — how much, when, and in what form — depends on the protocol version.
For founders and operators building a business model around a DeFi venue, the honest starting point is that "swap fee revenue" is not one thing. It is a set of claims on pool activity that differ by version, by position, and by governance.
What the documentation establishes
The documentation states that a swap fee is charged on every trade and accrues to the LPs whose liquidity is active at the time of the swap. Fees are distributed pro-rata: the more liquidity you provide in the active price range, the larger your share.
It also states that how fees are set, collected, and distributed varies by protocol version. That single sentence is the reason a generic "DeFi fee" assumption breaks down in financial models.
Version-by-version comparison
The table below summarizes only what the source states, without extrapolation.
| Dimension | Uniswap v2 | Uniswap v3 and v4 |
|---|---|---|
| Fee level | Every pool charges a flat 0.30% fee | v3 has standard tiers of 0.05%, 0.30%, and 1%; v4 removes fixed tiers entirely |
| How fees accrue | Automatically added to pool reserves | Collected separately as claimable balances tied to each position |
| Claim process | No separate redemption described | Must be manually redeemed by the position owner |
| Compounding | Automatic, because fees increase k, the constant product invariant | Fees accumulate as claimable balances until redeemed |
| Fee choice | Flat 0.30% per pool | v3 allows multiple pools per pair at different tiers; v4 lets pool creators set any fee from 0% to 100% in 0.0001% increments, including dynamic fees via hooks |
| Range dependence | Not described as range-based | LPs choose a price range; only in-range liquidity earns fees |
The active-liquidity nuance that changes the model
In v3 and v4, LPs choose a price range for their position. Only in-range liquidity — positions whose range spans both sides of the current spot price — earns fees. If the price moves outside a position's range, that position stops accruing fees until the price re-enters.
The documentation puts the consequence plainly: LP fee income depends on two factors, how much liquidity you provide and how well your chosen range tracks the market price. For a business model, this means fee revenue is not a static percentage of volume. It is a function of range management skill as well.
In v2, by contrast, the fee is automatically added to pool reserves and compounds because it increases k. There is no separate redemption step described, and no range selection.
Fee tiers and governance
Uniswap v3 introduced fee tiers, allowing multiple pools for the same token pair, each with a different fee. The standard v3 tiers are 0.05%, 0.30%, and 1%. Additional fee tiers can be enabled by UNI governance. Uniswap v4 removes fixed tiers entirely: pool creators can set any fee from 0% to 100% in 0.0001% increments, and pools can use dynamic fees that adjust in real time through hooks.
For anyone modeling protocol revenue, that is a material design difference. A governance-enabled tier and a creator-set fee are both fee-setting mechanisms, but they sit with different actors.
A worked example (Hypothetical)
The source does not provide a numerical scenario, so the following is Hypothetical and illustrates mechanics only, not expected performance.
Suppose a pool charges a 0.30% fee and a Hypothetical 1,000,000 in swap volume occurs while an LP's position is in range with a 10% share of active liquidity. The fee pool generated is Hypothetical 3,000, and the LP's share is Hypothetical 300. If the price then moves outside that LP's range, subsequent swaps generate Hypothetical 0 for that position until price re-enters the range. A second LP whose range spans the new price would instead earn the fees on those later trades.
The example makes the core point: identical volume produces different LP outcomes depending on range placement. That is a management variable, not a constant.
A business-model checklist
- Identify the protocol version. Fee setting, collection, and distribution differ by version, so a single assumption across v2, v3, and v4 is unsupported.
- Separate LP fees from protocol fees. The source notes that in some cases a portion goes to the protocol itself, but does not quantify it for each version.
- Check whether fees compound or are claimed. In v2 they are automatically added to reserves; in v3 and v4 they accumulate as claimable balances that must be manually redeemed.
- For v3 and v4, model range behavior. Only in-range liquidity earns fees, and out-of-range positions stop accruing.
- For v4, check who sets the fee. Pool creators can set any fee from 0% to 100%, so fee level is a design choice rather than a fixed tier.
- For v3, check the tier. Standard tiers are 0.05%, 0.30%, and 1%, and additional tiers can be enabled by UNI governance.
What the source does not say
The documentation does not state a protocol fee percentage, a switch-on condition, or how protocol fee revenue is allocated. It does not quantify LP returns, impermanent loss, or volume, and it does not provide a formula for expected fee income. It does not say whether or how v2 pools can change their fee, or list every possible fee tier beyond the standard v3 set. It also does not address token price, valuation, or any relationship between protocol fees and a token's market value.
Those gaps matter for business planning. A model that needs a protocol revenue figure cannot be completed from this source alone. A model that needs only the mechanics of who receives swap fees can be, provided the version is specified and the range behavior is treated as a variable.
What to take away
The fee recipient question has a clean answer at the general level: active LPs, with possible protocol participation. The business-model question is harder because the same words cover three different mechanisms. Version, tier or fee level, range placement, and claim versus compound are the four levers that determine what a fee stream actually looks like. Any projection that does not name those levers is an assumption dressed as a fact.