Everything before you unleash the bull

Overview

Liquidity Bull eats your Pump.fun creator fees and puts them to work — burn supply on the curve pre-grad, stack LP post-grad. The SOL traders pay you? Automated. No daily clicking. No custom contract.

You configure everything once with Phantom. After that, a background worker checks your token every five minutes and executes whenever the bull wallet holds enough SOL above its safety reserve — from claimed fees or your own top-ups — and the run is simulated to be worthwhile.

Architecture

Liquidity Bull does not deploy a custom smart contract for your token. It orchestrates official on-chain programs you already trust:

• Pump.fun — bonding curve, creator fee distribution / claiming, graduation
• Jupiter — SOL → token swaps after graduation
• PumpSwap — liquidity pool operations for graduated tokens

The platform has three main parts:

The dashboard refreshes its display every 30 seconds so you see updated claimable amounts and run history. That refresh is read-only — it does not send transactions. Only the worker executes on-chain actions.

The two wallets

Every automation uses two different Solana wallets. Confusing them is the most common source of mistakes (e.g. sending bootstrap SOL to Phantom instead of the automation wallet).

A) Dev wallet — your Phantom wallet

B) Automation wallet — platform hot wallet

Why two wallets?

Automation must run 24/7 without you approving every transaction in Phantom. At the same time, you should never paste your main wallet's private key into a website. The solution: a dedicated automation wallet per token that only handles that token's fee strategy.

How fees reach the automation wallet

By default, Pump.fun creator fees accrue to the creator (dev) wallet. During setup you sign one on-chain transaction in Phantom that routes 100% of creator fees to your automation wallet via Pump fee-sharing configuration.

Traders pay fees on Pump
        ↓
Fees accumulate (claimable)
        ↓
Worker distributes / claims → automation wallet receives SOL
        ↓
Pre-bonding: buyback + burn  |  Post-bonding: swap + add LP

Who can use this

Liquidity Bull is for you if:

• You launched a token on Pump.fun
• You are the creator / dev wallet for that token
• You want creator fees to automatically burn supply (pre-bonding) or grow liquidity (post-bonding)

You need:

• Phantom or a compatible Solana wallet
• Your token mint address
• A small one-time SOL deposit to the automation wallet (see SOL & funding)

Complete setup

1. 01

   Connect wallet

   Open the dashboard, click Connect wallet, choose Phantom, and sign the login message. This proves you control the dev wallet. No automation runs yet.

2. 02

   Add a token

   Click + Add token and provide:

   • Token mint address — from Pump.fun or Solscan
   • Symbol — e.g. BLIQ

   You do not choose pre- or post-bonding manually. Liquidity Bull reads the Pump bonding curve on-chain and shows Detected strategy(claim & burn vs claim & LP). You can also pick a token from From your Pump wallet if discovery finds your launches.

   Click Sign & activate and approve the activation message in Phantom. Behind the scenes:

   • An automation record is created for your token
   • A new automation wallet is generated and stored (encrypted)
   • Your Phantom address is linked as the creator (ownerWallet)
3. 03

   Complete fee routing (one-time, Phantom)

   Route 100% of creator fees to the automation wallet. Phantom may prompt you automatically, or click Complete Setup on your token card.

   When successful, status becomes Automation ready. If you skip this step, the worker cannot claim fees into the automation wallet.

4. 04

   Fund the automation wallet (one-time bootstrap)

   Send SOL to the automation wallet address shown on the token card — not your Phantom address.

   Purpose	Amount
   Safety reserve (never spent)	0.05 SOL
   Recommended bootstrap	0.15 SOL

   The first 0.05 SOL is a permanent safety reserve for network fees — the worker never spends below it. Everything above the reserve is put to work on the next cycle (burn or LP), together with claimed creator fees. So a 0.15 SOL bootstrap funds the reserve plus a first ~0.1 SOL deploy even before any fees arrive.

5. 05

   Let the worker run

   When all of the following are true, automation runs every five minutes:

   • Fee routing complete (Automation ready)
   • Automation wallet has bootstrap SOL
   • Automation state is ACTIVE
   • The platform worker is running (live mode for real transactions)

   You do not sign anything in Phantom for normal runs.

SOL & funding

Two sources of SOL in the automation wallet

The safety reserve (hard floor)

The worker keeps a fixed 0.05 SOL reserve in the automation wallet at all times. It exists so the wallet can always pay network fees. A run only executes when the wallet would stay above this reserve afterwards — otherwise the run is skipped with SOL hard floor reached until new fees arrive.

Everything above the reserve gets deployed

On each approved cycle the worker deploys the wallet's surplus — balance minus reserve minus estimated costs — into your strategy (burn pre-bonding, LP post-bonding). That includes SOL you top up manually: sending extra SOL to the automation wallet is a direct way to trigger a bigger burn or LP add on the next cycle.

Typical first-run timeline

1. You send 0.15 SOL to the automation wallet
2. 0.05 SOL stays as reserve; ~0.1 SOL is surplus
3. Worker claims any available creator fees on top
4. Preflight approves (surplus covers costs, reserve stays intact)
5. Buyback/burn or swap + LP executes with the surplus

After that the system is self-funding: claimed fees accumulate above the reserve and get deployed on following cycles. If fees are zero or tiny and there is no surplus, the worker skips and waits — the reserve is never drained.

Quick checklist

• Phantom connected (dev wallet)
• Token added and activation signed
• Detected strategy shown (pre or post-bonding)
• Fee routing complete — Automation ready
• ~0.15 SOL sent to automation wallet address (not Phantom)
• Automation state ACTIVE
• Worker running (live mode for real on-chain transactions)

When all boxes are checked, Liquidity Bull handles creator fees automatically — checking every five minutes, executing only when it makes sense.

Automation cycles

Worker cycle (on-chain) — scheduled checks

For each ACTIVE token, the worker runs this pipeline roughly every five minutes (configurable via WORKER_INTERVAL_MS, default 300000):

┌─────────────┐     ┌──────────────┐     ┌─────────────────────────┐
│  Detect     │ --> │  Preflight   │ --> │  Execute (if approved)  │
│  fees/state │     │  simulate $  │     │  claim → burn or LP     │
└─────────────┘     └──────────────┘     └─────────────────────────┘
                            │
                     SKIP if guardrails fail

On each cycle the worker:

1. Selects automations that are due (next_check_at in the past), up to a per-cycle cap
2. Checks claimable creator fees first (light RPC) before heavier balance / bonding-curve reads
3. Runs preflight — estimates gas, swap costs, slippage, and net profit
4. If approved: sends transactions (claim → strategy). If not: logs a clear wait/skip reason — no drain, no reckless execution
5. Writes the result to Run History (with Solscan links when txs land)

Reading Run History

Every cycle gets a plain-language entry with a status badge and, where useful, an explanation of what happened and what to do:

Dashboard refresh — every 30 seconds

The dashboard polls the API every 30 seconds to update claimable amounts, wallet balance, bonding progress, and run history. This is display-only. After actions like adding a token or completing setup, the dashboard also refreshes immediately. If a refresh fails (RPC hiccup, network), the dashboard shows a small notice and keeps retrying.

Pre-bonding vs post-bonding

When your token graduates, Liquidity Bull detects bondingCurve.complete on-chain, updates token_state to post-bonding, and switches strategy on the next worker cycles. You do not need to reconfigure manually.

While pre-bonding, the dashboard may show Bonding progress: X% — how far the curve is toward graduation.

Pre-bonding runs

When preflight approves a pre-bonding cycle, the worker executes in order:

1. Distribute / claim creator fees — SOL moves to the automation wallet (Pump fee-sharing v2 distribute or legacy claim, depending on your token)
2. Buy back your token — spends a portion of available SOL on the bonding curve (capped by maxSolPerRun and hard floor rules)
3. Burn purchased tokens — permanently removes them from supply

Priority fees may be attached to land transactions during congestion, capped by maxPriorityFeeLamports.

In Dry-run mode (operator testing), the worker simulates approval and logs what it would do without sending transactions.

Post-bonding runs

After graduation, each approved cycle:

1. Distribute / claim creator fees → automation wallet receives SOL
2. Swap SOL to your token via Jupiter (respecting maxSlippageBps)
3. Add liquidity to the canonical PumpSwap pool for your token

Swap fees and slippage buffers are included in preflight so the worker does not LP when the math does not work.

The LP deposit is sized by the tokens actually in the wallet after the swap — including leftovers from earlier cycles. If the amounts are too small to pair in a given cycle, the deposit is deferred: the tokens stay safely in the automation wallet and are added to the pool on a later cycle. Run History shows this as “Swapped — LP deposit postponed”.

Preflight & guardrails

Before every execution, Liquidity Bull simulates costs and compares them to configurable risk limits. Default values for new automations:

Preflight also budgets for:

• Base network fee and priority fee
• Swap fee (~0.3% of the deploy) and slippage buffer (~1%)
• Token-account creation and a retry buffer for transactions that fail to land

Common wait/skip messages you may see in Run History:

• Waiting: fees too small to act on — claimable fees have not reached the minimum yet; nothing was spent
• Waiting: wallet at SOL reserve — only the safety reserve is left; the worker acts again once new fees arrive or you top up
• Skipped: network fees above your cap — Solana is congested; retries automatically on later cycles

Circuit breaker

If several on-chain attempts fail in a row (not normal waits — actual failed transactions), the automation is paused automatically to protect your wallet. The dashboard shows the reason. Fix the cause — usually a lack of SOL — and click Resume. If the wallet is funded and ready, the worker overrides the breaker on its own and keeps going.

Smart polling & RPC protection

With many tokens, polling every mint every 5 minutes would waste RPC quota. Liquidity Bull uses a per-automation schedule instead of a fixed global interval.

1. Claimable-first

Each check reads claimable creator fees before token state, wallet balance, or bonding-curve data. If fees are below minClaimAmountSol, the run skips early with minimal RPC cost.

2. Tiered polling (hot → warm → cold)

After consecutive inactive skips (claimable below threshold, no execution), the next check is scheduled farther out:

A successful run resets the tier to hot. Preflight skips for other reasons (hard floor, net profit) do not advance the inactive counter as aggressively as “no fees yet” skips.

3. Inactive tokens are never stranded

Tokens without fee activity are not paused — they simply decay to the cold tier and keep getting a cheap check every few hours. As soon as fees return, a successful run snaps them back to the hot 5-minute schedule. No manual Resume needed.

Auto-stop only cleans up long-abandoned automations. It is reversible with Resume on the dashboard (which resets polling to hot).

4. Max checks per worker cycle

Each worker tick processes at most 100 due automations (operator-configurable). Remaining due tokens wait for the next tick — order is by oldest next_check_at first.

Dashboard reference

Per-token actions:

• Complete Setup — finish fee routing in Phantom
• Resume — set automation to ACTIVE
• Pause — temporarily stop worker runs
• Stop — stronger off switch (can resume later)

Pause, resume, and stop

Pause does not undo on-chain fee routing. It only stops the worker from executing new strategy transactions until you set the token back to ACTIVE. Resuming resets polling to the hot tier.

Security

• Phantom private key — never shared. You only sign a login message, activation message, and one-time fee-routing transaction.
• Automation wallet key — generated server-side, encrypted at rest with SIGNER_ENCRYPTION_KEY, used only by the worker for your token.
• Session auth — wallet signature + nonce; your dashboard only shows automations where you are ownerWallet.
• No Liquidity Bull contract — interactions are with Pump, Jupiter, and PumpSwap programs directly.

FAQ

Is the automation wallet my dev wallet?

No. Dev wallet = Phantom (identity). Automation wallet = separate hot wallet for automatic signing.

Do I give Liquidity Bull my Phantom private key?

No. Never. You only sign messages and setup transactions in Phantom.

Do I need to send SOL every day?

No. Only a small one-time bootstrap to the automation wallet. After that, claimed fees fund operations when profitable.

What if my token has no fees yet?

Any SOL above the 0.05 SOL safety reserve is deployed into your strategy — including your bootstrap. Once the wallet is down to the reserve, the worker simply waits for new fees; the reserve itself is never touched. If you want the automation to only ever spend claimed fees, bootstrap with just the reserve amount plus a little gas.

What if I already claimed or configured fees on Pump manually?

The first fee claim on pump.fun automatically migrates a token to Pump.fun's fee-sharing system. Tokens migrated to the old versionof that system (before mid-2025-era configs, "v1") are locked: their fee split can never be changed again, so it can't be re-routed to an automation wallet — not by you and not by us. Liquidity Bull detects this when you add the token and tells you right away. Such tokens can't be automated; you can still claim their fees manually on pump.fun. Tokens on the current version of the fee-sharing system are unaffected.

Does graduation change my strategy?

Yes, automatically. Pre-bonding burn switches to post-bonding LP when detected on-chain.

How often are fees actually claimed?

Hot-tier tokens are checked about every 5 minutes; inactive tokens slow to 30 minutes or 6 hours. The worker claims and executes only when preflight approves — not on every check.

Why did my automation pause itself?

Quiet tokens are not paused anymore — they just get checked less often. The only automatic pause is the circuit breaker: several failed on-chain attempts in a row (usually not enough SOL). Fix the cause, then click Resume — polling resets to hot.

Troubleshooting