Skip to main content

Capital flow

Creator fees from pump.fun are claimed on a schedule, converted to dollars through Kraken, and sent to the creator's X Money account. 20% of every claim buys and burns $PAID. Pons fees still accrue in the fee escrow, but claiming and bridging them is paused while pons is not operational.

80%20%pump.fun & ponsFees claimedOfframp throughKraken APISent to X MoneybalanceSent to X user$PAID bought backand burnt
pump.funpons.family

A token on pump.fun or pons points its fees at us

At launch, the token directs its creator fees to our treasury and locks in that destination. pump.fun pays in SOL; pons pays in ETH. We read the X handle from the token's description and claim pump.fun's fees on a schedule. $PAID trades on Solana, so a pons claim's ETH would bridge there first, over deBridge, before anything downstream can spend it - but pons is not operational, so its fees sit accruing in the fee escrow rather than being claimed or bridged right now. Every pump.fun claim splits: 80% to the creator and 20% to buy and burn $PAID.

Kraken converts it to dollars

Every claim's recipient share reaches this step as SOL - pump.fun's directly, pons' would after it bridges over, once pons claiming resumes - and converts to US Dollars at the same Kraken account, so nothing after this step depends on which chain a token was on. Conversions run in batches rather than one per payout.

$PAID is bought back and burnt

The 20% buys $PAID on the open market, in SOL, and burns it through the SPL Token program's own burn instruction, which removes it from supply rather than parking it at an address. Supply is fixed, and the buys and burns are on chain if you want to check them.

USD arrives in our X Money balance

The dollars Kraken settles land in the X Money balance on the @UsePaid account, the treasury every payout is made from. It holds what is owed to X users between a claim and its payout, and we keep it ahead of what is owed.

The X user receives the distribution through X Money

The payout leaves our balance and arrives in the X user's X Money account, the one matched to their handle. X asks for verification and the enrolled security key answers it, so nobody taps a prompt. @UsePaid then replies with X's own receipt attached.

X Money operations

X Money allows an account to confirm payments with a security key. @UsePaid has one enrolled and held by our payout worker. When X requests verification, the worker uses the key to sign the verification challenge, allowing the payment to proceed through the X Money interface. This is what makes the sends automatic.

  • VerificationAn X security key, held by our payout worker
  • Send limitNo hard cap on peer-to-peer sends
  • Fee$0 per send
  • Minimum$1 per send

X's settings as of September 2026.