How itworks.

PETAL reports volume generated by the project’s own wallet, not independent buyers or evidence of organic demand. Half of each token’s creator fees goes to that wallet. Of new receipts, 50% enters the token buy queue, 10% funds the flywheel and 40% is recorded as treasury. These allocations do not describe lifetime spending or guarantee a remaining treasury balance.

There are no usernames, emails or passwords. Connect Phantom, Solflare or Backpack and sign a short login message with a timestamp. The server checks the signature (ed25519) and rejects messages older than 2 minutes. Your account is created the first time you connect.

The login signature is not a transaction and cannot move funds.

Your image and metadata are uploaded to Pump.fun's IPFS. The server then builds the launch and simulates it on mainnet before your wallet ever sees it. If it would fail (for example, not enough SOL for the dev buy), you get the exact reason instead of a broken prompt.

1. 01

   Connect

   Sign a login message. No funds move.

2. 02

   Tx 1 · create

   Pump.fun create_v2 + optional dev buy. Your wallet signs first, then the token key.

3. 03

   Tx 2 · split

   Fee-sharing config: 5000 bps you, 5000 bps platform wallet.

4. 04

   Verify

   Server reads the on-chain config. Volume share must be ≥50%.

5. 05

   Live

   Token joins the volume cycle.

Transaction 1 calls Pump.fun create_v2, plus a dev buy if you chose one. Your wallet signs first. Then the server adds the new token's key signature and sends it, so wallets can add priority fees without breaking anything.

Transaction 2 creates the fee-sharing config. It has to be separate because both together go over Solana's 1232-byte transaction limit. It's built with a fresh blockhash after transaction 1 lands.

Pump.fun pays a creator fee on every bonding-curve trade. The sharing config sends 5000 bps to you and 5000 bps to the volume wallet. Pump.fun's program enforces this split, not our server.

A token only goes live once the server reads the on-chain config and finds the volume wallet at 50% or more. The browser can never set a token's status. If a creator later removes the volume wallet, the token stops cycling and is marked Paused.

A scheduled job fires every minute. It has to authenticate with a server-only secret, since it spends real funds. Each run handles up to 6 live tokens.

For each token, the volume wallet claims its fee share and measures its own SOL balance before and after. The difference is that token's earnings, so each token's own-buy allocation stays with that token.

40% of new earnings enters recorded SOL treasury in the volume wallet. Another 50% enters the queue to buy the token on its bonding curve or PumpSwap pool, split into 5 equal buys sent 5 seconds apart. The last 10% buys PETAL, so every token on the launchpad feeds the flywheel. Buys below 0.0025 SOL are held as pending and added to the next cycle. Ordinary tokens release 0.1% of their treasury each turn, with a minimum-buy top-up when no fees are claimable. This applies to new claims; existing SOL is not reclassified. When a token graduates off the bonding curve, buys continue on its PumpSwap pool.

the primary coin uses different spending rules: half its own remaining treasury enters its queue, then it targets the larger of that queue or 30% of the whole wallet balance, not their sum. Available SOL and transaction costs cap spending. It can use shared backing recorded for other tokens, so treasury is not ring-fenced. Lifetime spend can exceed its own claimed fees without implying extra fees or organic demand.

The volume wallet holds the server-only key that signs every claim and every buy. Its address comes from that key, so there is no separate setting to drift out of sync.

The wallet’s balances and transactions are public on-chain. Current token holdings are not the same as cumulative SOL spent; transaction history is the spending receipt. The remaining treasury is an accounting record, not a separate locked wallet balance.

• The volume wallet's private key exists only on the server. Its public address comes from that key and is never set separately.
• Launch transactions are simulated before signing and checked on the server (correct payer, correct token) before they're sent.
• Each token's key is stored in a private place only the server can read, and is used only to co-sign that token's launch.
• Status changes (draft → live → paused) come only from on-chain verification.
• The platform can pause all launches and volume cycles.