sendBundle submission is billed as 1 credit from your plan.
Supported Methods
sendBundle
Submits a list of signed transactions as an atomic bundle. If the bundle is accepted, returns abundle_id (SHA-256 hash of the transaction signatures). This does not guarantee the bundle will land on-chain. Check for transaction confirmation on chain to verify.
A tip is required. At least one transaction must transfer SOL to a Helius tip account. If the tip is too low, the bundle may not be selected for inclusion.
Request
Example
Response
result is the bundle ID — use it with getBundleStatuses to track landing.
getBundleStatuses
Returns the status of submitted bundles. If a bundle has not landed or is not found, it returnsnull.
Request
Example
Response
null in the value array for bundles not found.
Region Routing
By default, Helius routes your bundle to Jito’s global endpoint (mainnet.block-engine.jito.wtf), which geo-routes to the nearest Block Engine automatically.
To target a specific region, set the jito-region HTTP header:
Example with Region
Tip Accounts
At least one transaction in your bundle must include a SOL transfer to one of these tip accounts. Pick one at random to reduce contention.Bundle Requirements
- Max 5 transactions per bundle
- All transactions must be fully signed
- Use base64 encoding (recommended over base58 for performance)
- At least one transaction must include a tip
- Transactions execute sequentially — tx2 can depend on state changes from tx1
simulateBundle (Optional)
You can optionally simulate your bundle before submitting to check for errors:Protect against sandwich attacks
To route your bundle away from validators statistically linked to sandwich attacks, add themev-protect=true query parameter to your RPC URL — no changes to your bundle:
See also
MEV Protect
Route around validators statistically linked to sandwich attacks.
Transaction Rebates
Opt in on single
sendTransaction calls to earn a share of the MEV your transactions create, paid in SOL.