Fee Distribution

Every post-graduation fee operation is permissionless. Anyone can trigger distribution; the split is enforced on-chain with no admin override and no discretion.

The split

distributeFees(token) divides accumulated pendingFees[token]:

The deployer and protocol cuts are credited immediately and pendingFees is zeroed before the reinvest swap runs, so nothing is held back to be taxed twice.

Reinvestment

1. Half the reinvest budget is swapped into tokens (fee-free internal swap)
2. The other half plus the acquired tokens are added to the existing position
3. Leftover token dust above 1,000,000 wei is burned to the dead address

If the pool holds too few tokens for a meaningful liquidity add, the branch flips: the remaining native is swapped and burned instead, emitting BuyAndBurn rather than Reinvested.

Capped processing and roll-forward

Reinvestment is bounded by the MEV cap, so a single call may not be able to process the whole pending balance. Rather than reverting, _reinvestAsLiquidity processes the safe portion and returns the remainder, which the caller re-accounts:

• From distributeFees the remainder goes to protocolBalance — it has already been split, so routing it back to pendingFees would tax it a second time.
• From processProtocolFees it goes back to protocolBalance and is picked up on the next call.

$LP24 is handled separately

Fees from the $LP24 pool go 100% to protocolBalance — there is no deployer to pay. distributeFees() rejects $LP24 outright and directs callers to processProtocolFees(), which chooses between two paths based on how many tokens the pool holds:

The reserve is read from pool state, not from balanceOf on the pool manager — the latter conflates this pool with any other pool holding the same token, which would send the branch the wrong way.

Gnosis: two buckets

V3 pays fees in both currencies, and the manager treats them differently under a hard rule: token-side fees are never sold to the market. The deployer and protocol cuts come exclusively from the native side.

Fees must be pulled out of the position first with collectFees(token), which anyone can call. Distribution then follows one of two paths depending on pool depth:

Buy-and-burn genuinely buys tokens, reducing supply — the inverse of selling. That is why it does not violate the no-selling rule.

Buy-and-burn is not a separate call

There is no buyAndBurn() function and no way for a deployer to elect it. Burning is a branch the contract selects from live pool state inside the ordinary distribution calls:

• On the V4 hooks, _reinvestAsLiquidity falls through to buy-and-burn when the pool holds too few tokens for a meaningful liquidity add, and processProtocolFees chooses it when the $LP24 pool is token-rich.
• On Gnosis it is the DEEP path: pool at or above 48,000,000 × 10⁹ (48M tokens) means burn rather than LP.

Which branch ran is visible in the logs — BuyAndBurn(token, nativeSpent) versus Reinvested(token, nativeAmount, tokensAdded, liquidityAdded) — but neither is selectable by the caller.

Deployer withdrawal

After distribution the deployer calls withdrawDeployerFees(token) to withdraw their accrued balance. Only the address currently registered as deployer can call it — which, after a successful CTO, is the new one.

Gnosis thresholds

These select a mechanism; they do not gate whether fees get processed at all. That distinction matters — gating on them was what previously bricked distribution.