Know the loop.
Then sign.
- Choose StonkFun or Pump.fun. All token launches use Solana mainnet and require wallet approval.
- Check each venue’s current status. Public launching stays closed until the complete real reward cycle is accepted. Pump remains beta.
- Use a creator wallet separate from the configured reward treasury. Review token details, the fixed allocation, network, program, treasuries and transaction cost before signing.
- Keep the launch receipt. A successful token launch and successful tracker activation are separate states.
- When live funding is enabled, open your creator dashboard and review an explicit deposit. Verify its finalized funding receipt.
- Wait for complete history and a finalized eligible snapshot. The treasury wallet must approve a prepared payout. Only finalized recipient transactions count as paid.
Venue fees do not automatically become rewards. Creators explicitly fund each launch’s isolated reward pool.
Would you qualify?
Change one thing.
Move the price. Sell. Receive tokens. Remove the funding. See which changes affect eligibility and which affect the budget.
One wallet buys 10 tokens at 10 STONK, then 10 at 20. Its weighted entry is 15. Change what happens next.
Both buys establish entry. The 20 retained verified units can qualify when the snapshot price is below 15.
(not paid)57.60fictional STONK
The existing TopBlast calculator is reused. Another sample buyer may share the pool. All wallets, prices, and funding here are fictional; no transactions or signatures are created.
Fresh wallet.
Public address only.
- Create a wallet or account in your trusted Solana wallet app and keep its recovery material private.
- Use one account as the creator and a different account as the reward treasury. The protocol treasury may share the reward-treasury address for this MVP.
- Provide only public treasury addresses in the website. Never put a private key or recovery phrase into Supabase, Vercel, browser storage, this website, Git, or chat.
- After address and infrastructure checks, review a mainnet launch through the platform. Approve its concrete transaction in your creator wallet.
- Then verify funding, buyer tracking, an eligible finalized snapshot, and a confirmed direct holder payout. A successful token launch alone does not prove rewards work.
Keep gas funding separate from reward funding: SOL pays network costs; the launch-specific funding action supplies STONK or WSOL rewards. Review the required amounts before moving funds. Read Solana’s signing guidance.
Launch underneath.
Rewards on top.
StonkFun or Pump.fun provides token creation and trading infrastructure. TopBlast tracks verified buyers and calculates rewards from that launch’s funded pool. TopBlast does not run its own curve, AMM, or exchange.
For creators
Choose a venue and fixed allocation. Review and sign your launch. Fund its rewards from your creator dashboard.
For holders
Buy through the recognized market. Keep holding. Look up your wallet on the token page and check confirmed payouts on its proof page.
Two options.
One reward engine.
| Venue | Pair | Reward asset | Funding |
|---|---|---|---|
| StonkFun | STONK | STONK | Explicit creator deposit |
| Pump.fun | SOL | Wrapped SOL (WSOL) | Explicit creator deposit |
Pump support uses the official creation instruction, with no initial buy. Native Pump holder rewards, cashback, mayhem mode, and non-SOL pairs are not enabled.
Venue activation depends on the checks displayed in the launch form. A supported option is not evidence of a completed real launch-to-payout test.
Review. Sign.
Keep the receipt.
- Connect your creator wallet on Solana mainnet. Choose the venue, token details, image, and fee allocation. Allocations total 100% and are fixed at launch.
- Review the token, pair, allocation, network, fee payer, recipient or program, and payment estimate. Expired quotes need a fresh review. Switching wallet accounts invalidates the prepared quote.
- Approve in your wallet only after reviewing the transaction. Creation costs real funds. Pump creation estimates can change with network fees.
- Keep the receipt. A timeout does not mean the transaction failed. Use the existing recovery action or creator dashboard before starting another launch.
- Wait for token creation and tracker activation separately. If the token exists but tracking is pending, retry registration without paying for another token.
Submission receipts are stored before broadcast, and the browser retains its recovery reference. Use the same wallet after refresh. Never send a second payment just because a response is slow.
No deposit.
No reward budget.
Venue fees do not automatically become rewards. Creators explicitly fund each launch’s isolated reward pool.
StonkFun standard LaunchLab creator fees may be forwarded to the creator automatically; any creator quote-vault claim is creator-scoped, not safely attributable to one launch. Pump creator fees follow Pump’s creator-wide vault mechanics. After fees reach the creator wallet, use Fund rewards in the creator dashboard. An allocation slider does not redirect venue fees onchain.
Enter a gross amount for the configured split. The reward and protocol portions are transferred; the creator portion stays in the creator wallet. An 80/20 selection on the creator’s 90% share means 72/18/10 of gross: declaring 100 units sends 72 to rewards and 10 to the protocol, retaining 18. It does not deposit 100 into the reward pool.
For StonkFun, funding transfers STONK. For Pump, the transferred portions are wrapped from SOL into WSOL. Wrapping is not a swap. You also need SOL for network fees and account rent.
The creator wallet must differ from the reward treasury. Use the funding action rather than an arbitrary transfer: the signed transaction binds the launch, sender, recipients, mint, exact amounts, and unique funding reference. Credit requires finalized verification. A deposit cannot be credited twice or used by another launch.
Verified buys
set your entry.
- Only recognized, successful market buys create purchased cost basis. Multiple buys produce a quantity-weighted average entry.
- Incoming transfers create no purchased cost basis. They do not turn transferred tokens into verified eligible units.
- A sell or outgoing transfer excludes the wallet for that epoch. Outgoing activity consumes verified units first.
- Uncertain or incomplete history, stale prices, and unverified activity cannot produce payable allocations.
- Eligibility is evaluated against a consistent finalized snapshot, not the moving price in an illustrative chart.
Eligible loss = retained verified units × max(average entry − snapshot price, 0)
Wallet allocation = funded epoch budget × wallet eligible loss ÷ total eligible loss
The engine uses exact integer amounts, configured caps, and deterministic rounding. Total allocations cannot exceed the reserved funded budget. Previous rewards remain in history; they are not silently substituted for a different eligibility formula.
Wallet lookup distinguishes eligible, above entry, transferred, sold this epoch, insufficient history, and not a verified buyer. The interactive homepage graphic and free test use examples, not live account balances.
Allocated
does not mean paid.
- Available
- Finalized, attributable funding not reserved for an epoch.
- Reserved
- Budget held for a specific epoch. It cannot fund another epoch at the same time.
- Allocated
- A calculated share for a wallet. No transfer is implied.
- Submitted
- A signed payout has been broadcast. Finalized payment has not yet been verified.
- Paid
- The transfer has been verified onchain. Public totals count confirmed payouts, not proposed allocations.
Each token’s proof page records snapshot slot and time, funding receipts, budget, wallet allocations, payout states, and transaction links. Pending or failed batches retain their state for reconciliation. Restarting the worker must not create another payment for an already-paid allocation.
Direct holder payouts can use manual treasury approval or the isolated Railway signer. Both modes bind the exact transaction before broadcast and count only finalized proof as paid.
Real receipts.
A proven cycle.
Illustrative examples explain the rules. They create no token and send no funds. They are not proof of live payouts.
A real controlled acceptance test must demonstrate: launch → verified buy → attributable funding → finalized eligibility → funded allocation → confirmed payout → public proof → restart without duplication. A price drop and actual eligible loss are required; do not manipulate a market to manufacture eligibility.
Operators must configure public reward and protocol treasury addresses, verify database and worker health, and explicitly enable controlled launches. No seed phrase or private key should be pasted into chat, Vercel, or Railway for manual-wallet mode.
What this is not.
TopBlast is not an exchange, bonding curve, AMM, insurance policy, or guaranteed loss-recovery product. Venue names identify integrations, not endorsement or operation by those venues.
Your weighted entry.
Only verified market buys establish cost. Buy 10 units for 20 quote units, then 10 for 40: the retained 20-unit position has an average entry of 3 quote units. Received tokens establish no new purchased basis. Outgoing activity consumes verified units first and excludes the wallet for the applicable epoch.
Calculations use actual mint decimals and integer base units. UI spot prices are not authorization for a payout; the finalized snapshot uses its validated price source.
One finalized checkpoint.
Schedule → acquire worker lease → reconcile finalized history → validate snapshot price → reserve attributable funding → record wallet snapshots → calculate loss-weighted allocations → prepare batches → obtain treasury approval → submit → reconcile finality → publish proof.
Missing history, stale price, unsupported markets and engine pauses stop payable allocation. A zero-funded epoch cannot distribute rewards.
Fixed at launch.
The fixed 10% protocol share and the creator’s division of the remaining 90% apply to explicit funding, not trades. The final gross allocation must total 100%. New launch controls use exact whole-percent policies, subject to the configured minimum reward allocation. The review shows both percentages before approval.
Your treasury pays holders.
TopBlast prepares launch-scoped direct-airdrop batches containing the exact asset, recipients, amounts, fee payer and network. Manual mode uses treasury-wallet approval. Server mode uses a Railway-only key that must match the configured treasury, signs only the stored message, enforces a per-batch ceiling and serializes unresolved spending.
Holders never claim. Never approve an unexplained transfer. Reserved and submitted balances are not confirmed payouts.
Recover the receipt.
Do not pay twice.
After a timeout, refresh or closed tab, use the saved launch or funding receipt. A delayed response does not establish failure. The server binds signed transactions before broadcasting and reconciles their finality. A restart must resume the same payment, not generate a replacement.
Partial payout recovery operates per batch and recipient. Confirmed transfers stay paid; unresolved batches remain reserved or submitted until reconciled. Retry tracking after a completed launch without creating another token.
Know the boundaries.
- Automatic venue-fee funding is not deployed. Creators explicitly deposit.
- Pump is beta: official creation only, no initial buy, native cashback, mayhem or non-SOL pairs.
- PumpSwap graduation is unsupported. Tracking and new epochs pause after unsupported graduation.
- Unproven production acceptance means public launches stay disabled. A passing build is not a payout receipt.
- Controlled tests are real mainnet tokens and may be visibly labelled as tests. Hiding a listing cannot remove onchain history.
Exact transactions only.
Never paste private keys or recovery phrases into this site, chat, browser storage, Supabase, Vercel or Git. Connect only through a trusted wallet and review each exact transaction. If automatic payouts are selected, the treasury key is entered directly into Railway’s protected worker variables and nowhere else.
Financial records are scoped to launch IDs. Funding signatures cannot be reused across launches; database reservations prevent competing epochs from spending the same budget. Public readers cannot modify financial records. Operator actions require separate authorization; connecting a wallet to view public data does not grant administrative access.
Report unexpected recipients, missing receipts or inconsistent balances before signing anything else. Large treasury movements should use an independently reviewed approval process.
Participation.
Not protection.
TopBlast rewards participation. It does not promise to recover losses. Token prices can fall to zero. Eligibility and funding may be insufficient, delayed or unavailable. Venue, RPC, wallet and smart-contract failures can interrupt operation. No APY, guaranteed payment or guaranteed principal recovery is offered.