Laser Bundle

POST /v1/laser/bundle

Laser Bundle builds, signs, and submits a Jito bundle from SolanaLaser-managed wallets. The main launch flow is:

Wallet A creates a Pump token.
Wallet A can make an initial developer buy inside the create transaction.
Wallet B, Wallet C, or Wallet D can buy the newly created token in the same bundle.

The transactions are sent to Jito as one ordered bundle. Jito bundles are designed for sequential, atomic execution: transactions execute in order, and the bundle either lands as a unit or does not land.

SolanaLaser never accepts private keys or pre-signed transactions here. It resolves each wallet from your API key's managed-wallet store, decrypts only while signing, serializes the signed transactions, submits them to Jito sendBundle, and optionally checks Jito bundle status.

What This Endpoint Is For

Use Laser Bundle when transaction order matters and partial execution would be bad.

The important case is token launch bundling. A normal sequence of separate HTTP requests can create a token first and buy later, but other transactions can land between those requests. A bundle packages create and the first buys together.

For existing tokens, SolanaLaser currently supports only one buy or sell leg per bundle. Multi-wallet buying is supported after a create leg because the server can maintain a fresh bonding-curve preview for the newly created token and quote each buyer in bundle order.

Request

const response = await fetch("https://api.solanalaser.xyz/v1/laser/bundle", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-api-key": "sl_your_key",
  },
  body: JSON.stringify({
    jitoTip: "0.01",
    confirm: true,
    accounts: [
      {
        wallet: "CREATOR_WALLET_PUBLIC_KEY",
        type: "create",
        name: "Laser Cat",
        symbol: "LASER",
        uri: "ipfs://YOUR_METADATA_CID",
        initial_buy: "0.05",
        slippage: 5,
      },
      {
        wallet: "BUYER_WALLET_PUBLIC_KEY",
        type: "buy",
        amount: "0.10",
        denominatedInSol: true,
        slippageBps: 500,
      },
    ],
  }),
});

const bundle = await response.json();

Top-Level Fields

Field	Type	Required	Meaning
`accounts`	array	Yes	Ordered bundle legs. SolanaLaser accepts 1 to 4 legs.
`mint`	string	Conditional	Required for existing-token buy or sell bundles. Omit it when the bundle starts with `create`.
`jitoTip`	number or string	Yes	SOL amount paid as the Jito tip. Must be at least `0.000001` SOL.
`confirm`	boolean	No	Defaults to `true`. If `true`, SolanaLaser checks Jito bundle status for up to about 30 seconds.

Bundle Legs

Each item in accounts is one transaction in the Jito bundle. Transactions are built and signed in the same order as the array.

Every leg accepts:

Field	Type	Required	Meaning
`type`	`"create"`, `"buy"`, or `"sell"`	Yes	Leg kind.
`wallet`	string	No	Managed wallet public key for this leg. If omitted, the default wallet is used.

The first leg receives the Jito tip instruction, so the first leg's wallet pays the bundle tip. Later legs do not receive Sender tips or Jito tips.

Create Leg

A create leg uses the same creation model as Laser Create. It generates the mint server-side and writes your externally hosted metadata URI into the Pump create instruction.

Field	Type	Required	Meaning
`name`	string	Yes	Token display name. Must not be empty.
`symbol`	string	Yes	Token ticker. Must not be empty.
`uri`	string	Yes	Public metadata JSON URI. Accepts `ipfs://`, `https://`, or `http://`. Aliases: `metadataUrl`, `metadataUri`.
`mayhem_mode`	boolean	No	Pump create flag. Alias: `mayhemMode`.
`cashback`	boolean	No	Pump creator cashback flag.
`initial_buy`	number or string	No	Developer buy in SOL, included inside the create transaction. Aliases: `initialBuy`, `buyAmountSol`, `devBuy`, `dev_buy`.
`slippage`	number or string	No	Percentage slippage for `initial_buy`. Default is `2`, maximum is `50`. Aliases: `initialBuySlippage`, `devBuySlippage`, `dev_buy_slippage`.

SolanaLaser does not host token images or metadata. Upload your image and metadata JSON to your own IPFS provider or public host, then pass the final metadata JSON URI as uri.

Buy and Sell Legs

Buy and sell legs use the trade builder from Laser Trade, with a smaller bundle-specific field set.

Field	Type	Required	Meaning
`amount`	number or string	Yes	SOL amount for SOL-denominated buys, or token atomic units for token-denominated buys and sells.
`denominatedInSol`	boolean or boolean string	No	Defaults to `true`. Sells must set this to `false`. New-token buy legs after `create` must keep it `true`.
`slippageBps`	integer	No	Defaults to `200`. Maximum is `5000`. `500` means 5%.
`pool`	string	No	Optional PumpSwap pool for existing-token trades.

Important limitations:

Buy legs after a create leg must be SOL-denominated buys.
Sell legs after a create leg are not supported.
Existing-token bundles currently support only one buy or sell leg.
Percentage sell amounts such as "100%" are not supported in bundle legs.
Bundle trade legs use slippageBps, not slippage.

Two-Wallet Launch Bundle

This is the normal launch bundle: the creator creates the token and performs a small initial developer buy, then a second managed wallet buys the token in the same Jito bundle.

Request

const response = await fetch("https://api.solanalaser.xyz/v1/laser/bundle", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-api-key": "sl_your_key",
  },
  body: JSON.stringify({
    jitoTip: "0.01",
    accounts: [
      {
        wallet: "CREATOR_WALLET_PUBLIC_KEY",
        type: "create",
        name: "Laser Cat",
        symbol: "LASER",
        uri: "ipfs://YOUR_METADATA_CID",
        initial_buy: "0.03",
        slippage: 5,
      },
      {
        wallet: "BUYER_WALLET_PUBLIC_KEY",
        type: "buy",
        amount: "0.10",
        denominatedInSol: true,
        slippageBps: 500,
      },
    ],
  }),
});

const bundle = await response.json();

Response: 200

{
  "bundle_id": "JITO_BUNDLE_ID",
  "results": [
    {
      "index": 0,
      "type": "create",
      "wallet": "CREATOR_WALLET_PUBLIC_KEY",
      "signature": "CREATE_AND_DEV_BUY_SIGNATURE"
    },
    {
      "index": 1,
      "type": "buy",
      "wallet": "BUYER_WALLET_PUBLIC_KEY",
      "signature": "BUYER_BUY_SIGNATURE"
    }
  ],
  "mint": "CREATED_TOKEN_MINT",
  "confirmed": true,
  "confirmation_status": "confirmed"
}

Launch With Multiple Buyers

SolanaLaser accepts up to 4 legs total. If the first leg is create, that leaves up to 3 following buy legs.

Request

const response = await fetch("https://api.solanalaser.xyz/v1/laser/bundle", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-api-key": "sl_your_key",
  },
  body: JSON.stringify({
    jitoTip: "0.015",
    confirm: true,
    accounts: [
      {
        wallet: "CREATOR_WALLET_PUBLIC_KEY",
        type: "create",
        name: "Laser Cat",
        symbol: "LASER",
        uri: "https://ipfs.io/ipfs/YOUR_METADATA_CID",
        initial_buy: "0.05",
        slippage: "7.5",
      },
      {wallet: "BUYER_1_PUBLIC_KEY", type: "buy", amount: "0.10", denominatedInSol: true, slippageBps: 700},
      {wallet: "BUYER_2_PUBLIC_KEY", type: "buy", amount: "0.08", denominatedInSol: true, slippageBps: 700},
      {wallet: "BUYER_3_PUBLIC_KEY", type: "buy", amount: "0.06", denominatedInSol: true, slippageBps: 700}
    ],
  }),
});

const bundle = await response.json();

Response: 200

{
  "bundle_id": "JITO_BUNDLE_ID",
  "results": [
    {"index": 0, "type": "create", "wallet": "CREATOR_WALLET_PUBLIC_KEY", "signature": "SIG_0"},
    {"index": 1, "type": "buy", "wallet": "BUYER_1_PUBLIC_KEY", "signature": "SIG_1"},
    {"index": 2, "type": "buy", "wallet": "BUYER_2_PUBLIC_KEY", "signature": "SIG_2"},
    {"index": 3, "type": "buy", "wallet": "BUYER_3_PUBLIC_KEY", "signature": "SIG_3"}
  ],
  "mint": "CREATED_TOKEN_MINT",
  "confirmed": true,
  "confirmation_status": "confirmed"
}

For this flow, SolanaLaser quotes each buy against a fresh bonding-curve model that is advanced after the dev buy and after each buyer. This matters because buyer 2 should not be quoted as if buyer 1 had not already bought.

Existing-Token Jito Trade

For an existing token, provide mint at the top level and include one buy or sell leg. This still sends through Jito, but it is not a multi-wallet launch bundle.

Request

const response = await fetch("https://api.solanalaser.xyz/v1/laser/bundle", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-api-key": "sl_your_key",
  },
  body: JSON.stringify({
    mint: "EXISTING_TOKEN_MINT",
    jitoTip: "0.005",
    accounts: [
      {
        wallet: "TRADER_WALLET_PUBLIC_KEY",
        type: "buy",
        amount: "0.10",
        denominatedInSol: true,
        slippageBps: 500,
      },
    ],
  }),
});

const bundle = await response.json();

Response: 200

{
  "bundle_id": "JITO_BUNDLE_ID",
  "results": [
    {
      "index": 0,
      "type": "buy",
      "wallet": "TRADER_WALLET_PUBLIC_KEY",
      "signature": "TRADE_SIGNATURE"
    }
  ],
  "mint": "EXISTING_TOKEN_MINT",
  "confirmed": true,
  "confirmation_status": "confirmed"
}

Response Fields

Field	Meaning
`bundle_id`	64-character Jito bundle ID returned by `sendBundle`.
`results`	One result per bundle leg, in request order.
`results.index`	Zero-based leg index.
`results.type`	Leg type: `create`, `buy`, or `sell`.
`results.wallet`	Managed wallet that signed this leg.
`results.signature`	Signature of the signed transaction for this leg.
`mint`	Created mint for create bundles, or the top-level `mint` for existing-token bundles.
`confirmed`	`true` when SolanaLaser observed a landed Jito bundle status.
`confirmation_status`	Jito/RPC confirmation status such as `confirmed` or `finalized`; `null` when `confirm: false`.

The signatures are useful for explorers and diagnostics, but the atomic unit is the bundle_id. A signature may be known before Jito confirms whether the bundle landed.

Jito Tip and Confirmation

Jito enforces a minimum bundle tip of 1,000 lamports. SolanaLaser validates jitoTip as at least 0.000001 SOL and adds it to the first bundle leg, paid by that leg's wallet.

Minimum tips can be insufficient during high-demand periods because bundles compete in a Jito auction. A higher jitoTip can improve landing probability, but it does not guarantee execution.

With confirm: true, SolanaLaser checks getBundleStatuses and getInflightBundleStatuses for about 30 seconds. Jito can briefly report Invalid or no status while a bundle is propagating, so SolanaLaser does not treat that as immediate failure. It only fails early on explicit Failed status or bundle-status errors.

With confirm: false, SolanaLaser returns after sendBundle accepts the payload and returns a bundle_id.

Common Errors

HTTP	Detail	Meaning
`400`	`accounts must contain between 1 and 4 bundle legs`	Empty bundle or too many legs for SolanaLaser.
`400`	`mint is required before buy or sell legs`	You sent a trade leg without top-level `mint` and without a prior `create` leg.
`400`	`mint must not be supplied with a create leg`	A create bundle should let SolanaLaser generate the mint.
`400`	`amount is required for buy and sell legs`	Trade leg has no `amount`.
`400`	`new-token bundle legs must be SOL-denominated buys`	A buy after create used token units, or a non-buy appeared after create.
`400`	`sell legs are not supported after a create leg`	You tried to sell the just-created token in the same bundle.
`400`	`only one trade against an existing token is supported per bundle`	Existing-token bundles currently allow one trade leg.
`400`	`slippageBps must not exceed 5000`	Bundle trade slippage cannot exceed 50%.
`400`	`jitoTip must be at least 0.000001 SOL`	Jito tip was below the service minimum.
`502`	`Jito bundle confirmation timed out`	Jito accepted the bundle, but SolanaLaser did not observe landed status before timeout.
`502`	`Jito bundle failed`	Jito reported explicit failure or landed bundle status contained an error.

Notes

Bundles are submitted as base64-encoded signed transactions.
SolanaLaser caps bundles at 4 transactions, even though Jito infrastructure can support larger bundles, to keep launch construction predictable.
Each transaction still includes priority-fee compute budget instructions.
The first managed wallet should have enough SOL for the Jito tip, its own transaction costs, and any initial_buy.
Buyer wallets need enough SOL for their own buy amounts and transaction costs.

What This Endpoint Is For​

Request​

Top-Level Fields​

Bundle Legs​

Create Leg​

Buy and Sell Legs​

Two-Wallet Launch Bundle​

Launch With Multiple Buyers​

Existing-Token Jito Trade​

Response Fields​

Jito Tip and Confirmation​

Common Errors​

Notes​

What This Endpoint Is For

Request

Top-Level Fields

Bundle Legs

Create Leg

Buy and Sell Legs

Two-Wallet Launch Bundle

Launch With Multiple Buyers

Existing-Token Jito Trade

Response Fields

Jito Tip and Confirmation

Common Errors

Notes