TokenPromotePro: Atomic SPL Minting and Distributed Liquidity Execution on Solana

Technical architecture — Solana mainnet · October 2026

Abstract. TokenPromotePro is a non-custodial, pay-per-action toolkit on Solana mainnet comprising five services: an atomic SPL token minter, a social-velocity promotion service, a 24-hour distributed buy-side liquidity engine, a token safety scanner with bundled-wallet detection, and a memecoin discovery terminal. This document describes the on-chain architecture, the wallet-distribution model, the payment-verification protocol, and the refund mechanics. All monetary flows are verifiable on-chain; no component requires user credentials or custody of user keys.

1. System Overview

The platform runs as a static frontend with serverless backend functions, backed by a PostgreSQL ledger (Supabase) and direct JSON-RPC access to Solana mainnet. Identity is wallet-based: a Phantom/Solflare/Backpack connection serves as both authentication and payment rail. Every paid action follows the same protocol: server-issued signed quote → user-signed transaction → on-chain verification → service activation.

Component	Function	Cost model
Launchpad	Atomic SPL mint + Metaplex metadata	0.05 SOL + rent ≈ 0.02 SOL
Social Boost	Timed visibility campaign	0.2 / 0.5 SOL
Master Liquidity	24h distributed buy-side execution	0.6–3.0 SOL + budget ≥ 2 SOL
Rug-Scan / SWR	Safety analysis + bundle detection	Free / 0.1–0.2 SOL
Degen Terminal	Discovery feed + quick-buy	Free / 0.5 SOL unlock

2. Token Launch Architecture

2.1 Atomic transaction composition

A launch composes a single transaction with the following instruction sequence:

transfer(fee → recipient) createAccount(mint, rent-exempt, space=82) initializeMint(decimals, mintAuthority=payer, freezeAuthority=payer) createAssociatedTokenAccount(owner=payer) mintTo(mint → payer_ata, supply) createMetadataAccountV3(name, symbol, uri=IPFS) setAuthority(mint → null) [optional, +0.1 SOL] setAuthority(freeze → null) [optional, +0.1 SOL] updateMetadata(updateAuth → burn)[optional, +0.1 SOL]

Atomicity guarantees that a token either exists fully — minted, supplied, and metadata-annotated — or the entire operation reverts. Authority revocation is instruction-level in the same transaction, so a deployer cannot retain authority beyond the landing of the launch transaction.

2.2 Metadata pipeline

Token images are uploaded to IPFS via a server-side Pinata gateway; the metadata JSON (name, symbol, image URI, description, external links) is referenced by the Metaplex account. Clone mode resolves an existing mint's metadata through a three-source fallback: Metaplex PDA → pump.fun endpoint → Dexscreener API.

2.3 Supply constraint

Supply is bounded by the u64 representation: supply × 10^decimals < 1.8 × 10^19.

3. Distributed Liquidity Execution

3.1 Session lifecycle

PENDING_PAYMENT → quote issued (HMAC-signed, 10-min TTL) PAID_VERIFIED → dual-transfer confirmed on-chain RUNNING → engine ticks execute distributed buys DEGRADED → transient failure; auto-recovers on next good tick ENDED / FAILED → terminal; refundable via sweep

3.2 Wallet-distribution model

On payment verification, the engine generates one master wallet and 20 child wallets. The user's trading budget (≥ 2 SOL) is split across the children, which then act as 20 distinct holder addresses. This produces real, distributed on-chain buying rather than a single concentrated buyer footprint.

3.3 Execution path

Each engine tick selects active child wallets and issues buy-side (SOL_TO_TOKEN) swap quotes through the Jupiter Lite API. Swap transactions are submitted as Jito bundles for MEV-protected inclusion. Only confirmed landings increment session metrics (tx_count, volume_sol); unconfirmed submissions are recorded as deferred events while the budget accounts for potentially spent lamports.

3.4 Budget accounting

Per executed buy, the ledger deducts: swap amount + Jito tip + transaction fee + first-buy associated-token-account rent (~0.002 SOL). This prevents the drift condition where on-chain balances empty before the recorded budget reaches zero.

3.5 Tiers

Tier	Fee	Execution intensity
IGNITE	0.6 SOL	Baseline distributed buys, randomized intervals
PHANTOM	1.1 SOL	Higher distribution diversity, reduced on-chain linkage
GODMODE	3.0 SOL	Maximum intensity, priority bundle submission

3.6 Refund mechanics (refund-to-last-lamport)

Session termination — manual or at the 24-hour boundary — triggers the sweep engine: it reads live on-chain balances of all 20 children and the master, issues per-wallet transfers back to the user, deducts only the required transaction fees, and records the refund in an idempotent ledger entry enforced by a partial unique index. Dust below the sweep-fee threshold (~6,000 lamports) is skipped by design.

4. Timed Promotion Campaigns (Social Boost)

Social Boost activates a fixed-duration visibility campaign for an existing token. Payment follows the same quote-bound protocol: the server signs the price (0.2 SOL Public / 2-hour window, or 0.5 SOL Private / 6-hour window) together with the token contract address, and the campaign is only registered after the on-chain transfer verifies. Campaign state is stored in the ledger keyed to the paying wallet; no account or email is collected. Lead notifications to the operator channel pass through Cloudflare Turnstile and server-side input validation.

5. Discovery Terminal (Degen Terminal)

The Degen Terminal is a real-time discovery surface built on public data streams:

New-token feed: a direct WebSocket subscription to the pump.fun launch stream renders new mints as they are created.
Golden Dev Hunter: deployer addresses are matched against the history of previously launched tokens; repeat deployers with graduated tokens are flagged inline.
Shadow Whale tracking: monitors large SOL transfers from exchange-linked wallets to fresh addresses — an early-accumulation signal.
Migration & sniper context: tracks pump.fun → Raydium migrations and sniper activity around new listings.
Market data: charts and token metadata are served through public aggregator APIs (Dexscreener, pump.fun).

The terminal is free to read. The optional Alpha Vault unlock (0.5 SOL, quote-bound payment like every other service) exposes the top-5 ranked signals per feed for the session window.

6. Safety Analysis & Bundle Detection (SWR)

The free scan evaluates mint/freeze authority, LP burn percentage, top-holder concentration, Token-2022 transfer fees, and deployer history. The paid SWR deep-scan reconstructs funding links between wallets: clusters of wallets funded by a common source inside a short window, holding >5% of supply in aggregate, are flagged as bundled distribution — the primary signature of insider-controlled supply. The scanner also surfaces reclaimable rent: empty token accounts owned by the connected wallet can be closed to recover their SOL rent deposits.

7. Payment Verification Protocol

Verification is quote-bound and replay-resistant:

Quote issued server-side: HMAC-SHA256(service, price, token_ca, recipient, expiry). Client-supplied prices are never trusted.
Payment must be a single transaction containing the required transfer instructions (service fee → service wallet; budget → session master wallet for liquidity).
Transaction signature is checked against a durable replay store; reuse across any payment flow is rejected.
Freshness: the transaction must land within a 24-hour window of verification.
For liquidity sessions, the token CA is taken from the quote — not from the client payload — so a session cannot be re-targeted after quoting.

8. Security Model

Custody: non-custodial end to end; users sign all payments in their own wallet. Session-wallet secrets are AES-256-GCM encrypted at rest and zeroized from memory post-use.
Session access: status and restore endpoints bind responses to the paying wallet via token + Ed25519 signature verification; cross-session reads are rejected.
Edge: Cloudflare ASN filtering and rate limiting; Cloudflare Turnstile (invisible) on lead-capture; server-side input validation on every public endpoint.
Funding recovery: if a wallet-distribution batch fails mid-way, funded children are swept back to the master wallet — no lamports can be stranded in untracked keypairs.

9. Conclusion

TokenPromotePro implements a fully on-chain, non-custodial service architecture: atomic minting, quote-bound payments, distributed buy-side execution across 20 wallets, deterministic refunds, real-time discovery feeds, and on-chain safety analysis. Every claim in this document maps to an observable on-chain mechanism.