One launch. An ongoing fee cycle.
WheelPad creates Solana tokens through pump.fun and configures a dedicated creator-fee recipient for each token. A background service monitors those fees, buys the same token with its allocated revenue, and burns the tokens it purchased.
The creator signs the launch in Phantom. Subsequent fee collection, purchases, and burns use service-controlled signers; the creator does not need to keep the website open.
Buybacks & burns
Eligible creator fees allocated to that token’s automation wallet.
Original creator
The creator’s allocation remains directed to their wallet.
From details to a confirmed mint.
Use a Phantom wallet with enough SOL for the network fee and account creation. WheelPad supports SOL as the launch quote asset. The final wallet approval is your authorization to create the token and accept its fee configuration.
- 01
Connect your wallet
Open Create coin and connect Phantom. The wallet that signs becomes the original creator and receives the 10% allocation.
- 02
Provide token details
Enter a name, ticker, description, and image, or provide supported hosted metadata. Uploaded images must be PNG, JPEG, GIF, or WebP, up to 5 MB. Names support up to 32 UTF-8 bytes; tickers support up to 13.
- 03
Review the permanent split
Accept the 90/10 allocation, then review the mint, creator, automation recipient, and estimated costs. The current launch flow uses zero initial buy; token creation is separate from purchasing tokens.
- 04
Sign and wait for confirmation
Phantom presents the launch transaction. Token creation and fee-sharing configuration are bundled atomically: an instruction failure rolls back the transaction’s state changes, although a network fee may still be charged.
- 05
Open your token page
After registration, the coin appears in the catalog. Its page shows its mint, creator, market snapshots, execution status, and confirmed transaction history.
/token/<mint-address>New metadata contains the full WheelPad token-page URL in both website and external_url. Existing hosted metadata is republished with this link. Third-party platforms control when they refresh or display metadata.
Know where the funds go.
The 90/10 split applies to eligible creator fees. It is not a percentage of all trading volume, the token supply, or every fee charged by the underlying market.
| Account | Responsibility | Funds used |
|---|---|---|
| Creator wallet | Signs the launch; receives its creator-fee share | 10% allocation |
| Token automation wallet | Receives that mint’s allocation; signs purchases and burns | 90% allocation |
| WheelPad treasury | Sponsors execution fees and required account creation | Service SOL reserve |
| Protocol fee accounts | Hold and distribute accrued fees through supported instructions | Accrued protocol-managed fees |
One recipient per token
Each registered mint has a dedicated automation recipient. Funds credited to a token’s buyback allocation are used to purchase that same token. The creator’s 10% is not part of the automation spending budget.
Permanent creator configuration
The launch revokes the creator’s ability to edit the fee split through the supported configuration workflow. This does not remove pump.fun’s program-level administrative powers. WheelPad checks routing before execution and pauses affected work if the expected allocation changes.
Six stages. Separate receipts.
The persistent worker runs independently of browser sessions. A database-backed job records each stage, signed transaction, confirmation, and retry so execution can resume after a service restart.
Monitor
Inspect the registered mint, market lifecycle, accrued fees, and recipient balances.
Collect
Use supported fee instructions and verify the resulting 90/10 distribution.
Validate
Check allocation, quote, liquidity, price impact, slippage, and transaction costs.
Buy
Purchase the originating token and verify the actual received quantity.
Burn
Submit the appropriate SPL Token or Token-2022 burn for the purchased amount.
Reconcile
Confirm the receipt and supply reduction before recording a completed burn.
When does a buyback happen?
The deployed default minimum is 0.1 SOL of eligible buyback allocation. Reaching it makes work eligible for evaluation; it does not guarantee immediate execution. Network costs, account rent, available liquidity, and transaction validation can require additional accumulation or a retry.
| Control | Default | Purpose |
|---|---|---|
| Minimum buyback allocation | 0.1 SOL | Avoid uneconomical small cycles |
| Maximum buy input per execution | 1 SOL | Bound individual purchases |
| Slippage limit | 1% | Reject fills outside the accepted limit |
| Price-impact limit | 2% | Restrict execution against shallow liquidity |
| Cycle cost limit | 5% of budget | Check estimated execution economics |
These are operator-configurable defaults, not immutable protocol parameters. Execution always uses the active server configuration and current on-chain state.
The route follows the market.
pump.fun bonding curve
The engine uses supported bonding-curve fee collection and trading instructions. Purchases are evaluated against the curve’s live state.
Canonical PumpSwap pool
The engine switches to the supported pool and creator-fee path. It validates the mint and pool rather than continuing to submit bonding-curve purchases.
A migration in progress, missing pool, or insufficient liquidity can delay execution. The job retains its allocation and retries when the market becomes usable. Graduation does not itself prove that a buyback or burn has occurred.
Read the evidence, not a counter.
The token page and Buybacks & burns dashboard separate pending allocations, executed purchases, and verified burns. A submitted transaction is not a completed execution.
- Purchased tokens
- Tokens received in a verified purchase. They may still be waiting for the burn stage.
- Burned tokens
- Tokens destroyed by a finalized burn whose token balance and supply reduction were checked.
- Transaction history
- Recorded signatures link to Solscan so the underlying on-chain activity can be inspected.
- Price and chart
- Recorded on-chain reserve-price snapshots, starting when WheelPad monitors the token. These are not reconstructed trade-by-trade OHLC candles.
- Execution status
- The latest stored job state, including pending stages, errors, and scheduled retries.
On-chain rules. Service-run execution.
Fee routing and transactions live on Solana. Scheduling and signing are performed by WheelPad’s backend. The system depends on service availability, secure signing keys, supported protocol behavior, RPC access, and a funded treasury.
Wallet boundaries
Creators sign through Phantom. WheelPad does not need a creator’s recovery phrase or private key. The automation wallet is service-controlled, not creator-controlled; its signing infrastructure is a trust dependency.
Retries without duplicate purchases
Per-token locks prevent competing workers from executing the same job. Signed bytes and signatures are stored before submission. An uncertain transaction is reconciled before a replacement is prepared.
A failed burn remains a pending burn
If a purchase succeeds and its burn fails, the job resumes at the burn stage. It does not record a successful burn or intentionally repeat the purchase to retry that stage.
Pauses and outages
Operators can pause automation. Launch availability and engine availability are separate controls: launches may be open while automation is paused, in which case the launch page discloses that fees can accrue without immediate buybacks. RPC outages, expired transactions, and market failures are surfaced as pending or retry states.
No execution schedule, price support, investment return, or uninterrupted availability is guaranteed. Permanent fee settings should be reviewed before signing.
Before you launch.
Do I need to keep Phantom connected?
No. After the launch is confirmed and registered, recurring operations use the service signers. The creator does not sign each buyback.
Does any trade immediately trigger a burn?
No. Eligible fees accumulate, then threshold and cost checks determine when a cycle can run. A burn is a separate transaction after the purchase.
Who pays for execution?
The creator pays launch costs. Buyback input comes from the token’s allocated fees. The WheelPad treasury sponsors automation network fees and required account rent.
Can I change the split after launch?
The supported launch workflow removes the creator’s edit authority. Treat the 90/10 split as permanent when approving it.
Why does my coin’s website point to WheelPad?
New launches automatically publish a website link to their mint-specific WheelPad page. That provides a consistent place to inspect the token and its execution history.
Are purchased tokens added to liquidity?
No. This implementation burns the purchased tokens. Providing liquidity would be a separate mechanism requiring both assets and its own execution rules.
Can an existing token join automatically?
No. The engine monitors verified WheelPad registrations and their configured recipients. An unrelated token or an older manual-model launch is not automatically enrolled.
The essential terms.
- Mint
- The Solana address identifying a specific token.
- Creator fee
- The portion of market fees made available to the token’s configured creator recipients.
- Buyback allocation
- Verified fee revenue assigned to purchasing the originating token.
- Burn
- A token-program instruction that destroys tokens and reduces mint supply.
- Graduation
- The transition from the bonding curve to the supported liquidity-pool market.
- Finalized receipt
- Transaction data confirmed at Solana’s finalized commitment and checked against the intended operation.