How Pons Creator Fees Work Across Multiple Quote Assets

Fees follow the quote asset, not the creator

On Pons, creator fees accrue in whatever asset a launch was paired against. A creator who has launched three tokens — one paired against ETH, one against NVDA, and one against USDG — isn't sitting on a single combined balance. They hold three separate, independently claimable balances, one per quote asset.

This follows directly from how the fee escrow contract tracks balances: balanceOf(recipient) reports what's owed in native ETH, while balanceOfToken(recipient, token) reports what's owed in each specific ERC-20 quote asset. There's no single call that nets everything into one number.

Reading what you're owed

To see the full picture, every known quote-asset candidate has to be checked individually against the escrow contract — the same candidate list used to decide which assets are pairable in the first place. ETH is checked once via balanceOf; every other asset (USDG, cbBTC, and each tokenized stock) is checked via balanceOfToken, and only nonzero balances are worth surfacing.

This mirrors how Pons's own documentation describes it: a creator with launches against several quote assets holds several separate balances, full stop — there's no aggregation step anywhere in the protocol.

Claiming is also per-asset

Claiming mirrors the balance structure. ETH fees are claimed with a plain claim() call. Every ERC-20 quote asset is claimed separately with claimToken(address), passing the specific token's address. If you've earned fees in ETH, NVDA, and USDG, that's three separate claim transactions, not one.

It's easy to claim ETH, see a zero balance there, and assume there's nothing left — while a real balance in NVDA or USDG sits unclaimed simply because it was never checked.

The decimals lesson, applied to fee balances

The same decimals issue that affects trading shows up here too, and it's worth being deliberate about. USDG was, for a period, hardcoded as an 18-decimal asset in the fee-balance code when it is actually 6 decimals — a 10^12 scale error that took a real 12.5 USDG balance and rendered it as effectively zero.

The current implementation reads decimals() directly from each token contract at claim time and only falls back to a hardcoded registry value if that call fails, specifically so a mismaintained decimals table can't silently zero out a real balance again.

FAQ

• If I claim ETH fees, does that also claim my token fees? No — claim() only settles the native ETH balance; every ERC-20 quote asset needs its own claimToken(address) call.
• Why did my dashboard show a small NVDA balance I hadn't noticed? Each quote asset is checked separately from the same candidate list used for pairing, so a low-value balance in a less-traded asset is easy to miss if you only check the asset you expect.
• Is claiming free? Claiming still costs gas per transaction, so claiming three separate small balances costs three transactions' worth of gas — worth weighing against the balance size for very small amounts.

Related reading