$JOBBER launches on pons v2 against NVDA with:

• creatorFeeRecipient = Distributor address, set at creation
• buybackEnabled = false
• creatorTaxBps = 0

Buybacks are off deliberately. A buyback would route part of the fee into a five-year vest that pays the creator recipient in $JOBBER rather than in NVDA, and more importantly it forces every sweep through the pons operator (§5.2). Off means the Distributor can crank most sweeps itself.

Because creatorFeeRecipient is a contract with no owner and no withdrawal path, there is no wallet anywhere that can receive $JOBBER trading fees. The team's revenue is activation burns and the badge AMM, and nothing else. That sentence is worth more than any amount of marketing.

Any pons creator can call transferCreatorFeeRecipient(token, distributor) on their own launch and point its fees here. The Distributor accepts any approved asset and accrues it to badge holders alongside $JOBBER's own stream.

Why a creator would: a launch with no community gets a distribution channel, a holder base with a reason to care, and a listing on a terminal people already watch. We can also offer enrollment as a condition of incubation, and can pursue abandoned tokens through the pons CTO process, which runs on a three-day public timelock.

This ships in phase 1, not phase 2. A single-token version of this protocol lives or dies on one token's volume. A multi-launch version is a fee terminal. The moat is the second one and there is no reason to wait.

An enrolled asset can also leave, in two steps. beginRemoval(asset) freezes the asset's crank index immediately — no further fees are pulled for it — but every other path stays live: claim/claimMany keep paying out against the frozen index, and notifyWeightChange keeps settling debt for it on every Payroll touch. After a 30-day window, finalizeRemoval(asset) closes the asset for good — claims against it revert from that point on, and it can never be re-enrolled.

The window is the point: it exists so rightful claimants have time to withdraw at the correct, unstale weight before the asset closes, rather than losing it the moment removal starts.

Fees do not reach the pons escrow until someone sweeps them. Post-graduation that is sweepPoolFees(poolId, ...) on the meme hook.

A sweep that requires an internal swap — converting launch-token-denominated fees back into the quote asset — is restricted to the pons sweep operator and reverts for anyone else with InternalSwapRequiresOperator. When no conversion is needed, the creator recipient can sweep the already-quoted portion itself.

In practice: the Distributor can always crank the NVDA-denominated share. The launch-token-denominated share waits for the pons operator.

Payout cadence is designed around this. The weekly crank distributes what is claimable, states what is pending, and never pretends the pending share is lost. The interface shows three numbers: claimed, swept-but-unclaimed, and unswept — because an interface showing only the escrow balance understates what holders are owed.

crank() is permissionless.

1. Reads balanceOfToken(distributor, asset) on the pons escrow for each enrolled asset
2. Calls claimToken(asset) for anything with a balance
3. Advances a per-asset accumulator index by the amount claimed, divided by total active weight
4. Pays the caller a small bounty from the ops slice

Distribution is pull-based, multi-asset. Each badge accrues against the index at its weight; nothing is pushed. A badge whose account cannot receive a transfer cannot jam distribution for anyone else, which is the same reasoning pons itself uses for its escrow.

No admin key on the Distributor. Not pausable, no guardian, no upgrade path.