How it works

Fresh wallets, every launch

Each launch generates its own wallets and never reuses them:

The dev wallet — creates the token and makes the first buy.
Buy wallets — between 9 and 19 of them, each buying a randomised amount so the buys do not look like a row of identical orders.

Every private key is encrypted before storage. Keys exist in plaintext only inside the running process, for as long as it takes to sign.

One transfer, not N

All wallets are funded in a single batched transaction. Sending one transfer per wallet costs a fee each time and is the fastest way to hit a public RPC's rate limit; batching pays one fee and makes one request.

The create and the dev buy are one transaction

This is the part that matters most. The dev buy is not a second transaction sent after the create — it is an instruction inside the create transaction itself. The two either land together or not at all.

Because they are atomic, nothing can be inserted between them. No bot can see the token appear and buy ahead of the dev wallet, because at the moment the token exists the dev buy has already executed in the same transaction. This holds however the transaction reaches the chain — it is a property of the transaction, not of winning an auction.

What it does not prevent is a sniper buying in the same slot, just behind you. The create is broadcast through the public RPC path, where anyone running a node can see it before inclusion. This has been observed: on one launch a sniper took 3.4% of supply in the create's own slot, paying no Jito tip at all — just a higher priority fee. Your dev buy was still first; theirs was second, near the bottom of the curve.

The buy wallets ride the same bundle

The buy wallets are submitted in the same Jito bundle as the create. A bundle is atomic and lands in a single slot. Jito caps a bundle at 5 transactions, and PumpRug packs 3 buys into each transaction:

1 tx  (create + dev buy)
4 txs × 3 buys        = 12 buy wallets
                      ─────────────────
                        13 wallets in one slot

So up to 13 wallets can be in the protected group, and any wallet past that is bought normally afterwards.

In practice the bundle often does not land. Jito bundles are an auction, not a guarantee. When a bundle is not selected, PumpRug falls back to sending each buy individually through the public RPC — one per slot — which is exactly the path snipers watch. Measured on real launches: of three launches carrying a slot measurement, one landed fully atomic (slotSpread 0) and two had their buys spread over 8 and 10 slots — roughly 3–4 seconds — despite using only 10 wallets, well inside the 13-wallet capacity. Do not assume your buy wallets will share the create's slot; read the measurement each launch reports.

It is measured, not assumed

After the buys settle, PumpRug reads the chain and records what actually happened on the launch:

Field	Meaning
`atomic`	true when every landed buy shared the create's slot
`slotSpread`	slots between the create and the last landed buy; 0 means all together
`coreSlot`	the slot the create landed in

These are reported in the live log after each launch, so you can see whether your bundle held together instead of taking it on trust.

Token metadata and IPFS

pump.fun retired its own image-hosting endpoint, so metadata must be pinned yourself. PumpRug uploads your image and metadata JSON to IPFS through Pinata and passes the resulting URI to the token creation call. A Pinata JWT is therefore required for launching, and pre-flight checks it.