Hood Helper

Trading fees → charity, enforced by code. On Robinhood Chain.

The fees only
go one way.

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.

Launch a coin 0.0005 ETH to launch. 0% to us — no fee parameter exists.
A campaign, right now.

Reading a campaign from chain…

Donated—to charities
Left the vaults—released to charities
Campaigns—live on chain
Our cut0%no fee parameter exists

The fees can't reach anyone but the charity.

A trade pays a creator fee.

The fee lands in a vault.

The vault has one exit.

$SHARKsomeone buys

1% protocol fee on the trade. The creator share accrues on the curve — about 0.7% of everything traded.

Fee accrued
Vaultno owner

The vault launched the coin, so it is both deployer and fee recipient. It has no withdraw, no admin, and no upgrade path.

One exit, fixed at birth
St. Judeon Ethereum

Anyone can trigger the payout. It crosses the bridge and is donated under the charity's own config ID.

Settled

Launch a coin, pick a cause.

Pay the protocol's 0.0005 ETH fee. The charity is written into the coin as it deploys and there is no function to change it afterwards.

Its fees collect in a vault.

Every trade pays a fee, and the creator share lands in a vault whose only exit is the charity you picked — roughly 0.7% of everything traded.

Anyone can trigger the payout.

Not just you, and not only us. The vault has no function capable of paying anybody else, so a payout is never waiting on our permission.

Every campaign

Every coin launched through Hood Helper, read from the launchpad contract on each load. Each one has its own vault, and each vault's charity was fixed the moment it deployed.

reading chain…

No campaigns yet. The first one launched will appear here, read live from chain.

$charity

The project's own token, launched separately from the launchpad. Its creator fees fund Hood Helper 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 above.

—
— mcap — 24h vol

Not launched yet. When it is, the chart draws itself from chain data.

Everything, as it happens

Campaigns launching, payouts leaving their vaults, and donations landing on Ethereum. Read from chain on each load. Nothing here is typed in by us.

reading chain…
Looking for payouts…

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.

Eight charities

Five are fixed in the launchpad running today. Three are prepared and go live with the next one — their payout contracts are not deployed yet, so the launch form will not let you pick them, and they are marked below rather than quietly listed.

A launchpad's charity list is set when it deploys and has no function to add, remove, or repoint one. That is why adding three means a new launchpad, and why you can tell from the outside that it happened.

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.

Why it can't be redirected

Three routes could divert a campaign's fees. The design closes all three, and the tests check each one.

01 Trade fees accrue on the curve 02 Vault one exit, fixed at birth 03 Bridge to Ethereum, ~6 days 04 Charity under its config ID the launcher us anyone else
the only path fees can take routes the contract does not contain
RouteClosed 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.

What stays outside our control, in full: payouts take 6 days, the challenge period on the chain's own bridge. The pons protocol owner can move a token's fee recipient, but only in public and only after a 3-day timelock. donate.gg, whose relay receives the final donation, can upgrade that contract. And our contracts have not been reviewed by anyone outside this project — they compile and pass their tests, which is not the same thing.

Why we are doing this

Memecoins move a startling amount of money and produce nothing. We wanted to know what happened if you left the machine exactly as it is and pointed the one useful output somewhere that matters.

The fees already exist. Someone always gets them.

Every token launched anywhere charges a fee on every trade, and a share of it goes to whoever launched the thing. That is not a flaw we invented a fix for — it is simply how these markets work, and it is usually the single largest transfer of value in a coin's life.

So the question was never whether to take fees. It was who receives them. We pointed that share at five causes, and now eight, and removed our own ability to change our minds.

Charities do not have a money problem. They have a follow-through problem.

Plenty of projects have promised a cut to a good cause. Most of the time nobody checks, and the promise quietly becomes a marketing line that costs nothing to make and nothing to break.

Code does not forget, get busy, or change its mind when the number gets large. A vault that has no function to pay anyone else is not being honest — it has no other option. That is a much smaller thing to trust than a person, and you can read it yourself.

Why these causes.

Children's cancer treatment, wishes for critically ill kids, clean water, children in crisis, hunger, cancer research, water access, and disaster relief. They are large, independently rated, and they publish where their money goes — which matters, because once a donation leaves our contracts we have no say in what happens next, and we would rather hand it to organisations that answer for it.

Every one of them is fixed in the contract. We cannot move a campaign's charity after it launches, and neither can the person who launched it.

It is still a memecoin.

Buying one is not a donation and is not tax deductible. You should expect to lose what you put in. The donation is the fee routing, it happens whether the price goes up or down, and it is the part we can actually guarantee.

Launch a coin

Name it, pick a cause, and the fee routing is locked the moment it deploys.

Drop an image here or click to choose — PNG, JPG, GIF or WebP, up to 2 MB

Required. Pinned to IPFS and written into the coin, so it shows anywhere the token is listed.

Launching costs the protocol's 0.0005 ETH fee plus gas, on Robinhood Chain.

The charity you pick is written into the coin and cannot be changed afterwards — not by you, and not by us. Its fees will be collected by a vault with no function capable of paying anyone else.

A dev buy cannot be part of the launch. The protocol rejects any payment that is not exactly the fee, and a buy made during the launch would be credited to the vault, which has no way to send tokens on. A buy step appears here the moment the launch confirms, so you can buy from your own wallet.