Bundles and atomic execution
“Bundled” can mean several different things: instructions inside one Solana transaction, a Jito group of signed transactions, calls inside one EVM account operation, or unrelated ERC-4337 operations submitted together. Their guarantees are not interchangeable.
The short answer
Atomic execution means a defined group commits as one state transition: either every required step succeeds or the group's state changes do not persist. It protects against a half-completed sequence. It does not guarantee inclusion, favorable pricing, low fees, or protection from every re-broadcast and contract design.
Start by identifying the atomic boundary. On Solana it may be one transaction or a Jito bundle. On Robinhood Chain it may be several calls deliberately encoded inside one EVM transaction or smart-account operation. The word “bundle” by itself does not reveal which boundary applies.
Four boundaries traders commonly call a bundle
Solana transaction
Several instructions, one transaction
The runtime processes instructions sequentially and atomically. Account setup, swap instructions, and cleanup can succeed together; a required instruction failure prevents the transaction's state changes from committing.
Jito bundle
Several signed Solana transactions
Jito accepts an ordered list of up to five transactions that execute sequentially, in the same slot, and all-or-nothing under the bundle path. The transactions remain individually signed payloads.
EVM batch
Several calls inside one account operation
A smart account or Multicall-style contract can execute several calls in one transaction. They are atomic when the batch implementation reverts on a required failure; contract code can also intentionally catch failures, so inspect the behavior.
ERC-4337 bundle
Several UserOperations in one handleOps transaction
An ERC-4337 bundler packages operations from one or more accounts. The word describes submission infrastructure. It does not make unrelated users' actions one shared all-or-nothing trade.
One Solana transaction is the smallest atomic group
Solana transactions can contain multiple instructions to different programs. The runtime executes them in order. If a required instruction fails—because a balance changed, a slippage check rejects the swap, or compute is exhausted—the transaction reports an error and does not leave earlier instruction state as a partial trade.
The transaction fee can still be charged because validators already performed signature verification and processing. Atomicity protects state, not the fee payer's entire native balance. Read from quote to fill for the difference between submission, execution, and reconciliation.
A Jito bundle extends the group across transactions
Jito's Block Engine accepts a list of up to five fully signed transactions. The documented bundle path preserves their listed order, requires execution in one slot, and rejects the bundle if any transaction fails. This is useful when several payloads cannot fit inside one transaction but must share an outcome.
A tip is required for bundle consideration, and bundles compete in an auction. Too small a tip may leave the bundle unselected. The response's bundle ID means the engine received it; status endpoints are required to learn whether it landed.
Jito also documents an important edge case: transactions from an uncled block can be re-broadcast into the normal banking path, which does not preserve bundle atomicity or reversion protection. State assertions and conditional tip logic remain necessary. Avoid placing an unconditional tip in a standalone transaction whose safety depends on the rest of the bundle landing.
EVM batching depends on the contract that defines it
Robinhood Chain is EVM-compatible and supports account abstraction. A smart account can encode multiple calls in one operation—for example, approve an exact amount, execute a swap, and move the result. If the account's batch function reverts when one call fails, the state changes from the entire transaction revert together while gas is still consumed.
Atomic behavior is a contract choice. A batch function can catch an inner call failure and continue, or mark some calls as optional. A wallet's “batch” label therefore does not prove all-or-nothing behavior. Inspect the account implementation, call mode, and receipt logs.
ERC-4337 introduces another actor named a bundler. It receives UserOperations, validates them, and packages several into an EntryPoint handleOps transaction. Your smart account can encode several atomic calls inside its own UserOperation, but unrelated UserOperations in the same outer transaction are not automatically one shared economic outcome.
What atomicity does not guarantee
Landing
The group can be valid and still expire, be dropped, lose an auction, or never reach the relevant leader, sequencer, or bundler.
Price
All steps can succeed atomically at the worst output you authorized. Minimum output and deadlines still define execution quality.
External systems
An offchain API response, centralized exchange action, bridge finality event, or later transaction is outside the atomic boundary unless a protocol explicitly links it onchain.
Safe permissions
An approval included before a swap can be safe inside a reverting batch, while an approval sent as an earlier standalone transaction can remain active after the swap fails.
No fees
Failed onchain execution can still charge Solana transaction fees or EVM gas. A poorly structured tip can create additional loss.
Track the status at each layer
- Constructed: instructions, transactions, or calls have been grouped with an intended order and state assumptions.
- Accepted: an RPC, Block Engine, sequencer endpoint, or ERC-4337 bundler returned an identifier.
- Selected: the submission path chose the group for delivery or inclusion. This stage may be hidden from the trader.
- Landed: an onchain slot or block contains the transaction or group.
- Executed: the receipt or transaction metadata reports success rather than a revert or instruction error.
- Reconciled: wallet deltas, fees, tips, authorities, and remaining inventory match the intended outcome.
Before signing a grouped action
Draw the atomic boundary
Identify exactly which instructions or calls revert together and which setup, approval, tip, or follow-up actions sit outside it.
Inspect the failure condition
Find the minimum output, deadline, balance assertion, account state, gas or compute ceiling, and any optional call behavior.
Separate acknowledgment from execution
Know what the returned signature, bundle ID, or UserOperation hash proves and which status endpoint supplies the final result.
Price every attempt
Include network fees, priority fees, tips, paymaster or service charges, and retry costs even when the economic action reverts.
Reconcile every component
Verify all expected assets and authorities after success or failure. A single success badge can hide a surviving approval or unexpected transfer.
Primary sources
Verify the whole outcome
Do not stop at the bundle identifier.
Paste a public address to reconstruct successful and failed transactions, fees, approvals, and final balances without connecting a wallet.
Open the journal