Integration guide

For Pons creators. Where to set the fee recipient, how to transfer it later, and what to check first.

Irreversible

Once a token points at a charity address, nobody can move its fees anywhere else. Not the creator, not Petal. There is no undo. donate.gg keeps 10% of everything and pays the charity 90% in USDC.

Before you start

Use a live charity address only. Pick one from the Contracts page or the landing page grid. Those are charity addresses the registry has deployed for config IDs on the approved list. An address for a config ID that is not yet approved is not usable: the registry would refuse to deploy it, and fees sent there would sit unclaimable until it is approved.
ETH-paired launches only. Pons credits fees in the pair token. An ETH launch credits ETH, which the relay moves. A custom-pair launch credits an ERC-20, which stays in Pons Fee Escrow; the relay does not touch non-ETH balances.
Verify the address before you paste it. See Verify a charity address below.

Setting the fee recipient at launch

Pons's launchToken(TokenParams, launchConfigId, pairToken) takes the fee recipient in TokenParams.creatorFeeRecipient. Set it to the charity address. Leaving it zero defaults to the caller, which is the creator, not the charity.

Fees credited to the charity address before and after graduation both land in Pons Fee Escrow for the same recipient, so the relay keeps working when the curve graduates to a pool.

Transferring an existing token later

Pons's transferCreatorFeeRecipient(token, newRecipient) is callable only by the current fee recipient. If you are the current recipient, call it with the charity address as newRecipient. It reverts with NotCreatorFeeRecipient for anyone else, including the token's deployer.

After the transfer the charity address is the recipient, and the charity address has no code path that calls transferCreatorFeeRecipient. That is the point at which the choice becomes permanent.

You can confirm the state with getLaunchedToken(token), which returns a record including deployer and creatorFeeRecipient.

What happens to the fees

The fees follow the money path: Pons Fee Escrow credits the charity address; anyone (in practice the keeper, on a timer) calls claimAndBridge, which claims and deposits into Across aimed at the receiver on Base; anyone calls flush on the receiver, which hands everything to donate.gg under the charity's config ID; donate.gg converts to USDC and pays the charity 90%, keeping 10%.

The minimum bridge amount

claimAndBridge requires at least 0.01 ETH, counting the escrow balance plus any ETH and WETH the charity address already holds. Below that, nothing moves; the fees stay credited in Pons Fee Escrow, safe and claimable, until the total reaches the minimum. For a token with little volume this means the charity is paid in batches rather than per trade, and a token whose lifetime fees never reach 0.01 ETH never triggers a bridge on its own. Because one charity address serves every token pointed at the same charity, fees from all of them pool toward the same minimum.

The fee cap

Each bridge pays an Across fee. The charity address rejects any call whose implied fee is above the registry's live fee cap (0.001 ETH at launch, never above the immutable hard ceiling of 0.002 ETH), so the most a single bridge can lose to fees is bounded on-chain. If Across fees sit above the cap, money waits rather than overpaying. See Fee cap and hard ceiling.

The 90/10 split

100% of the creator fees are handed to donate.gg. donate.gg's epoch processing pays the charity 90% of the settled USDC and keeps 10%. The split is donate.gg's, applied on Base, and is visible in the DonationEpochProcessed event and in the example settlement.

Verify a charity address

A charity address is an EIP-1167 minimal proxy deployed by the registry with CREATE2 and salt equal to the config ID. Its address is a pure function of the registry address, the implementation address, and the config ID, so you can check it without trusting this site.

On the Robinhood registry (address on the Contracts page):

charityAddressFor(configId) must return the address you are about to paste.
approved(configId) must be true.
isDeployed(configId) should be true; if not, anyone can call deploy(configId) and pay the gas, and the address will not change.
Optionally, baseReceiverFor(configId) on Robinhood Chain must equal receiverFor(configId) on the Base registry. That is the receiver the charity address will bridge to.

The config ID for each charity is on the Contracts page in hex; that is the form the EVM contracts take. On Blockscout the charity address shows as a proxy whose implementation is the charity address implementation listed on the same page, and its source is readable through the Sourcify match.

Trust boundary

The Pons protocol owner can propose a fee recipient change on any token through the factory's setCreatorFeeRecipient, with a 3-day timelock and permissionless execution. The relay contracts cannot prevent that. It is a Pons-level power, disclosed here as a risk.

On this page