Trading fees → charity, enforced by code
Launch a memecoin and pick a cause. Its creator fees go to a vault that is structurally incapable of paying anybody else — not the person who launched it, and not us. That isn't a policy we could revise. It's the absence of a function.
The project's own token, launched separately from the launchpad. Its creator fees fund Robin Help itself — the audit, the launch form, hosting, and the work to add more charities and more chains. They do not go to a charity, and we would rather say that plainly than let it blur into the campaigns below.
Not launched yet. When it is, the chart draws itself from chain data.
Read from chain on each load — payouts leaving campaign vaults, and the transactions that carried them. Nothing here is typed in by us.
A payout leaves a vault, crosses to Ethereum, and is donated under the charity's config. Until it clears the bridge it shows as in transit — that is the rollup's challenge period, not a delay we control.
Fixed in the contract when it was deployed. There is no function to add a sixth, remove one, or change where any of them point. Adding a charity would mean deploying a different launchpad, and you'd be able to tell.
Payouts route through donate.gg, which holds the relationship with each charity and resolves its current payout address. Each config ID is a public value published on that charity's page.
Three routes could divert a campaign's fees. The design closes all three, and the tests check each one.
| Route | Closed by |
|---|---|
| The fee recipient hands the stream to someone else — instant, no delay | only the current recipient can do that, and the recipient is a contract with no such function. A wallet could always sign it; a contract without the code cannot. |
| The protocol's rescue path pays the token's deployer, not its fee recipient | the vault launches the token itself, so it is the deployer too |
| The vault spending its own balance | no owner, no admin, no withdraw, no upgrade path. Two exits, both fixed on the charity, both callable by anyone. |
A campaign donates about 0.7% of its trading volume. The protocol charges 1% per trade and keeps 30% of that; the remainder is the creator share, and all of it goes to the charity.
No campaigns yet. The first one launched will appear here, read live from chain.
A page like this usually says "trustless" and stops. Here is the specific, complete list of what remains outside our control, so you can price it yourself.
The pons protocol owner can move a token's fee recipient, but only by proposing the change publicly and waiting out a 3-day timelock. And donate.gg, whose relay receives the final donation, can upgrade that contract — it's a proxy under one key.
The route that always works is the chain's own bridge, and it carries a 6.36-day challenge period — the delay every optimistic rollup withdrawal has. It depends on nothing but the rollup, anyone can trigger it, and it cannot be blocked.
There is also a fast route through Across that settles in seconds, and the contract caps what any caller can concede to relayers so nobody can quote a hostile rate and keep the difference. But it needs third-party relayers holding capital on this route, and on a chain this young that comes and goes — we have seen it quote seven seconds in the morning and offer nothing by evening.
So treat the fast route as a bonus and the six days as the real answer. A donation is never stuck either way.
We take 0% — there is no fee parameter in our contracts and the donation tip is hardcoded to zero. But the pons protocol takes its own cut of trading fees before the creator share exists, as it does for every token on this chain. So: 100% of the creator fee share reaches the charity, not 100% of every trade.
The contracts compile and pass their tests. Nobody outside has reviewed them. Until that changes, treat this as software that has not been proven, because it hasn't.
Name it, pick a cause, and the fee routing is locked the moment it deploys.