> For the complete documentation index, see [llms.txt](https://docs.efficientdex.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.efficientdex.com/use-efficient/fees.md). # Fees What an Efficient pool charges, a swap fee and a performance fee in two parts, and what a conversion costs a depositor. **An Efficient pool charges traders a swap fee on each fill, and depositors only a performance fee on gains.** The pool has no management fee. The swap fee stays in the pool and accrues to every share. A depositor who converts through the asset router also bears the conversion's cost. That cost is capped at 1% of the conversion's value at the feed price. ## Charges | Charge | Set by | Where it goes | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Swap fee | The pool's fee hook, inside the pool's fee floor and cap | Stays in the pool and accrues to every share | | Performance fee, pool operator's part | The pool operator, up to a ceiling fixed at creation (at most 50%). A rise waits out the pool's governance delay | Minted as shares to the fee receiver the pool operator appoints | | Performance fee, protocol's part | The protocol Safe, pool by pool, up to 50%. A rise waits out the factory's upgrade delay | Minted as shares to the factory's protocol fee receiver | | Management fee | None | The pool contract has none | | Conversion through the asset router | The DEX route named in the depositor's call, at most 1% below the value at the feed price | The DEX route. The pool and the router take nothing | ## The swap fee **The swap fee is what the hooks keep back from a fill's gross output.** The pool's fee hook reports one fee rate for each swap. The trader receives the rest of the output, and the pool checks the trader's `minAmountOut` against that amount. A sell pays its fee in the loan asset, and a buy pays it in the pool asset. The loan asset is the other token in the pool's pair, which the pool can borrow. In an Efficient pool that trades BTC against USDC, it's USDC. Take $$Q$$ as the gross output and $$f$$ as the fee rate, ignoring token rounding. A fill charged on its whole output keeps a fee $$F$$:
$$ F = fQ, \qquad Q\_{\text{received}} = (1-f)Q $$ A pool's hooks can keep a fee other than $$fQ$$. That's because the pool checks the fee kept only against the gross output, never against the rate. So a pool's fee income is the sum of `feeOut` across its `Swap` events, for each token separately. It's not `feeWad` times `grossOut`. The pool refuses any fee rate outside its floor and cap with `FeeOutOfBounds`. In a pool with a price band, the band also bounds the output after the fee. [Hooks](/how-pools-work/hooks.md#what-the-pool-enforces-on-every-fill) covers both limits and who sets them. Everlong vaults run the Everlong hook. Its curve fee is dynamic and clipped to the pool's cap. Its leverage fills charge a spread instead, as [The Everlong strategy](https://docs.foreverlong.io/everlong/everlong-strategy) explains. A lever-down filled wholly at the down cap's floor keeps no spread, because that floor sets its price. A loan-to-loan swap pays no pool fee. So in a pool with a loan-to-loan swap hook, that hook's quote is the swap's whole cost. The swap path is in audit, but no such hook has shipped yet. See [Hooks](/how-pools-work/hooks.md#loan-to-loan-swaps). ## The performance fee **A pool charges the performance fee only on gains.** A gain is the rise in value per share above the pool's high-water mark. The fee has two parts, the pool operator's and the protocol's, and they charge the same gain. Each part mints new shares instead of taking assets from the pool. Take $$s$$ as the shares outstanding, $$v$$ as the value per share before the charge, $$v\_{\mathrm{hwm}}$$ as the high-water mark and $$r$$ as a part's rate. Each part mints: $$ \Delta s = s,\frac{v - v\_{\mathrm{hwm}}}{v},r $$ Both parts are struck at the share supply before either mint. The mark then moves to the value per share after the mints. So no gain is charged twice. Each charge above the mark raises the mark, even while both rates are zero. The new shares dilute every holder, the fee receivers included. So each part ends up worth slightly less than its rate times the gain. The pool charges before every proportional deposit and exit. Anyone can also trigger a charge with `skimPerformanceFee`. A charge takes nothing while the pool can't read its net asset value. In that state it also leaves the mark alone and never makes the deposit or exit revert. But a deposit still reverts with `PriceUnchecked` if the pool has a price band and either rate on. Without that revert, the uncharged gain would later be charged on the deposit's shares too. Every change to either rate first charges any fee owed at the old rates. A rise lands only if that charge can read value per share. Otherwise the rise reverts with `PriceUnchecked` and stays scheduled. So an uncharged gain can meet a lower rate, but never a higher one. A pool with no price band charges neither part. It takes no rise of either rate, though a cut still lands. The pool operator's rise reverts with `NoBand` when scheduled. Any other scheduled rise waits for a band. ### The pool operator's part The pool operator sets its rate with `setPerformanceFeeBp`. The rate can go up to a ceiling, `maxPerformanceFeeBp`, fixed at creation. The ceiling can't exceed 5,000 bp (50%), so the two parts together never take more than the whole gain. A rise waits out the pool's governance delay. Then anyone can land it with `executePerformanceFee`. A cut applies at once and clears any scheduled rise, and so does setting the current rate again. The first Everlong vault's rate is zero, its ceiling is 50% and its governance delay is 10 days. ### The protocol's part The protocol Safe sets each pool's protocol rate through the factory's `scheduleProtocolFee(pool, feeBp)`. The rate is at most 5,000 bp (50%). The protocol's shares go to the factory's protocol fee receiver. The Safe sets that receiver, and it can never be zero. A rise waits out the factory's upgrade delay. Then anyone can land it with `executeProtocolFee(pool)`. Before it lands, the Safe can cancel it with `cancelProtocolFee(pool)`. A cut applies at once. A new pool starts at the factory's default rate, which the Safe sets with `setDefaultProtocolFeeBp`. A cut to the default applies at once and clears any scheduled rise. Once the upgrade delay has passed, anyone can land a rise with `executeDefaultProtocolFee`. For the first Everlong vault, the protocol rate and the factory's default are both zero, and the upgrade delay is 10 days. ## Costs of entering and exiting **A proportional deposit or exit carries no charge of its own.** `depositProRata` and `redeemProRata` move the shares' slice of every leg of the book. So neither needs a conversion. The pool first charges any performance fee owed. So an exit bears its share of that fee. A deposit is priced after the charge and bears none. Each asset router conversion must return at least its input's value at the pool's checked feed price, less 1%. Otherwise the whole transaction reverts. The depositor's own minimum can set a tighter limit. The [entry market](/use-efficient/provide-liquidity.md#the-entry-market-intents-for-shares) and the tranche controller charge no fee of their own. An entry market request costs at most the discount it has reached. [Provide liquidity](/use-efficient/provide-liquidity.md) compares the routes in and out. ## Reading the fees | Call | What it shows | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `limits()` | The fee floor and cap, the rate of each part of the performance fee, the pool operator's ceiling, the high-water mark and any scheduled rise of the pool operator's rate | | Factory `pendingProtocolFee(pool)` | A scheduled rise of the pool's protocol rate and when it can land | | `identity(pool)` on the [lens](/integrate/swaps-for-aggregators-and-solvers.md) | Both fee receivers, with the pool's other addresses and roles | [Understanding returns](/use-efficient/provide-liquidity/understanding-returns.md) shows how the swap fee and the performance fee move value per share.