How LP fees flow
Both sides of every fee, end to end: compound + buyback + recipient, compound + burn + recipient.
The pool's LP program earns swap fees in both currencies, and each side has its own three-way waterfall — chosen by you, validated at write time, executed identically on every harvest. This chapter is the management view: the two flows end to end, why they are deliberately asymmetric, and which lever controls what.
The two waterfalls, side by side
compound + buyback ≤ 100%
compound + burn ≤ 100% · burn = 0 on a native main
Why the two sides are different
The asymmetry is the machine's logic, not an arbitrary menu. The secondary side is the buyback currency — so its special destination is the pot: a buybackShare makes the pool fund its own buyback pressure from its own traffic, forever. The main side is the defended asset — so its special destination is destruction: a burnShare cuts supply at the source, before those tokens ever circulate. Sending main to the pot would be pointless (the pot only spends secondary), and burning secondary would burn the wrong asset. Each side gets exactly the lever that makes sense for what it is.
| destination | side | what it does | deep dive |
|---|---|---|---|
| compound | both | re-mints as liquidity in the program's own position; what doesn't fit carries | Autocompound |
| buyback | secondary | credits the pool's own pot — self-fueling pump & shield | The pot |
| burn | main | destroys the fees through the verified burn cascade | The burn share |
| recipient | both (one each) | receives the exact remainder — treasury, rewards, vesting, anything | The recipients |
One config, seven WAD numbers
The last two dials govern not the fees but what the pot buys with them — the buyback split, taken apart in Buy back management.
All of it lives in one struct, written by one call (setProgramConfig), owned by one role (the program operator), and checked when it is written — over-100% sums, a missing recipient under a real remainder, a burn on a native main: every invalid shape is rejected at the door, so harvest time is pure arithmetic. Edits are forward-only: fees already pending split under whatever config is live when the harvest actually runs.
This section is where fees are allowed to go. When harvests fire and the exact formulas live in Auto-harvest; how the compound budget becomes liquidity lives in Autocompound. The three chapters after this one take each destination apart.
The three chapters of this section
FAQ
What are the seven numbers in one config?+
Per side: secondary → compound share + buyback share; main → compound share + burn share (the remainder of each side goes to its recipient), plus the two recipients and the harvest minimums packed in the same struct.
Which side funds the pot?+
The secondary side's buyback share: that slice of every harvest is credited straight to the pot, making the machine self-funding from the pool's own traffic.
Do LP fees and the buyback split interact?+
They're two independent stages: LP fees split at harvest time; pump/shield output splits at buyback time. Both can compound into the same position and both are edited by the same operator.
Can the shares sum to less than 100%?+
Yes — the remainder of each side is exactly what the recipient receives. Shares above 100% per side are rejected at write-time with BadConfig.
When do the fees actually move?+
At harvest: automatically inside a swap once the configured minimums are reached (within a gas budget), or manually via harvest(key) with full gas, callable by the owner — or by anyone once the owner surrendered.