Good questions.
Clear answers.

A launch studio.
Not another exchange.

UnderWaterPad combines an editable launch brief, supported venue integrations, creator configuration and an existing launch-scoped reward ledger. StonkFun and Pump.fun provide token creation and trading. UnderWaterPad does not operate a bonding curve, AMM or exchange.

The rebrand does not rewrite old transactions, immutable policies, wallet positions or paid receipts. Historical token names remain the names of those tokens.

From idea to review.

1. Open the studio. Describe your idea or start with a manual template.
2. Edit the brief. Check names, rights, claims and risks yourself.
3. Save and explicitly apply the name, ticker and description in the launch form.
4. Choose a supported venue and pair, upload your image, set the holder / creator split and optional first buy.
5. Connect your wallet and review the exact mainnet transaction, recipients, costs and permanent limitations.
6. After confirmation, use the dashboard and token page to inspect tracking, funding and payout receipts.

A completed launch is not evidence that the reward lifecycle is proven.

A copy editor.
Not your wallet.

The AI studio produces a proposed name, ticker, description, one-liner, announcement and checklist. It sends only the idea, tone and venue you enter to OpenAI. Generation is available only when the server provider and usage checks are configured. The manual template remains usable without AI.

The output is validated and editable. It cannot choose a recipient, set your allocation, sign, launch, post to X, select reward recipients or move money. Import applies only three text fields after your explicit click. Saved briefs stay in this browser; export them if you need another device.

Do not include confidential information, private keys or seed phrases. AI can produce errors, misleading claims or names already in use. Check everything before publication. Provider requests use storage disabled; this does not make a zero-retention promise about provider security logs.

Familiar venues.
Honest boundaries.

Pair support does not prove a full production reward cycle. Availability checks remain authoritative. Neither venue operates or endorses UnderWaterPad.

Review first.
Approve once.

The form shows token details, venue, network, quote and reward asset, fee recipient, creator wallet, allocation and estimated costs before approval. Optional first-buy controls use the selected quote asset and supported venue path. Bought tokens are sent to the creator, not invented in the UI.

Your wallet signs the exact prepared transaction. A timeout does not mean failure. Public receipt identifiers are stored before submission so a refresh can recover the same launch. A launched token with a failed tracker needs registration recovery, not another payment.

Your share, simply.

The holder and creator controls divide the distributable 90% and total 100% on screen. The protocol share is 10% of verified funding. An 80 / 20 choice therefore records 72% holders, 18% creator and 10% protocol of gross funding. Controls use 10-point increments to match exact integer database percentages.

This allocates received funding. It is not an additional trading tax. Minimum reward requirements and exact enforced amounts are checked during preparation. The policy is fixed at launch; old launches retain their policy. A protocol allocation is not proof of a buyback, burn or a newly launched UnderWaterPad token.

Accrued is not funded.

Funding is credited only after a finalized receipt has been attributed to one launch. New Stonk launches use isolated fee receivers. Legacy shared-wallet attribution can remain blocked. A dedicated receiver may accept voluntary funding, so a sweep alone does not prove every unit came from trading fees. Pump requires its verified per-mint distribution receipt.

Creator deposits are a separate path with transaction verification. Gas SOL is operating money, not reward funding. A quote asset may be WSOL or another supported token; no swap is silently invented. The full automatic lifecycle must be demonstrated with real receipts before being described as production-proven.

Only verified buys
establish entry.

• Weighted entry is based on recognized market buys and exact token amounts.
• Incoming transfers create no purchase price or purchased cost basis.
• Sells and outgoing transfers exclude the wallet for the applicable epoch.
• The retained verified position must be below its verified entry at a finalized snapshot.
• Missing history, stale prices or an unfunded pool cannot produce payable rewards.

The existing loss-weighted formula and caps are preserved. This is not guaranteed compensation or a promise to recover losses.

Change one condition.

An illustrative eligibility calculator, not a live position or payment.

One checkpoint.
One accountable budget.

The worker acquires a lease, reconciles finalized history, validates the snapshot price, reserves attributable funding, records positions, calculates deterministic allocations and prepares batches. Payouts require the configured wallet approval or authorized isolated server signer. Only confirmed transfers count as paid.

The current schedule is operator-configured, not a per-token timing control in the form. Unspent balances remain with the same launch. AI cannot override eligibility or reserves.

Allocated is not paid.

Available

Verified funding not reserved for an epoch.

Reserved

Funding held for a particular epoch, not yet paid.

Submitted

A stored signed transaction was broadcast; confirmation is unresolved.

Paid

Finalized recipient transfers have been verified and linked to public proof.

Open a token’s proof page for its snapshots, allocations, signatures, failed or unpaid amounts and recovery status. An absent receipt is not a successful payout.

Recover the receipt.
Do not pay twice.

Use the saved receipt after a refresh or timeout. Signed transactions are bound before broadcast. Confirmed payments stay confirmed across restarts. Unresolved batches must be reconciled before replacement; partial payouts recover per batch and recipient.

Community rewards
need real verification.

Contributor payouts inspired by social-reward platforms are a product direction, not an active reward mode. UnderWaterPad currently does not ingest X posts, verify handles or pay users for social engagement. No simulated leaderboard is presented as real.

Adding this requires authenticated account linking, authorized X data access, explicit scoring and dispute rules, anti-abuse checks, launch-level budgets and proof. Existing holder rewards will not silently be converted into social rewards.

Evidence before claims.

Examples and automated fixtures exercise behavior. They are not proof of live payouts. Acceptance must demonstrate a real launch, verified buy, attributable funding, finalized eligibility, funded allocation, confirmed payout and restart without duplication.

Dry run locks funding and payout submission. Creating a token on mainnet still costs real funds when launch creation is enabled. Rebranding or a passing build does not unlock production safeguards.

Keep your keys.
Keep the history.

Never paste secrets into this site, chat, browser storage, Supabase or Git. Signing secrets remain in the separately secured worker configuration. AI keys stay server-side and are never exposed through public variables.

Financial actions retain their authorization checks. The AI endpoint has a durable global limit of five requests per minute and one hundred per UTC day, bounded input/output and a timeout. If quota storage is unavailable, generation is blocked. Public record viewing does not grant spending permission.

Participation.
Not protection.

Tokens can lose all value. Fees, eligibility and rewards can be delayed or unavailable. Venue, wallet, RPC and smart-contract failures can interrupt operation. No APY, guaranteed return, guaranteed reward or guaranteed principal recovery is offered. Check naming and intellectual-property rights before using any generated idea.