Universal Bundled Sell: Coordinated Exits on Pump.fun

If you ran a bundled buy at launch, you already understand half of this post. The Jito-bundle primitive that protected your entry against searchers wedging in between your wallets does the exact same job in the exit direction. Same atomic group, same all-or-nothing settlement, same protection from external sandwich attempts. What you may not have thought about carefully is how the on-chain reader interprets a row of twenty wallets selling in the same block versus the same twenty wallets buying. The mechanic is symmetric. The optic is not. This post unpacks both sides.

Same mechanic, different optic

A Jito bundle is a list of transactions plus a tip, processed atomically by the validator. Either every transaction in the list lands, or none of them do. There is no way for a searcher to slot a transaction between wallet seven and wallet eight in your bundle. That property is what makes bundled execution worth the tip in the first place.

For a bundled sell, the primitive is identical. You submit an ordered list of sell instructions, signed by separate wallets, with a tip attached. The validator either lands all of them in one block or rejects the bundle. The pool moves in one direction (down) by the cumulative size of the sells, and no external actor can sandwich any single wallet inside the group.

The change shows up not in the mechanic but in the reading. A bundle of twenty buys in one block looks like coordinated accumulation, which the market sometimes welcomes (a team buying back, a treasury rotating in). A bundle of twenty sells in the same block reads as a coordinated exit, even when the twenty wallets belong to twenty different operators each taking profit independently. The on-chain feed does not know intent. It sees direction.

Three differences between bundled buy and bundled sell

The mechanic is symmetric. The downstream behavior is not. Three things invert when you flip the direction.

Price impact runs against you in series. In a bundled buy, the first wallet fills at the best price and the last wallet pays the worst. In a bundled sell, the first wallet sells into the deepest part of the curve and the last wallet sells into a shallower, already-impacted pool. Ordering matters in both cases. The cost asymmetry just runs the opposite way.

Liquidity drains rather than fills. A bundled buy adds SOL to the pool side, deepening one leg of the pair. A bundled sell removes SOL from the pool, leaving the post-bundle pool thinner than before. The next buyer faces a wider spread. This is the worst part of the optic, because a thinner pool is visible to anyone scanning the pair.

The optic flips from welcome to suspect. A coordinated buy gets framed as conviction. A coordinated sell gets framed as fleeing. The mechanic neither knows nor cares which it is. Anyone reading the on-chain tape after the fact does care, and they will read the second one harder than the first.

A bundled sell that takes a meaningful slice of pool depth in one block drains liquidity instantly. The next buyer faces a wider spread, the pair looks thinner on every scanner, and the visual reads as a dump even when the intent was disciplined profit-taking. Plan the size against pool depth, not against ego.

When bundled sell is the right call

Three operator cases earn the bundled-sell primitive. Anything else probably belongs in a different tool.

Coordinated take-profit at a target. A team that ran a bundled buy at launch and now wants to exit those same launch wallets at a coordinated profit level. The exit is symmetric to the entry. The team has already chosen to act as one group on the entry, so acting as one group on the exit is consistent. The optic is still loud, but the framing matches.

Treasury unwind on a published policy. A project DAO votes to liquidate a portion of a treasury position at a stated trigger. The operator wants to execute the vote cleanly, in one block, without printing a long single-wallet sell tape that invites front-running over the next ten minutes. The vote is the comms; the bundle is the execution.

Session-end wallet retirement. A sniper or farming operator running a multi-wallet position at the end of a session wants to unwind all of them atomically. Spreading the exit over time means each later wallet gets a worse price and exposes the operator to sandwich attempts. Atomic ordering closes both holes at once.

Alternative: multi-swap with delay

The alternative when you want the same outcome with a different visual is multi-swap with a delay between transactions. The delayBetweenTx setting spreads the same set of sells across many blocks, five to fifteen seconds apart. Each wallet reads as independent to a casual observer. The trade-off has two parts.

First, the price drifts down between wallet one and wallet two hundred. The last wallet fills at whatever the pool gives it after every earlier wallet has already sold. Second, the gap between wallets opens a window for external searchers to take a bite. Atomic ordering is gone.

This is the choice operators have to make explicitly.

Approach	Atomicity	Market optic	Sandwich exposure	Cost profile
Bundled sell in one block	All-or-nothing in a single block	Reads as coordinated exit	Zero external sandwich risk	0.05 SOL flat plus Jito tip
Multi-swap with delay	Independent across many blocks	Reads as scattered organic sells	Open window between wallets	0.0035 SOL per transaction, no tip
Single-wallet sequential sells	One transaction at a time	Reads as a long single-wallet tape	Highest sandwich exposure	Network fees only

If the operator group can defend the coordination publicly, pick the bundle. If the goal is to hide that the wallets belong to the same operator, pick multi-swap with a delay. Picking both for the same position is incoherent.

Step by step on j.tools

The bundled sell tool is currently on the coming-soon list; the flow below describes the steps you will run when it ships. The bundled buy tool is the buy-side mirror of the same Jito primitive and is already live.

The flow mirrors the bundled buy flow with the direction reversed.

1. Load the wallet list. Each wallet must hold a balance of the target token and enough SOL to cover its own transaction fee.
2. Set the token mint address. The same mint applies to every wallet in the bundle.
3. Set per-wallet sell amounts. Mixed sizes are allowed; some wallets can sell fifty percent of their balance while others sell everything.
4. Set the slippage cap. Two percent is a reasonable starting point for a deep pool; thinner pools need a wider cap or the bundle reverts at the last wallet.
5. Set the Jito tip. Higher tip means the bundle is more likely to land in the next block. Read the current tip floor before submitting.
6. Submit. The validator either lands all sells in one block or rejects the whole bundle.

The conceptual shape of the call looks like this:

// Conceptual: bundled sell across N operator wallets in one block
const bundle = {
  transactions: walletList.map((wallet) => ({
    signer: wallet.keypair,
    instruction: sellInstruction({
      mint: tokenMint,
      amount: wallet.tokenAmount,
      slippageBps: 200,  // 2% cap per wallet
    }),
  })),
  tip: 0.001 * LAMPORTS_PER_SOL,
};

await jitoClient.sendBundle(bundle);
// All sells either succeed atomically or all revert.
// No searcher can wedge between the wallets.

For a position that mixes buys and sells in the same atomic group (closing one position while opening another), the upstream primitive is the universal bundled trade tool. That one is out of scope for most readers, but worth knowing it exists.

Post-exit cleanup

After the bundle lands, each wallet holds SOL from the sale plus, in some cases, a small dust balance of the token. The cleanup chain is short.

Consolidate the SOL into one operator wallet with the batch collector tool. That sweeps proceeds from every wallet in one pass and saves the cost of running two hundred individual transfer transactions. Close the empty token accounts with the close account tool to reclaim the rent SOL locked inside each ATA. Two hundred closed accounts recover meaningful SOL. Verify the final balances on-chain with the token snapshot tool against the operator wallet list before declaring the position closed.

The full chain looks like: bundled sell, then the batch collector step, then the close account pass, then the token snapshot check. Each step removes work the operator would otherwise do manually.

Failure modes

Three things make a bundled sell fail or land badly.

Tip too low. The validator drops the bundle. None of the sells execute. The pool moves against the operator while they retry, and the second attempt fills at worse prices. A reasonable tip floor for a busy block is higher than a quiet block; check before submitting, not after.

Pool depth too shallow for the bundle size. The last wallets in the bundle hit a pool that has already been drained by the earlier wallets. They fill at extreme prices or revert against the slippage cap. If they revert, the whole bundle reverts. Sizing the bundle against pool depth is the operator's job, and the math is not optional.

Slippage cap too tight. Identical to the bundled buy failure mode. One wallet's actual slippage exceeds the cap, the wallet reverts, the bundle reverts. Picking 200 bps on a pool that needs 400 bps wastes the tip and shows up as nothing happened.

Publish the exit policy before the bundle lands. A team that has stated "we will exit treasury position X at price Y" and then runs a coordinated sell at Y reads as disciplined. A team that goes quiet for a week and then prints a bundle of two hundred sells reads as fleeing. The on-chain mechanic is the same. The framing is operator-side comms.

The optics question, coordinated or dump?

Bundled sell is a clean execution primitive with a loud on-chain signature. That is the whole tension of the tool. The mechanic protects the operator from external sandwich. The optic exposes the operator to community reading. There is no way to have both.

What an operator can control is the framing that surrounds the execution. A bundle that follows a public policy reads one way. A bundle that arrives out of nowhere reads the other way. The execution code is the same. The chain does not know which one it is rendering.

Before pressing the submit button, the question to answer is not "can I do this cleanly", the bundle takes care of cleanly. The question is "has the audience been told this was coming." If yes, run it. If no, either run it anyway and own the optic, or move to the delay-based alternative and accept the drift cost. Read more launch and exit walkthroughs in the guides category, or browse the rest of the Solana-tagged operator posts.