Understand the flow.

For eligible creator fees received by the engine, the custody program sends 10% to the configured public protocol treasury and commits the remainder to the coin’s liquidity engine. Integer rounding is deterministic; the engine receives the remainder.

The split is enforced after receipt. Network costs and the initial launch funding are accounted for separately. The treasury does not need a private key to receive SOL, and its key is never part of the website or keeper’s normal execution.

Pump.fun’s upstream creator and fee-routing authorities can influence where future creator fees go. An engine cannot make an upstream permission immutable. A change can stop new fees from reaching the engine even while existing committed reserves remain subject to its custody rules.

The keeper compares the expected creator address and the observed creator address. If routing no longer matches, automation pauses and the dashboard flags the change. Do not interpret the 90 / 10 engine rule as an immutable promise about all future Pump.fun fees.

At launch, an explicit initial liquidity seed funds token acquisition and an ordinary PumpSwap pool in the same atomic transaction as coin creation and engine initialization. This creates the early pool before an outside trader can graduate the bonding curve.

The quote asset is wrapped SOL. The ordinary early pool is distinct from the canonical PumpSwap pool created at graduation. PUMPFLOW tracks both addresses and continues verified operations through the lifecycle.

Future deposits occur only when real reserves meet the configured minimums. Unspent reserves remain in program-controlled custody; the interface never presents accumulated reserves as deposited liquidity.

The initial liquidity seed is committed capital, separate from creator fees. It is not a protocol fee and is not subject to the 10% treasury allocation. There is no creator withdrawal option for assets committed to the engine.

A separate operating reserve covers account setup and operations. Transaction preparation uses a real network simulation to estimate the total wallet debit, including relevant account funding and network costs. You review the prepared transaction in your wallet before signing.

Launching uses two wallet approvals. The first creates only required token accounts and spends account rent plus network fees. After it finalizes, the second creates the coin, initializes its engine, deposits the liquidity seed, creates the early pool, and burns the LP tokens atomically. Each transaction is simulated and priced separately. Abandoning the launch after the first approval can leave account rent committed; keep the original tab open between approvals.

There is no optional developer purchase in the current launch flow. The seed token purchase exists exclusively to fund the engine’s pool.

The engine burns the LP tokens issued to it when it deposits liquidity. Burning destroys that withdrawal claim. “Permanently deposited” on the dashboard means verified lifetime deposit amounts with corresponding LP burns.

Pool reserves and the market value of deposited liquidity change as traders swap. Lifetime deposits are therefore distinct from the current dollar or SOL value of a position. The dashboard links the actual deposits and burns for inspection.

After launch, token acquisitions require price-bound attestations from at least 2 of 3 distinct price observers. This limits the keeper’s ability to choose an adverse price alone.

The independent model uses observers with independent administrators. The single-operator model uses three isolated services and distinct signing keys under one operator. Shared administration can lead to correlated compromise or common administrative failure across the quorum; separate keys and isolated services do not remove that operator trust.

The observers are an additional trust assumption. Their public keys are fixed in the deployed configuration. Launch review discloses the keys and selected operating model; the host selection must match its deployment manifest. Both models retain the same 2 of 3 signature threshold and price and history checks. If enough valid attestations are unavailable, acquisition pauses rather than removing the price constraint.

Public launch readiness must verify the live program’s immutable configuration, treasury address, supported token programs, and account layout. Deployments with an active upgrade authority or test configuration must fail the production readiness check.

The interface also requires explicit server approval for the deployed configuration and a separate mainnet approval. There are two release review paths. An audited release supplies the reviewed source commit, reviewer, and external report, with explicit audit approval on the host. An unaudited release requires an explicit operator approval in both its deployment manifest and the host configuration. That path is labeled “Unaudited, operator-approved”; no external audit has been provided.

Both paths bind the source commit, exact program hash, treasury, and network genesis. Live bytes and network identity must match the manifest, and all custody and launch checks still apply. For an audited release, the supplied report and its scope still need independent review. When any required check fails, coin creation remains unavailable. Connecting a wallet does not grant spending approval.

Coin metrics come from persisted on-chain observations. Transaction histories contain real signatures, and price charts use recorded market observations. Missing data appears as a dash or an explicit unavailable state.

Operator income periods cover observed finalized counter changes after registration. They do not imply historical backfill. Treasury totals describe verified PUMPFLOW distributions and do not include unrelated wallet transfers.