The keeper

What a keeper can do

Exactly two things, both of which anyone can do:

• Call the functions that move fees to the charity. They are public and take no permission. Calling one sends the charity's share to the charity and the creator's share to the creator, in the ratio fixed when the coin launched.
• Take back the gas it just spent, out of the fees it is moving, capped at 2% and priced from the block's own base fee. That is the payment for doing the work, and it is why a stranger would bother.

There is no third thing. No function exists that sends money anywhere else, and none can be added — the contracts have no owner and no upgrade path.

What a keeper cannot do

Change where the money goes. Not the charity, not the split, not by any amount.

This is not a promise, it is a property of the deployed code. Every function that moves money is listed below with the access control it carries, which is none — meaning anyone may call it, and calling it does the same thing no matter who you are.

Our test suite scans the deployed bytecode of each contract for owner-like functions — owner, transferOwnership, upgradeTo, withdraw, sweep, rescue — and fails if any of them answers. You can run the same check yourself against the addresses on the verify page.

So what if ours is compromised

Whoever took it could spend the small amount of gas money in that wallet, and could call the donate functions. Calling them donates. They would collect the 2% gas reimbursement each time, which is the attack: a few dollars, and every one of those calls also pays a charity.

They could not redirect a single wei. That is the whole exposure, and it is why the keeper's key is not treated as a secret worth much.

So what if ours stops

Donations pause. They are not lost — fees accumulate in each coin's vault exactly where they were, and the next call moves them, whenever that is and whoever makes it.

Half the work does not depend on us at all. When the charity's share is bridged to Base, the bridge relayer completes the donation as part of filling the transfer, paid for by a fee already deducted. That half happens whether or not anyone is watching.

Run one yourself

You do not need our permission, our code, or our keeper. Any coin's vault can be serviced by anyone, and the reimbursement goes to whoever sends the transaction.

With foundry, against any vault listed on the transparency page:

cast send <vault> "claimAndDonate()" \
  --rpc-url https://rpc.mainnet.chain.robinhood.com \
  --private-key <yours>

If the coin is still on its bonding curve the fees sit on the curve rather than in the vault, and the call that sweeps them first is sweepCurveAndDonate(curve, 0). Both are no-ops when there is nothing to move, so neither can waste more than gas.

If this site disappears

There is nothing to reconnect. A keeper is not registered, granted or approved anywhere. No contract stores who the keeper is, because no contract needs to — the functions are public. Becoming the keeper means sending a transaction, and stopping means not sending one.

The part that would actually be missing is the list of coins, since that is what this site provides. It is also on-chain, so it can be rebuilt without us. Every launch emits an event from the factory:

cast logs \
  "LaunchCreated(address,address,address,uint8,uint16,uint16)" \
  --address <factory> \
  --from-block 0 \
  --rpc-url https://rpc.mainnet.chain.robinhood.com

The second indexed address in each log is that coin's vault. Sweep it, call claimAndDonate(), collect the reimbursement. The factory addresses — including the older ones, whose coins are still live and still owed their donations — are on the verify page and in /config.json.

None of that needs our permission, our software, or us to be alive. It is the difference between a service and a set of contracts: a service can be withdrawn, and these cannot.

Ours, in the open

Published so it can be watched, not because it matters who runs it.