PIMPFUN documentation

PIMPFUN is a front end and API for Pump.fun's on-chain programs. It does not deploy its own bonding curve or swap. Coins launch on Pump's bonding curve; when the curve sells out the coin migrates to a PumpSwap pool and keeps trading there.

Every transaction is built on the server with the official @pump-fun/pump-sdk, simulated against current chain state, shown to you for review, and only then sent to your wallet. Your wallet signs; PIMPFUN never sees a private key or seed phrase. Signed transactions are relayed only if they pay from your wallet and call allowlisted programs.

1. Ticker. Every ticker ends in PIMP. Pump allows 13-character symbols, so up to 9 characters (A–Z, 0–9) go before the suffix. The suffix is a naming rule, not a uniqueness guarantee: anyone can create another token with the same ticker. Identify tokens by mint address.
2. Metadata. The image and a JSON document are pinned to IPFS (when the server has Pinata configured), or you provide an existing URI. Name, symbol and URI are written on chain and cannot be edited.
3. Create. PIMPFUN builds Pump's create_v2: a Token-2022 mint with 6 decimals and a 1 billion supply on a SOL-quoted bonding curve. The mint keypair co-signs once and is then useless: Pump creates the mint with no mint, freeze or metadata authority.
4. Mint address. When this deployment has a vanity pool, the mint address ends in pimp, the way pump.fun's end in pump. The key comes from a pool generated in advance, is handed to your browser once and is deleted from the server at that moment. When the pool is empty, your browser generates a random address instead. Like the ticker, the suffix is branding, not proof: anyone can grind an address ending in pimp.
5. Optional first buy. create_v2 + buy_exact_quote_in_v3 in one transaction, capped at 50 SOL with your chosen slippage.
6. Fee split (optional). A second transaction runs create_fee_sharing_config and update_fee_shares_v2.

Costs are shown from simulation before you sign: network fee, priority fee and rent for the new accounts. They are not refundable.

Every Pump trade pays a creator fee. PIMPFUN lets the creator choose where it goes, using only mechanisms Pump supports on chain:

• Creator only

  Pump's default. Creator fees accrue to the creator vault and the creator claims them.

  • Can be upgraded to a fee split later by the creator, once.
• Fee split

  Pump Fees sharing config. Up to 10 recipients; shares must total exactly 100%. Anyone can trigger a distribution.

  • Configured in a second transaction right after the token is created.
  • Pump revokes the admin when shares are set, so the split is permanent.
  • Each address can appear only once.
• Pump holder rewards

  Pump's native holder-reward coin: 100% of the creator fee goes to holders and is distributed by pump.fun.

  • Chosen at creation and permanent.
  • The creator receives no creator fee and cannot add a fee split.
  • Pump.fun's distribution authority sets the schedule; holders have nothing to claim.
  • Pump can disable holder-reward creation globally; the launch checks this live.

Fee split rules, enforced by Pump and checked by PIMPFUN before signing: 1–10 recipients, each a positive integer number of basis points, totalling exactly 10,000 (100%), no duplicate addresses. Only the coin's creator can set it, and update_fee_shares_v2 revokes the admin, so a split is set once and is permanent. Graduated coins can be configured too; Pump migrates the pool's creator as well.

Allocation types and their real status:

• Creator wallet — active. Paid directly to the creator's wallet as a Pump fee-sharing shareholder.
• Team wallet — active. Paid directly to a team wallet as a Pump fee-sharing shareholder.
• Community treasury — active. Paid directly to a treasury address (a multisig vault is recommended) as a Pump fee-sharing shareholder.
• Holder reward pool — pending integration. A share of fees reserved for token holders, paid out by snapshot. Pump only supports holder rewards as a whole-coin mode, so a partial pool needs a PIMPFUN vault program.
• Buyback & burn — disabled. A share of fees used to buy the token back and burn it. This deployment has no buyback keeper configured, so it cannot be enabled.

Buyback & burn through the PIMPFUN keeper. A deployment that runs the keeper service can offer buyback & burn as a fee-split recipient. Each coin gets its own keeper wallet, derived when the split is built; the server only accepts that exact address. Every cycle the keeper distributes the coin's accrued fees, buys the coin with its balance minus a small reserve (simulated first, capped per run, with slippage and price-impact limits) and burns everything it bought. Every run, with its signatures, is listed on the coin's rewards page. This is custodial: the operator holds the keeper key, and if the keeper stops, the share accumulates in that wallet. Whether this deployment runs it, and whether it only simulates (dry run), is shown under Integration status.

Holder rewards through the PIMPFUN keeper. The same service can pay a fee-split share to the coin's holders from a second keeper wallet per coin. Once per period, at a moment derived from a secret so nobody can time a buy before it, the keeper snapshots every holder and sends SOL pro rata, if its balance has reached the minimum; otherwise the balance carries over. Program accounts (bonding curve, pools), the creator, the coin's keepers and small holders are not paid, and payouts too small to be worth a transfer wait for a later period. Every payout is listed with its signature on the coin's rewards page. Also custodial.

• Creator only: fees accrue in a creator vault derived from the creator wallet (shared by all of that wallet's coins). The creator claims from the coin's rewards page; one claim covers every coin.
• Fee split: fees accrue in the coin's vault. Anyone can trigger distribute_creator_fees_v2, which pays every shareholder their share directly. Recipients don't claim. Pump enforces a minimum distributable amount.
• Pump holder rewards: pump.fun's distribution authority pays holders. There is nothing to claim.

PIMPFUN keeps these separate everywhere: configured allocations, fees received (settled trade events), available (live vault balance), distributed and claimed (settled payout transactions). Pending and failed transactions never count toward totals, and estimates are labeled as estimates.

Pump supports holder rewards only as a whole-coin mode chosen at creation. Splitting part of the creator fee to holders requires a PIMPFUN vault program, which is designed but not deployed. The design:

• The vault is a fee-split shareholder; its program alone can move funds.
• Snapshots of token balances at random times within each period, from an indexer, reproducible from chain data.
• Eligibility: a minimum balance; bonding curve, pool, burn, creator and team addresses excluded; per-wallet cap.
• Pro-rata allocation in integer base units; remainders roll over. A Merkle root per period is posted on chain.
• Holders claim with a Merkle proof; each claim is recorded once (bitmap) so nothing pays twice.
• Anti-Sybil: snapshot timing is unpredictable, small balances are excluded, and splitting a balance across wallets gains nothing pro-rata.

The accounting core is implemented and tested; the program needs an audit before it can hold funds. See docs/HOLDER_REWARDS.md.

Pump charges a protocol fee and a creator fee on every bonding-curve trade, by market-cap tier; PumpSwap adds an LP fee after graduation. PIMPFUN adds no fee of its own. You also pay the Solana network fee (5,000 lamports per signature) and a priority fee, shown on every review screen.

• Pump (bonding curve) 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P: create_v2, buy_exact_quote_in_v3, sell_v3, distribute_creator_fees_v2, creator fee collection.
• Pump Fees pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ: create_fee_sharing_config, update_fee_shares_v2.
• PumpSwap pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA: buy and sell on the canonical pool after graduation.

SOL-paired coins only. Legacy cashback coins are not tradable here.

Every coin page has a safety score from 0 to 100 with the checks behind it. Coin lists flag launches where the creator sold its buy within minutes (“Dev rugged”) or where snipers and bundled wallets bought a large share in the first slots.

• From the mint: whether anyone can still mint or freeze, and whether Token-2022 extensions let someone move, tax or block holders' tokens.
• From a live holder snapshot: how much the 10 largest wallets and the creator hold, leaving out the bonding curve and pools.
• From the launch, as PIMPFUN saw it: what the creator wallet bought and sold and when, and which other wallets bought in the create slot or the next two (snipers; in the same slot, bundled), and how much of that they still hold.
• From the creator's history: how many of its other coins it dumped within 10 minutes.

A creator can hold or sell through other wallets, which no check can see, and launch signals exist only for coins PIMPFUN saw being created. A good score is not a promise; treat it as one input, not advice.

• Most meme coins lose almost all of their value. Treat any purchase as money you can lose entirely.
• Prices on a bonding curve move sharply with every trade, especially early. Slippage and price impact can be large.
• Anyone can launch a token with any name or ticker. Always verify the mint address.
• Large holders and creators can sell at any time. Check holder concentration on the token page.
• Trending ranks and price moves are informational and are not recommendations or investment advice.
• Transactions on Solana are final. A confirmed trade cannot be reversed.

• PIMPFUN never requests seed phrases or private keys, and connecting a wallet never authorizes a transaction.
• Every transaction is simulated and reviewed before signing; failed simulations cannot be approved.
• The relay rejects transactions with another fee payer, missing signatures, lookup tables or non-allowlisted programs.
• Off-chain writes (recipient labels) need a one-time signed message; nonces cannot be replayed.
• The server's RPC endpoint and API keys never reach the browser.

• Without the indexer database, lists and reward history are clearly labeled demo data; token pages still read live chain state.
• Holder counts need an indexer; without one the holders tab shows the top 20 accounts from RPC.
• Holder rewards and buyback & burn need the operator's keeper and are custodial (see above). A non-custodial holder vault is not built.
• Only SOL-paired coins; cashback coins and multi-hop routes are not supported.
• Rate limits are per server instance; use a shared store behind multiple instances.
• The indexer listens to RPC logs and can miss events during disconnects; production should use a replayable stream.

Ready to try it? Launch a token.

What this deployment can do right now: