How paid.family works

paid.family is a fee bridge. A token on pons points its creator fees at us, we claim them on chain, and 80% is paid to an X account through Money.

1. Overview

paid.family turns a token's creator fees into dollars in someone's pocket. A deployer launches a token on pons, the launchpad on Robinhood Chain, and points its creator fees at the paid.family treasury.

Everything between the two is mechanical. Fees accrue to the treasury as the token trades, paid.family claims them on chain, 80% is converted to dollars and paid to the recipient through X Money, and 20% buys $PAID and burns it.

The recipient is not asked to do anything first. There is no account to make and no wallet to connect, so a payout can arrive from a token they have never heard of.

1. A token directs its fees. The deployer sets the paid.family treasury as the token's creator fee recipient, permanently.
2. The description names a handle. One line in the token description says who the fees belong to.
3. The token registers itself. The indexer sees the fee direction on chain and registers the token. There is no approval step.
4. Fees are claimed. paid.family claims accrued creator fees on a schedule and records each claim against its transaction hash.
5. The recipient is paid in dollars. The recipient share is sent through X Money from a pre-funded float, and a public reply confirms it.

2. The venue: pons on Robinhood Chain

pons is the native launchpad on Robinhood Chain, an Arbitrum Orbit L2 (chain id 4663) where ETH is gas. A pons v2 launch mints its full supply to a bonding curve that trades in ETH, then graduates permanently into a locked Uniswap V4 pool. Creator fees are charged in ETH from the very first trade, both on the curve and after graduation, and are credited to the token's creator fee recipient in the pons fee escrow.

3. Directing fees

The rule is simple: paid.family is the token's creator fee recipient, and it stays that way. It has to be the whole fee, because pons has exactly one creator fee recipient per token; there is no partial share to get wrong. And it has to be permanent, because a fee direction that can still be changed is a promise that can still be withdrawn.

On pons the assignment is its own lock. The factory's transferCreatorFeeRecipient can only be called by the current recipient, so once the treasury holds it the deployer cannot take it back. There is no separate revoke step.

• At creation: the launch form on this site fills creatorFeeRecipient with the treasury for you.
• After creation: the current recipient of an existing pons token calls transferCreatorFeeRecipient(token, treasury). The Register tab on the launch page does this from your wallet.

One caveat that is pons's, not ours: the pons protocol owner can propose a recipient change for a token whose creator has vanished, with a three-day timelock and a three-day execution window. It is public on chain as pendingCreatorFeeRecipient, and the indexer unregisters a token the moment its recipient is no longer the treasury.

4. Naming the recipient

The X account that gets paid is read from the token's description. Put this line in it, with the handle you want paid:

Fees to @elonmusk via paid.family

Use it exactly, anywhere in the description. A description can easily mention several accounts, and without a fixed line there is no way to tell which one is meant to be paid.

If the line is missing we fall back to the first handle in the description, and then to the X account the token is linked to in its socials. Both work, and neither is as reliable as the line.

pons stores the description on chain and caps it at 2048 bytes. The recipient does not need to agree, know in advance, or hold a wallet. A token can be launched for someone, and the first they hear of it is the money arriving and a public reply saying where it came from.

5. The 80/20 split

Note that pons itself takes a protocol share of trading fees before anything reaches the creator; paid.family's split applies to the creator share that pons credits to the treasury. The one exception: $PAID itself does not split. All of its own fees are held as protocol treasury.

6. How claims work

Creator fees do not arrive continuously. pons sweeps them from each curve or pool into the fee escrow, where they sit as one balance for the treasury. paid.family claims that balance on a schedule rather than on every trade, and attributes each claim to tokens in proportion to the creator fees pons swept for them since the previous claim.

Each claim is written to the ledger keyed on its own transaction hash, so a claim cannot be recorded twice and every obligation can be traced back to the on-chain event that created it. The recipient share and the protocol cut are both computed at that moment, from that claim, and neither is recalculated afterwards.

A claim can fail. Chains halt, RPC providers go down, and transactions revert. A failed claim creates no obligation and is retried; the fees stay in escrow in the meantime and are not lost.

Payout milestones

Payouts land at milestones. A creator's share builds until it crosses $5, then $10, $20, $50, $100, $250, $500, $1,000, and every $1,000 after. Each crossing sends the full balance.

Balances below a milestone keep building; nothing expires for a resolved recipient. If the account cannot receive yet, the balance is held. See Held balances.

7. Getting your fees

If a token has named your handle, the money is already yours. There is nothing to claim and no form to fill in. It is sent once the balance crosses a payout milestone and your X Money account can receive.

You are not required to do anything, acknowledge anything, or agree to anything. Receiving a payment does not make you a customer of paid.family or a promoter of the token that named you.

8. X Money setup

Payments settle into X Money, so the only requirement on your side is an X Money account that is open to receiving. That is configured on X, not here, and paid.family cannot open one for you or change its settings.

X Money is available to X Premium members with a verified phone number, which covers a large share of the handles a token is likely to name. Where a handle can already receive, a payout simply lands. We check whether a handle can be paid before opening a payable balance. If it cannot yet, the money is held rather than lost.

9. Held balances

Any X account can be named, whether or not it has X Money. Where a handle cannot yet receive, the money is not lost and it is not sent anywhere else. It is held for them.

A held balance stays held for 7 days. Open an X Money account in that window and it becomes payable, going out on the next run. If the 7 days pass and the account still cannot receive, the balance is recycled into the $PAID buyback. That is the only thing that ever happens to an unclaimed balance, and it is why the period is published rather than decided case by case.

10. The public confirmation

Every payout is announced. @paidfamily replies to the recipient with the amount and the token it came from, so the recipient and their audience can both see it. Most were not asked before their handle was named, so the payment is usually the first they hear of it, and the reply is what they and their audience can check it against.

11. The treasury and the off-ramp

Fees are claimed on Robinhood Chain and arrive at the treasury as ETH. The recipient share crosses the Robinhood Chain bridge, is sold for dollars at Kraken in batches, and the dollars land in the @paidfamily X Money balance. That balance is the float payouts are sent from, and it is kept ahead of what is owed, so a payout never waits on the off-ramp.

12. $PAID and the buyback

The protocol cut is spent buying $PAID on pons and burning it through the token's ERC20Burnable burn function. The protocol buys from the same market as everyone else, at whatever the price is when it buys. Both halves are on chain and can be checked by anyone. $PAID gates nothing: holding it does not change the split, who can launch, or who gets paid.

13. Stopping payments

There is no opt-out on this site, deliberately. Who may pay you is a setting on your X Money account. A control on this site would only stop us; the X Money setting stops anyone. If you would also prefer your handle not to appear on this site, ask @paidfamily on X.

14. If a token is not registering

1. Wrong treasury address. The creator fee recipient is an address that is not the paid.family treasury. Check it against the launch page.
2. Recipient moved. A pending pons owner override executed and the recipient is no longer the treasury.
3. No handle in the description. Nothing in the description names a recipient, and the token is not linked to an X account either.
4. Not a native-ETH launch. Tokens launched against an ERC-20 pair asset are indexed but not yet paid; the off-ramp handles ETH.
5. Too recent. The indexer reads the chain on a schedule. A token created moments ago has not been seen yet.

15. Glossary

16. Terms, privacy and disclosures

paid.family is software that routes on-chain creator fees. It is not affiliated with X Corp, Robinhood Markets, or pons. $PAID is not an investment, carries no rights, and its only function is to be the asset the protocol cut is spent on. Payouts depend on third-party services (pons, Kraken, X Money) that paid.family does not control.

This site stores public on-chain data and public X handles. It does not collect personal information beyond what an X handle or a wallet address already makes public.