FAQ

What if the keeper is down?

Nothing is lost and nothing is stuck. Fees keep accruing in Pons Fee Escrow, credited to the charity address. claimAndBridge and flush are public functions on immutable contracts; anyone with a little ETH for gas can call them and the money follows the same path. The keeper's key has no on-chain role, so replacing the keeper needs no contract change. See Keeper and relay.

What if Across is down or has no liquidity?

claimAndBridge calls Across depositV3 only; there is no fallback route. If Across declines the route, the keeper skips the call and retries on its next tick. Nothing reverts on-chain and nothing moves: ETH waits in Pons Fee Escrow and on the charity address. If a deposit is made but not filled within the 2-hour fill deadline, Across refunds it to the charity address in WETH, and the next claimAndBridge unwraps and includes it.

What if a config ID is wrong?

donate.gg's contract does not validate config IDs; ETH donated under a wrong ID is stranded. That is why the registry only deploys charity addresses for config IDs on the approved list. A charity address can only bridge to the receiver for its own config ID, and a receiver can only donate under its own config ID, so once the ID is right at deployment it cannot drift. Verify before pointing a token at an address: charityAddressFor(configId) and approved(configId) on the Robinhood registry. See Integration guide.

What happens below the minimum bridge amount?

claimAndBridge requires at least 0.01 ETH, counting the balance in Pons Fee Escrow plus any ETH and WETH the charity address already holds. Below that it reverts BelowMinimum and the keeper does not call it. The fees stay credited in Pons Fee Escrow, claimable, until the total reaches 0.01 ETH. Every token pointed at the same charity address pools toward the same minimum. The minimum is immutable.

What if the Across fee is above the fee cap?

The charity address rejects any outputAmount that implies a fee above the registry's live fee cap (0.001 ETH at launch). The keeper checks the quote first and skips the call. Money waits. If fees are structurally higher, the Safe can raise the live fee cap, but never above the hard ceiling of 0.002 ETH, which is immutable. See Keeper and relay.

Why does the charity get 90%?

100% of the creator fees reach donate.gg through flush. donate.gg's epoch processing converts to USDC and pays the charity 90%, keeping 10% as its fee. The split is donate.gg's, applied on Base, and is visible in the DonationEpochProcessed event. The example settlement shows 27.258856 USDC settled, 24.532970 to the charity and 2.725886 to donate.gg.

Why might the totals on the landing page lag?

The headline total on the landing and the charities page comes from the indexer's snapshot, which the site re-reads at most every 60 seconds; the indexer itself follows Base on a 15-second tick, so a flush can take up to about a minute and a half to show. When the snapshot is unavailable, the landing falls back to reading the relay's own Flushed events on Base directly. Either way only Flushed events emitted by the receiver recorded for that config ID count. Fees below the minimum bridge amount are still in Pons Fee Escrow and are not part of total received; on the charities page they show under fees generated instead. If the indexer is unreachable the site keeps the last snapshot it fetched; if the direct reads fail too, the page renders without totals rather than erroring. Totals are what was handed to donate.gg in ETH; the USDC actually paid to a charity depends on donate.gg's conversion and is not estimated. See Live data.

Why do "fees generated" and "total received" differ?

They measure different points on the money path from different sources. Fees generated is per token: what Pons has credited to the charity address in Pons Fee Escrow, gross, read from Pons's Credited events on Robinhood Chain. Total received is per charity: what flush handed to donate.gg, net of the Across fee, read from the relay receivers' Flushed events on Base. Between the two sit the sweep lag, the 0.01 ETH minimum bridge amount, the keeper's tick, and the bridge. Neither is the USDC the charity ends up with, because the 90/10 split is applied by donate.gg on the payout side. Live data lists every reason.

What if the Safe is compromised?

The Safe can add or remove config IDs from the approved list, set the live fee cap up to the hard ceiling, and hand the role to another address. It cannot move, redirect, pause, or withdraw ETH, and it cannot change an existing charity address. The worst case is a bad config ID approved for future deployments, or the cap set to the ceiling. Money already flowing is untouched. See Why permissionless.

Can a creator change their mind?

No. A charity address has no code path that calls Pons transferCreatorFeeRecipient, and there is no migration mechanism or deployer exit. The only known exception is a Pons-level power: the Pons protocol owner can propose a recipient change on any token with a 3-day timelock. The relay contracts cannot prevent that.

What about fees in tokens other than ETH?

They stay in Pons Fee Escrow, credited to the charity address. The relay only claims and bridges ETH. ETH-paired launches credit ETH; custom-pair launches credit the quote ERC-20, which the relay does not touch.