The whole system is one contract that owns and operates its own token. Because it launched that token itself, it is permanently its own fee recipient, and it holds no button that could ever change that. Most of what follows is downstream of that single fact.
01 · A trade pays a fee
$FRANKLIN trades in an ordinary liquidity pool that charges a 1% fee on each swap. Of that fee, the Pons launchpad keeps 30% and the remaining 70% belongs to the token's creator. The split is fixed the moment the token launches and can never be changed afterward, it is snapshotted into the pool's records, not stored somewhere an admin can edit.
02 · The creator is a contract, not a person
Here is the part that makes the rest trustworthy. The Franklin vault does not point at a wallet for its fees, it launched the token from inside itself, so it is the creator. On this chain the launchpad lets the recipient be changed later by a redirect function; the vault simply does not contain a single line of code that calls it. We have tests that read the compiled contract and confirm the redirect selector is absent from its bytecode.
Practically: nobody, not us, not a future admin, not a leaked key, can send the fee stream anywhere other than the cats. It isn't a promise. It's the absence of a function.
The money that feeds the cats arrives at a contract that has no owner and no way to redirect it. Everything else is just how that money gets spent.
03 · Anyone rings the bell
Meals are not automatic, a blockchain can't wake itself up. Instead there is a public function anyone can call to serve the next meal, and the caller earns a small tip out of the pot to cover their gas and a little more. In practice bots do this for the tip, so it just happens; but the important part is that no privileged keeper is required. If we vanished, the bell would still ring.
Meals start frequent and slow down on a fixed schedule, because early volume is high and late volume fades. The cadence is:
A meal also won't be served unless the pot is worth more than the gas to distribute it, a small, gas-indexed floor, so the machine never spends a dollar of gas to hand out fifty cents.
04 · The pot is split, then spent
When a meal is served, the collected fee is divided:
- 30% to the treasury, held in WETH and withdrawn by the operator. It is deliberately kept in WETH and never in $PONS, so running the project never means selling $PONS back into the market.
- 70% to the cats, which is spent buying the four-asset basket on the open market and crediting it to every Franklin by weight.
The treasury only earns when meals are served. If distribution is ever paused, the operator's cut stops too , the incentives point the same way as yours.
05 · The cats get fed, by weight
Each Franklin carries a weight set by its rarity (see The Cats). A meal is divided across the collection in proportion to weight, so a rarer cat receives a larger share of the exact same meal. The accounting is done per cat, not per wallet, which is why splitting your cats across a hundred wallets changes nothing, and why the whole thing is quietly resistant to farming.
06 · Collect whenever, it lives on the cat
Meals are not pushed to your wallet; they accrue to the cat and wait there. You claim when you want, and until you do, the balance simply sits on the token. It never expires. And because it lives on the cat rather than in your wallet, selling the cat hands the full, uncollected bowl to the new owner , which is exactly why a well-fed Franklin is worth more than an emptied one.
The money path, end to end
Gas & thresholds. Meals wait for a minimum pot so they're never gas-negative. On a quiet day, that means fewer, larger meals rather than a constant drip.
Thin markets. $PONS trades in a shallow pool, so purchases are size-capped and price-bounded to avoid slippage, the machine buys carefully, not all at once.
It can be paused. The operator can pause the meals for safety. They can never touch what a cat has already collected, and after 14 days anyone can switch the meals back on without us.