Send Bundle

Submit up to four transactions that land together, in order, or not at all.

Submit a group of 1–4 signed transactions as one atomic unit. Either every transaction in the bundle lands in the same slot, in the order you sent them, or none of them lands. Use it when one transaction only makes sense if another one landed first: a setup step followed by a swap, a swap followed by your own backrun, or a position change followed by a cleanup.

Bundles use the same compact binary framing as Batch Send. The difference is the guarantee: Batch Send forwards each transaction independently, while Send Bundle delivers the whole group to block builders as one unit.

Request

Field	Value
Method	POST
Path	/api/sendBundle?c=<YOUR_API_KEY>
Content-Type	application/octet-stream
Body	Binary-encoded bundle, 1–4 length-prefixed transactions

Send Bundle is available on every regional and auto-routed endpoint, over http:// and https://.

Limits

Constraint	Value
Transactions per bundle	1–4
Min transaction size	66 bytes
Max transaction size	1,232 bytes
Max body size	4,936 bytes

Members may be legacy, v0 or v1 transactions; bundles keep the 1,232-byte member limit for every version, unlike Batch Send where v1 members may reach 4,096 bytes. | Duplicate signatures within a bundle | Rejected |

Wire Format

The body is a concatenation of length-prefixed transactions. No JSON, no base64, no outer count, no separators. Order matters: transactions land in the order they appear in the body.

[len_hi][len_lo][tx_bytes...][len_hi][len_lo][tx_bytes...]...

Each length prefix is a big-endian u16 giving the size of the following signed transaction bytes. A zero length, a truncated final transaction, or trailing bytes rejects the whole request.

Tipping

At least one transaction in the bundle must pay a Nozomi tip of at least your account's minimum (default 0.001 SOL) and never less than 1,001 lamports. The other transactions may be untipped. Tip exemptions do not apply to bundles.

The tip can be in any member, but it is common to put it in the first. Because the tip is an instruction inside your own transaction, you only pay it when the bundle lands. Rotate tip addresses between bundles as you would for single transactions.

Response

Returns an empty body with 200 OK when the whole bundle is accepted and queued for delivery. Landing is determined asynchronously; compute and track your signatures client-side before submitting, then confirm on-chain or in the dashboard.

Unlike Batch Send, a bundle is validated in full before anything is queued. There is no partial acceptance: any error below means nothing from that request was sent.

Status	Body	Meaning
200	empty	Bundle accepted
400	Failed to parse transaction	Framing error, more than four members, a duplicate signature, or a transaction whose instructions cannot be read
400	Malformed transaction string	A member under 66 bytes
400	Transaction too large	A member over 1,232 bytes or a body over 4,936 bytes
400	Insufficient tip	No member pays a recognized tip at or above the minimum
401	Unauthorized	Missing or invalid API key
403	Forbidden	Your key is not permitted to send bundles, or a member uses a program your key is restricted from
409	Transaction already confirmed	A member has already landed on-chain; the bundle can no longer be atomic
429	Too Many Requests	Rate limited. Each member consumes one rate-limit token, so a four-transaction bundle costs four
500	Internal Server Error	Retry
503	not ready	Bundle delivery is temporarily unavailable on this server; retry against another region

All error bodies are plain text.

How Bundles Are Delivered

• Block builders only. Bundles are delivered to block-builder paths (such as Jito and Harmonic), which are the paths that can guarantee atomic inclusion. They do not go over staked connections or direct-to-leader paths.

• Nozomi appends its own fee transaction. You may see one extra small transaction from Nozomi immediately after your members in the block. Your transactions are delivered byte-for-byte as you signed them.

• Once per builder by default. A bundle is submitted once to each eligible block builder. If your strategy needs repeated resubmission until the blockhash expires, ask support to configure it for your key.

• No cross-region forwarding. Single transactions are cross-forwarded between Nozomi regions; bundles are not. For redundancy, send the same bundle to more than one regional endpoint yourself. Rate limits are per region.

• Deduplication. Re-sending an identical bundle (same signatures in the same order) shortly after the first is accepted with 200 but not delivered again. A bundle with a different member set or order is treated as new. Once any member confirms, every pending copy of the bundle is dropped and further submissions return 409.

Building a Bundle

• Sign every member with the same recent blockhash so they expire together. Durable-nonce members are accepted, including bundles where every member uses a durable nonce; see the note on durable nonces in Tipping → Retries.

• Put transactions in the body in the order they must execute.

• Keep each member's compute-unit limit close to what it uses. Bundles compete for block space as a unit.

• Do not include a transaction that may already have landed on its own. If it confirms before the bundle is delivered, the bundle is dropped.

When to Use

Use Send Bundle when correctness depends on ordering or all-or-nothing execution across several transactions. If you simply have several independent transactions to submit, use Batch Send: it is lower overhead, has no per-bundle size cap, and lands each transaction on whichever path is fastest.

From a browser, application/octet-stream skips the CORS preflight OPTIONS request, the same as Batch Send.