FEES HACK

Most creator fees end the same way: a wallet the creator controls, a promise in a Telegram message, and no way to check.

FeeJob replaces the promise with an account. A creator declares once what the fee stream is for - burn, buyback, public treasury, holder rewards, bounty escrow, liquidity, research, agent ops - with a weight for each. That job list is written into a PDA that has no authority field: no set_weights, no update_beneficiary, no admin key, no upgrade path to add one. After creation, the split is the split.

How it works. Fee income lands in the router's vault PDA (a 0-data account that holds only lamports). distribute is permissionless - anyone can crank it, so the creator cannot stall a payout they dislike. The payable balance above the rent floor is split by the immutable weights with floor division; rounding dust is never invented and never lost, it rolls into the next payout. Each job's share is transferred to its declared beneficiary in the same transaction, and a receipt account is written at a predictable PDA holding slot, timestamp, total and per-job amounts.

Why it is verifiable, not just claimed. Receipts are accounts, not events: distribution n lives at ["receipt", router, n], so a verifier walks 0..distribution_count with no indexer, no API and no trust in us. The dashboard reconciles rather than reports - it sums the receipts and compares them with the router's own counters, and prints "mismatch" instead of a nice number if they ever disagree. A job of kind burn is enforced by the program, not by convention.

What is real: the Anchor program, the PDA layout, permissionless distribute, dust handling, receipt accounts, the reconciling dashboard and the tests - deployed and demonstrated on Solana devnet.

What is mocked: nothing on the money path. The demo funds the vault with devnet SOL instead of live pump.fun creator fees, because live fees are mainnet; the router code is identical either way.