Buy back management
The buyback split: compound a share of every purchase into liquidity, burn a share, deliver the rest.
The pot decides how much main to buy; the LP program's operator decides what happens to it. The buyback split carves every pot purchase — pump or shield alike — into three legs: a share that compounds into the pool's own liquidity, a share that burns, and the exact rest that follows the pot's recipient. Two sliders, and the buyback stops being just a payout: it becomes a flywheel.
The waterfall
Shares are WAD fractions of the output (1e18 = 100%), floored individually; the rest is computed by subtraction, so the three legs always sum to the output to the wei. Both shares at zero is the classic behaviour bit-for-bit: the whole purchase follows the pot's recipient.
Who sets it, and the rules at set-time
The two shares live in the same ProgramConfig as the LP fee split, and follow the same law: only the program's operator can edit them, via setProgramConfig or up-front in addLiquidityAdvanced / launchPool. Plain addLiquidity names its owner as BOTH owner and operator with every share at zero — nothing is armed behind your back, and the owner can opt in later. Zeroing the operator (setProgramOperator(id, address(0))) freezes the split forever, sliders included.
| rule | why |
|---|---|
potCompound + potBurn ≤ 100% | the two carve-outs can never exceed the output |
potBurn = 0 on a native main | the network token has no supply to destroy — same law as the pot's own recipient rule |
| a program must exist | no program means both shares read zero: the whole output follows the pot's recipient |
The compound leg — buyback becomes liquidity
The compounded share is credited to the program's carryMain — the same carry the autocompounder already uses for mint remainders. It is not minted mid-swap (minting inside the carrying swap's unlock would re-enter the PoolManager); it waits, custody-covered and attributed in obligationOf, and the next harvest folds it into the mint budget alongside that harvest's own compound slice. The result is a loop the machine could not close before:
Remove ALL program liquidity and the pot keeps pumping — the compound legs keep accumulating as carry. Re-add any liquidity later and the next harvest mints the whole waiting budget. Nothing leaks, nothing strands; this exact cycle is a test (SP9).
The burn leg and the rest
The burn leg walks the same verified cascade as a burn-intent pot: the token's own burn(amount) accepted only on a measured balance drop, then 0xdEaD, then the held-forever ledger. And when the pot's recipient is itself address(0), the machine doesn't walk the cascade twice — the burn share and the rest merge into one cascade walk. On a native main the burn slider is locked at zero, but the compound slider still works: an ETH-main program can compound its buybacks even though it can't burn them.
Recipes
| intent | potCompound | potBurn | pot recipient |
|---|---|---|---|
| classic burn-everything | 0% | 0% | address(0) |
| classic treasury payout | 0% | 0% | your treasury |
| the flywheel — buyback → liquidity | 50–100% | 0% | anything |
| burn AND deepen | 50% | 50% | anything (nothing reaches it) |
| mostly burn, some liquidity | 25% | 0% | address(0) |
Never-stop, unchanged
The split adds zero new ways to revert a swap. The carry credit is pure accounting (it cannot fail); the burn leg already fails sideways to the held ledger; the delivered rest already fails sideways to the parked ledger; and the whole placement still runs inside the same try/catch isolation as before. The adversarial matrix for the new legs — a refusing recipient, an unburnable main under a burn share, a hostile native recipient, a re-entering recipient — is the NS series of the GlueHookPotSplit suite, and the split is exercised against live PoolManagers on Ethereum and Tempo in the fork suite.
FAQ
What are the two split knobs?+
potCompoundShareWad and potBurnShareWad — WAD fractions (1e18 = 100%) of every pump/shield output. Compound share becomes LP budget, burn share goes through the cascade, the exact remainder goes to the recipient.
What happens with no LP program or a zeroed split?+
Compounding is effectively 0, and the output flows like before the split existed: everything to the recipient, or the whole amount through the burn cascade when the recipient is 0x0.
Who edits the split?+
The program operator, via setProgramConfig — the same role and call that edits the LP fee shares. Surrendering the operator (0x0) freezes the split forever.
Why can't a native MAIN take a burn share?+
Native coins have no burn() and no 0xdEaD transfer that removes supply — a "burn" would be a pretend. The config validation rejects it at write-time instead of lying at runtime.
Does the compound leg mint immediately?+
It credits the program's carry — waiting LP budget covered by the hook's custody — and the next harvest mints it into the position together with the harvested fees. Nothing leaks in between.