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 Helping Hand 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. One exit, fixed on the charity, 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.
There is exactly one exit, and it is the chain's own bridge. 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.
An earlier version also bridged through Across, settling in seconds. We removed it before launch. Across pays contract recipients in WETH rather than ETH, and the address receiving a donation is a contract that only understands ETH — so the fast route would have delivered a charity's money in a form its own forwarder could never spend, permanently, and anyone could have triggered it. Six honest days beat a shortcut that can destroy the donation.
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.