Bundler

The Bundler buys an existing token from a list of wallets in one go. Same machinery as a launch's buy leg, without creating anything. It is also how you add to a position you already hold.

Picking the venue and the token

Pick where the token trades, then paste its address. The venues are the chain's own, each carrying its launchpad's mark:

A venue refuses a token that is in the wrong phase and names the right one, rather than quietly buying somewhere else. See Venues for how the console tells them apart.

A pair against another token

What this console calls a pair is always token-against-the-coin, because every buy here spends the coin. A token whose real market is a pair with another token has no first-party path, and the Bundler used to refuse it outright: "there is nothing here to buy", about a token that trades perfectly well.

It is routed now. The aggregator hops straight through such a pair, and the planner asks it before concluding there is nothing. Measured on a token reported from the field, whose only market is a Uniswap V2 pair against a tokenised NVIDIA holding 68.8M of it against 144.6 NVDA: three wallets bought it with the chain's coin alone, and a round trip through the two hops kept 97.2%.

The same applies to a token whose only liquidity is an ordinary V3 pool. A deep pair against the coin is still taken first hand, because routing cannot beat the venue it would route into.

The two pool venues on Robinhood Chain are genuinely different places, which is why they are two cards. A PONS token graduates into a Uniswap V4 pool; a Flap token graduates into a plain Uniswap V2 pair, and so does anything from Create Token. Pointing one at the other quotes the wrong pool, or nothing at all, so each card looks for its own and says so when it does not find it.

What a curve venue reads first

Curve venues read the token before pricing anything, because a token that has traded is not the same as a fresh one:

• four.meme. The curve constants are read off the token itself, and the opening reserve is worked back from what has already been raised. A token whose launch time is in the future is refused with that time. Tokens on the older manager, and tokens raising something other than the chain's coin, are refused.
• Flap. The curve, the protocol fee, the buy tax and any per-address buy cap are read from the Portal. The tax is priced into every wallet's minimum. If a wallet would exceed the cap, the log says so and warns that the excess comes back as a refund rather than as tokens.
• Genius. Two things, and both can stop the run before it spends anything. How much the curve has really raised, so the plan is clipped at the 15 BNB graduation threshold instead of sending the wallets behind the line into a buy that reverts. And whether the token is still inside its launch tax window, which only the wallets named when it was created are exempt from: a buy in there keeps about 1% of what it spends, so it is refused with the seconds left on it rather than sent. Curves raising something other than the chain's coin are refused.
• Faze. Three things, and any of them can stop the run before it spends anything. How much the raise has taken, so the plan stops where the curve fills rather than sending wallets into a buy that reverts, and it stops at exactly the figure the contract itself would clip to. Whether the curve has been opened: a launch can name one wallet that must make the first buy, and until that lands the curve refuses everyone else. And whether the coin is still inside its launch tax window, which only the wallets named at creation are exempt from: a buy there keeps about 1% of what it spends, so it is refused with the seconds left on it rather than sent. That window is three seconds, which on a half second chain is a handful of blocks. A curve raising the launchpad's own token rather than the chain's coin is not refused: each wallet swaps for it through Faze's own pool first, which costs two extra transactions.
• OneMeme. The Core's own state, refusing anything past the migration threshold.

Sizing

Either a total in the chain's coin split across wallets, or a target percentage of supply. As with a launch, wallets are priced in sequence: each buy moves the price for the next, so a plan that quoted every wallet at the opening price would have the last ones fail their own minimum.

Distribution is equal or naturally jittered. Slippage applies per wallet.

Simulate

Simulate prices the plan without sending anything, on every venue except Launchpad. On a curve it uses the same planner the run does, walking the curve forward wallet by wallet, so the table it shows is what the bundle will carry.

Buying in one transaction, where there is no bundle market

On Robinhood Chain the buys normally go out together but land in whatever order the sequencer gives them, because nothing there sells ordering. For the two venues a contract can reach, the console offers the same trick the launch uses: name a wallet under Pays for the buys, and the whole set goes out as one transaction that fills every wallet at once.

Leave the field empty and each wallet buys for itself, exactly as before.

A graduated PONS token is the one case this cannot cover. It lives in a Uniswap V4 pool whose route is built off chain by an aggregator, and the only way to put that in a contract is to let the contract execute calldata handed to it, which is a much worse thing to have than the convenience is worth. Those buys go out together, unatomically, and the panel says so.

Atomic or not

Where a bundle market exists the whole set lands in one block. Where it does not, the buys go out together and land in whatever order the chain gives them, which for a token that is already trading is usually fine: there is no create transaction to front-run.

What you get

A position, exactly like a launch's. Holdings per wallet, a cost basis, and a sell path in Tokens. Run the Bundler again on the same token with the same wallets and the new buys are recorded against the same token page.