> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gank.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# bundles

> atomic and delayed bundle buys

# bundles

bundle wallets buy in the same jito bundle as token creation. block 0 buys are atomic — they land in the exact same slot as the token. nobody can frontrun them because the token doesn't exist until that block.

## how it works

jito bundles are atomic multi-transaction packages. all transactions in a bundle either succeed together or fail together, in the same block. gank uses this to pack token creation + dev buy + bundle buys into a single bundle.

```
jito bundle (block 0):
  tx 1: create token
  tx 2: dev buy
  tx 3: bundle wallet 1 buy
  tx 4: bundle wallet 2 buy
  tx 5: bundle wallet 3 buy
  ...
```

all of these land in the same slot. from the chain's perspective, these are independent transactions that just happen to be in the same block.

## atomic vs delayed

### block 0 (atomic)

the default. bundle buys land in the same block as token creation. guaranteed same slot via jito.

* **max 4 wallets per bundle** (jito transaction limit)
* guaranteed same block as creation
* nobody can frontrun — token doesn't exist until this block

### delayed waves (block 1, 2, 3...)

configure bundle groups to target later blocks. the system waits until the target block, then submits a new jito bundle.

why use delayed waves:

* **avoid detection** — 10 buys all in block 0 looks coordinated. spreading across blocks 0, 1, 2 looks organic.
* **more wallets** — 4 wallet jito limit per bundle, but you can have multiple waves
* **price impact** — stagger your buys to build momentum instead of one spike

### multi-wave example

```
wave 1 (block 0):  wallets A, B, C, D    — atomic with creation
wave 2 (block 1):  wallets E, F, G, H    — fires at block 1
wave 3 (block 2):  wallets I, J, K, L    — fires at block 2
```

each wave is its own jito bundle. block targeting uses slot-relative positioning — the system polls the rpc for the current slot and waits until `create_slot + block_target` before submitting.

## configuration

set up in the launch modal under "bundle wallets":

| param             | what                                 |
| ----------------- | ------------------------------------ |
| **wallet**        | must be `bundle` type                |
| **amount\_sol**   | sol per wallet                       |
| **block\_target** | 0 = atomic with create, 1+ = delayed |

group wallets by block target to create waves.

## prefunding

bundle wallets are automatically prefunded from the dev wallet before launch. the system checks existing balances and only sends the shortfall — if a wallet already has enough sol, it's skipped.

each wallet needs its buy amount + a small gas reserve (\~0.003 sol).

## after launch

bundle wallets hold tokens after buying. you can:

* let them hold and sell later from the positions panel
* [vamp](/platform/vamp-recovery) to sell everything and recover sol
* [consolidate](/platform/consolidate) to pull sol back without selling

## tips

* use 2-4 wallets in block 0 for guaranteed atomic buys
* add delayed waves at block 1 and 2 if you want more coverage
* vary the buy amounts across wallets — identical amounts look coordinated
* increase jito tip during high network congestion