Files
pumpfun-bonkfun-bot_github/README.md
T
13b9ec2baf fix(monitoring,core): keep detecting tokens after the Solana transaction v1 cutover (#212)
* fix(monitoring,core): keep detecting tokens after the Solana transaction v1 cutover

Solana transaction v1 (SIMD-0296/0385) went live at epoch 1035 on 2026-09-15.
`maxSupportedTransactionVersion` turns out to be a whole-frame setting, not a
per-transaction filter: asking blockSubscribe for 0 does not skip the v1
transactions in a block, it nulls out `value.block` for the entire
notification, which reads as a skipped slot. Measured against mainnet
2026-09-16, 60s per run on the pump program: 0 delivered 1 block and 177
nulls, 1 delivered 78 blocks and no nulls.

solders 0.26 cannot deserialize a v1 envelope either, but it does not need to.
The RPC has already decoded it by the time `meta.logMessages` is emitted, and
the platform parsers prefer the CreateEvent in those logs anyway, for the
canonical creator. What broke was the dispatch: _process_block_transactions
decoded the bytes first only to learn which program a transaction touched, and
swallowed the failure in a bare `except Exception: pass`. It now tries
_parse_from_logs on every transaction first and keeps the byte decode as a
fallback, so v1 coins arrive with state_from_event=True and extreme_fast_mode
keeps its zero-RPC contract.

Also raises every other reader to v1, fixes the null-block crash in
listen_blocksubscribe.py, and records that PumpPortal does not push coins
created in a v1 transaction — 0 of 6 measured, against near-complete v0
coverage. That one is upstream and not fixable here.

Closes #197

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013LDiKnRFW49m3T1rKYiz98

* fix(examples): survive a v1 envelope and a null block per notification

Raising maxSupportedTransactionVersion to 1 means these examples now receive
the v1 transactions the RPC used to withhold, and solders 0.26 cannot decode
one. manual_buy.py had no handler at all around from_bytes, so the first v1
transaction in a block would have ended listen_for_create_transaction outright
— a regression introduced by the version bump itself.

Guards the null `value.block` in the same three places while here: the key is
present and the value is not for a skipped slot, so the membership test raises
TypeError and costs the whole notification. Same root cause as #196.

Found by CodeRabbit on #212.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013LDiKnRFW49m3T1rKYiz98

* fix(examples): raise the shared confirm helper to v1 and decode create_v2's OptionU64

Two gaps the first pass missed, both found by running the changed code against
mainnet instead of only exercising it offline.

tx_status.py confirmed through solana-py's snake_case
`max_supported_transaction_version=0`, a spelling the source scan in
verify_transaction_v1.py did not know about — so the sweep reported clean while
the helper every example confirms through still rejected v1. Verified live: at 0
it raises UnsupportedTransactionVersionMessage on a v1 signature, at 1 it reads
meta.err. The scan now covers both spellings, and setting the threshold above 1
makes it name all seven call sites, so the check is not vacuous.

listen_blocksubscribe.py then turned out to have a third cause behind #197 that
no offline check could reach, because until this branch the example never
received a block to decode: its local create_v2 decoder raises on OptionU64,
the arg added by the 2026-09-15 program upgrade. Live before the fix, 90s: 0
creates decoded, 8 tracebacks. After: 58 creates, 0 tracebacks. Trailing option
args are reported unset rather than as a fabricated default, matching
utils/idl_parser.py and the three wire forms that are live on chain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013LDiKnRFW49m3T1rKYiz98

* fix(examples): decode create_v2's trailing optional args in manual_buy

Found by running the script against mainnet with real funds. It crashed before
it could buy:

    File "learning-examples/manual_buy.py", line 316, in decode_create_instruction
        value = bool(ix_data[offset])
    IndexError: index out of range

decode_create_instruction treated every `defined` arg as a 1-byte OptionBool and
read it unconditionally. create_v2's trailing args are positional and legally
absent from the wire, and the 2026-09-15 upgrade added creator_fee_bps as an
8-byte OptionU64, so the fixed read walks off the end on the shorter forms —
which is most coins. Same defect class as the OptionU64 crash in
listen_blocksubscribe.py, and invisible until this branch let either script
receive a block at all.

Absent trailing options are now reported as None, meaning unset, matching
utils/idl_parser.py. Verified live: the script decodes a create with
creator_fee_bps and is_holder_reward both null, then buys 69,387 tokens for
0.003 SOL, confirmed on-chain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013LDiKnRFW49m3T1rKYiz98

* refactor(examples): drop one v1 fixture and trim the other

Two fixtures was one too many. The v0 one was captured to prove the byte-decode
path still works, but it never did: the listener routes on logs first, so the
fixture was caught there and the check passed without exercising what its name
claimed. Feeding it through with the logs stripped shows the byte fallback does
not parse a v0 create_v2 either — the parser's own logs-first branch was always
doing the detection. So the check now reuses the create fixture already
committed for verify_create_v2_optional_args.

The v1 fixture stays, because a v1 transaction cannot be synthesized locally —
solders 0.26 cannot build one — and every verifier here runs offline. Trimmed
from 30KB to 13KB by dropping what nothing reads: innerInstructions, token
balances and pre/post balances. What is left is the envelope, the version and
the logs the listener parses.

Adds the check that was missing: strip the logs and the v1 create must vanish.
That is what makes the log route load-bearing rather than decorative, and it
will start failing the day solders learns to decode a v1 envelope, which is
exactly when the routing could be simplified again.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013LDiKnRFW49m3T1rKYiz98

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 08:27:30 +02:00

13 KiB
Raw Blame History

Labs

Chainstack is the leading suite of services connecting developers with Web3 infrastructure

• Homepage • Supported protocols • Chainstack blog • Blockchain API reference •
• Start for free •

A Solana trading bot for pump.fun and letsbonk.fun. Its core feature is sniping new tokens: it watches for token creation, buys, and exits on a strategy you configure. learning-examples/ contains standalone scripts covering every piece of the flow — listeners, price math, manual buys and sells — useful on their own even if you never run the bot.

For the full walkthrough, see Solana: Creating a trading and sniping pump.fun bot. It explains the concepts well but lags behind the code, so treat this README as the source of truth for setup and configuration.

Also by Chainstack — if you prefer a terminal interface or want to give an AI agent trading capabilities:

  • pumpfun-cli — CLI for trading, launching, and managing tokens on pump.fun; buy, sell, wallet management, and smart routing between the bonding curve and PumpSwap AMM.
  • pumpclaw — agent skill that equips AI assistants (OpenClaw, Claude Code, Cursor, Codex) with the ability to operate pumpfun-cli.

🚨 SCAM ALERT: The Issues section is regularly targeted by scam bots that try to redirect you to an external site and drain your funds. A GitHub Action tags the common patterns, which is not 100% accurate. Deleted comments in issues are scam bots after your private keys — genuine outside devs are welcome and appreciated.

⚠️ NOT FOR PRODUCTION: This code is for learning purposes only. We assume no responsibility for the code or its usage. Modify it for your needs and learn from it — the examples, issues, and PRs contain valuable insights.


Getting started

1. Prerequisites

Install uv, a fast Python package manager. The project needs Python 3.11+; uv uses an existing install if it's new enough, otherwise it fetches one for you.

2. Clone and install

git clone https://github.com/chainstacklabs/pumpfun-bonkfun-bot.git
cd pumpfun-bonkfun-bot

uv sync                        # create .venv and install dependencies
source .venv/bin/activate      # Unix/macOS — Windows: .venv\Scripts\activate
uv pip install -e .            # install the bot as an editable package

3. Set your credentials

cp .env.example .env

Fill in .env:

Variable Purpose
SOLANA_NODE_RPC_ENDPOINT HTTPS RPC endpoint
SOLANA_NODE_WSS_ENDPOINT WebSocket endpoint (for logs / blocks listeners)
SOLANA_PRIVATE_KEY Base58 private key of the trading wallet
GEYSER_ENDPOINT, GEYSER_API_TOKEN, GEYSER_AUTH_TYPE Only for the geyser listener

Public RPC nodes will not work for this workload — see throughput below.

4. Configure a bot

Each YAML file in bots/ is one bot instance. They ship with commented defaults; start from the one matching the listener you want:

File Listener Ships with
bot-sniper-1-geyser.yaml geyser — fastest, needs a Geyser endpoint pump_fun
bot-sniper-2-logs.yaml logs — logsSubscribe, supported everywhere pump_fun
bot-sniper-3-blocks.yaml blocks — blockSubscribe, not supported by every provider pump_fun
bot-sniper-4-pp.yaml pumpportal — third-party aggregator, misses some coins lets_bonk

Set platform: "pump_fun" or platform: "lets_bonk". pump.fun supports all four listeners; letsbonk.fun supports blocks, geyser, and pumpportal but not logs. The bot validates the pairing at startup and refuses to run an invalid one.

pumpportal is a third-party feed and only reports what it indexes. As of 2026-09-16 it does not push coins whose creation landed in a Solana transaction v1 (a format live since 2026-09-15), so it sees a sample rather than everything. geyser and logs read the chain directly and are unaffected; blocks needs maxSupportedTransactionVersion: 1, which it now sends.

Set enabled: false to keep a config around without running it. Every bot with enabled: true starts when you run the bot.

5. Run

pump_bot                   # as an installed package
uv run src/bot_runner.py   # or directly

Logs land in logs/{bot_name}_{timestamp}.log.

Configuration reference

The YAML files are commented inline. The sections that matter most:

  • trade — buy_amount (in SOL), slippage, exit_strategy (time_based, tp_sl, manual), and extreme_fast_mode, which skips the bonding-curve price check and buys a fixed token amount instead. Faster, less precise. See Extreme fast mode for the zero-RPC behavior and its two knobs, trust_create_event and curve_refresh_budget.
  • priority_fees — fixed or dynamic. Dynamic costs an extra RPC call, which slows the buy.
  • filters — listener_type, max_token_age, name/creator matching, marry_mode (buy only, never sell), yolo_mode (trade continuously).
  • retries — attempts and the wait windows around creation, buy, and the next token.
  • cleanup — when to close leftover token accounts: disabled, on_fail, after_sell, post_session.
  • node.max_rps — cap requests per second to match your provider's plan.

Extreme fast mode: zero-RPC buys

With extreme_fast_mode: true the bot buys a fixed token amount (extreme_fast_token_amount) instead of fetching the curve price first. For tokens detected through the on-chain CreateEvent — the geyser, logs and blocks listeners — the buy is built entirely from the event: the canonical creator, mayhem/cashback flags and quote mint are all in it, so no RPC call happens between detecting the token and submitting the buy. That is the point of the mode; a single account read costs ~40–50 ms even on a good endpoint, a tenth of a slot.

The pumpportal listener can't do this — its payload carries none of those fields — so it performs one batched account read (bonding curve + mint in a single slot-consistent getMultipleAccounts) before buying. If the curve isn't readable within trade.curve_refresh_budget seconds (default 2.0), the token is skipped: a buy built from guessed accounts reverts on-chain with NotAuthorized (6000) or ConstraintSeeds (2006) and still costs the fee. The same skip applies to any token whose event data was incomplete.

trade.trust_create_event: false turns the zero-RPC path off and forces the pre-buy read for every listener — the safe fallback if pump.fun changes what the CreateEvent carries.

Machine checks: learning-examples/verify_extreme_fast_zero_rpc.py (the zero-RPC contract per listener) and learning-examples/verify_pumpportal_buy_path.py (the refresh/skip path). Neither moves funds.

Non-SOL quote assets

pump.fun supports quote assets other than SOL, USDC first. Amounts are in that mint's own whole units, so usdc: 1.0 is one USDC and is not comparable to buy_amount:

trade:
  buy_amount: 0.0001    # SOL-paired coins
  quote_amounts:
    usdc: 1.0           # USDC-paired coins

filters:
  allowed_quote_mints: ["sol", "usdc"]   # omit to allow any configured quote

Keys accept the aliases sol / wsol / usdc or a raw base58 mint. A coin whose quote mint has no configured amount is skipped with a log line rather than bought with a wrongly-scaled amount. SOL always falls back to buy_amount, so existing configs keep working untouched. Buying a USDC-paired coin needs USDC in the wallet plus a little SOL for fees and ATA rent.

Learning examples

Standalone scripts, runnable with uv run <path>. No bot config needed — they read .env directly.

Path What it covers
listen-new-tokens/ One listener per method (logs, blocks, geyser, pumpportal) plus compare_listeners.py to race them
listen-migrations/ Detect a token graduating from the bonding curve to PumpSwap, via the migration wrapper program or new pool accounts
bonding-curve-progress/ Curve state, progress polling, and a live watch for coins close to graduating — over WebSocket (get_graduating_tokens.py) or Geyser (get_graduating_tokens_geyser.py), both taking --min-progress
pumpswap/ Manual buy/sell against the PumpSwap AMM, and pool discovery
letsbonk-buy-sell/ Manual exact-in / exact-out buys and sells on letsbonk.fun
copy-trading/ Watch another wallet's transactions
manual_buy.py, manual_sell.py, fetch_price.py The minimal pump.fun trade and price path. manual_buy.py --cu-optimized adds a SetLoadedAccountsDataSizeLimit instruction
mint_and_buy_v2.py Create a coin and buy it in one go
decode_from_*.py, calculate_discriminator.py Decoding account data, transactions, and Anchor discriminators
cleanup_accounts.py Close leftover empty token accounts

Most of these take the mint or curve address as the first argument, and print usage if you leave it off. The decode_from_*.py scripts fall back to the saved fixtures beside them (raw_*.json), which are recaptured from mainnet rather than hand-edited — a stale fixture makes a working decoder look broken and a broken one look fine.

Four examples double as verification scripts to run after any pump.fun program upgrade:

uv run learning-examples/verify_v2_account_layout.py     # offline: account layouts, PDAs, encoding
uv run learning-examples/verify_curve_account_sizes.py   # offline: 125/151/256-byte curves all decode
uv run learning-examples/simulate_v2_trades.py <MINT>    # mainnet simulation, no funds moved
uv run learning-examples/verify_tx_status_checks.py      # offline: every example checks meta.err

Related docs: Listening to pump.fun migrations · Sniping with only logsSubscribe

Throughput and rate limits

Every node provider has its own limits — method availability, requests per second, plan-specific caps. Consult your provider's docs before running the bot, and don't expect public RPC nodes to hold up.

One case worth knowing about: getProgramAccounts over the whole pump.fun program is no longer served by anyone. That program owns more than 10 million accounts, so providers reject the request or time out no matter which filters you pass. Use a filtered subscription instead — bonding-curve-progress/get_graduating_tokens.py shows the pattern.

For Chainstack, the numbers you need are in the throughput guidelines, kept up to date.

The bot rate-limits itself with a token bucket: node.max_rps in the YAML (25 by default) smooths the request rate while allowing short bursts, and 429s are retried with exponential backoff.

For faster execution, Chainstack offers Solana Trader nodes for transaction propagation and the Yellowstone gRPC Geyser plugin for streaming updates.

IDLs

The IDLs under idl/ are vendored from pump-fun/pump-public-docs — currently upstream commit 8109141. To refresh, copy pump.json, pump_amm.json, and pump_fees.json into pump_fun_idl.json, pump_swap_idl.json, and pump_fees.json, and note the upstream commit in your commit message. Don't hand-edit them.

The buy_v2 / sell_v2 account lists are complete in the IDL — that's the point of the v2 interface. The legacy buy / sell lists are not: the IDL omits PDAs the on-chain program requires. For anything outside v2, cross-check against a recent successful on-chain transaction before trusting the IDL.

CLAUDE.md documents the protocol gotchas in detail — account layouts, quote-mint handling, fee recipients, and what the IDL gets wrong.

Contributing

Maintainers are listed in MAINTAINERS.md. Open an Issue for feedback or bugs.

Lint and format the files you changed (uv sync installs ruff for you):

uv run ruff check --fix path/to/changed.py
uv run ruff format path/to/changed.py

Running ruff check over the whole repo reports a large backlog of pre-existing errors — that's a known baseline, so scope it to your own files.

Then test your change with a learning example rather than by running a bot with real funds.