Introduction

Solana is known for being fast, performant and home to internet capital markets. With so many markets, transactions need to land quickly and reliably. 

However, there's a constraint. Each Solana transaction has a maximum size of 1,232 bytes. That's fine for simple actions like swaps, but it quickly breaks down for transactions that involve multiple complex steps. To execute those, you need to split the logic across multiple transactions and then stitch the pieces back together. For instance, a typical LI.FI transaction involves multiple steps: onchain pathfinding, cross-chain transfers, fee handling, transaction tracking, and soon, multi-chain calls. All of this creates a real need for bundling logic. Historically, we worked around these constraints by returning a single Solana transaction via transactionData. When a route was too big to fit into one Solana transaction, we had to:

• Reduce route complexity

• Remove safety / tracking instructions

• Or fail the quote entirely

As LI.FI's cross-chain ecosystem has become more distributed over time, demand from users of popular wallets like Phantom has increased. This demand relies on deeper Solana flows; this "single transaction only" model was soon not versatile enough for an increasingly tight bottleneck.

To solve this problem without compromising reliability, performance, or UX, LI.FI has adopted Jito Bundles.

This deep dive explains exactly how LI.FI uses Jito bundles today, why they are necessary, and what these changes mean for developers integrating LI.FI on Solana.

Why We Need Jito Bundles

For simple actions, Solana's transaction size limit is rarely a constraint. But for many LI.FI integrators, actions involve far more than a single swap in an increasingly multi-chain world. A common cross-chain flow might require a swap before bridging, a deposit into a messaging layer, fee logic, and tracking instructions. Each of these components adds to the instruction payload, and together they often exceed the limit that Solana accepts in a single transaction.

In the past, when a route's instruction set grew too large to compile into a Solana transaction, the risk of an error being returned was higher. This meant that Solana transactions would have had to be retried in an attempt to fit actions into the transaction size limit. Naturally, this is not a good user experience for developers or their end-users.

One obvious solution is splitting the logic into multiple transactions. But there's no native way to ensure that several separate transactions:

• execute atomically,

• execute in order,

• land in the same block, or

• all succeed, or all fail together.

Without these guarantees, splitting is unsafe. Imagine a route where the swap succeeds, but the bridge deposit never executes; instead, the user's funds would be left stranded in an inconsistent state. 

This is precisely the problem that LI.FI's utilisation of Jito bundles solves for. Bundles provide a safe, atomic way to break a large, complex Solana workflow into multiple smaller transactions while preserving the guarantees that transactions land correctly, every time. Instead of being constrained by the 1,232 byte limit, LI.FI now allows integrators to express multi-step routes cleanly, modularly, and safely without resorting to oversimplification or rejecting valid user requests.

A Bundled Future

Originally, LI.FI exposed a jitoBundle flag on the /quote endpoint.

The old configuration was simple:

• If jitoBundle was set, always return a bundle.

• If it was not set, always return a single Solana transaction.

This worked, but not as well as it could have. Some flows that fit into a single transaction were still returned as bundles. Others that couldn't fit were only returned as bundles if the integrator knew to set the flag—and if they didn't, the result was an error response due to hitting the transaction size limit. The previous configuration was deterministic, but rigid, and placed too much burden on integrators while limiting reliability.

Introducing: A Smarter, Dynamic Model with Jito Bundles

LI.FI is now rolling out a more flexible and intelligent model with Jito Bundles. In this new flow, we always attempt to create a normal Solana transaction first. Only when the route exceeds the size limit, or clearly cannot be represented as a single atomic operation, do we automatically generate a Jito bundle (of up to 5 sequential actions per bundle).

The same jitoBundle flag remains, but its meaning changes. Instead of "always return a bundle," it now signals: "I am willing to receive a Jito bundle if necessary".

This is a significant improvement for integrators. They no longer need to guess whether their transaction must be bundled. They simply opt into compatibility, and LI.FI determines the correct execution format automatically.

This dynamic approach allows LI.FI to adapt to the nature of each submitted request using single transactions wherever possible, and bundles only when they're genuinely needed.

How LI.FI Splits Transactions Inside Bundles

A Jito bundle can contain up to five transactions. LI.FI uses these slots to separate instructions based on natural operational boundaries rather than trying to pack them tightly.

For example:

Example 1: A complex multi-step swap

• Tx 1: tracking + fee collection

• Tx 2: swap (e.g., via Jupiter)

Example 2: Implicit swap + bridge

• Tx 1: swap (Jupiter)

• Tx 2: bridge deposit (Hyperlane, Wormhole, Unit, etc.)

Example 3: swap + bridge + swap (cross-chain DEX to DEX)

• Tx 1: swap on Solana

• Tx 2: bridge deposit

• Tx 3: swap on destination chain

(Only the first two would be bundled on Solana; the final swap is executed on the destination chain.)

LI.FI's bundling strategy is intentionally modular. We don't try to maximise byte utilisation per transaction. Instead, each logical action, like tracking, fee collection, swapping, bridging, gets its own transaction whenever appropriate. This leads to cleaner semantics, easier debugging, higher reliability, and a structure that matches how integrators reason about these actions.

Developers no longer need to think about whether their intended transaction sequence requires bundling; LI.FI handles it automatically.

Real-World Possibilities Unlocked by Jito Bundles

Jito bundles unlock combinations that previously could not fit into Solana's transaction size limits. For example, LI.FI can now safely combine a Jupiter swap with a Unit or Hyperlane bridge deposit. Before bundles, these pairings often may have exceeded transaction limits and failed at quote time.

Bundles also make more nuanced flows possible. A user might swap SOL into a stablecoin, deposit that stablecoin into a bridge, and then, once on the destination chain, swap again into a different token. Steps one and two almost never fit into a single Solana transaction, but bundling them ensures atomicity and reliability.

Even more advanced cases, such as interacting with systems like Perena, where mint, burn, and swap instructions must be sequenced across chains, are now unlocked. Bundles remove structural constraints that previously kept these workflows out of reach.

Composable across internet capital markets, LI.FI simply lets you just use Solana.

Conclusion

Jito bundles represent a major improvement in Solana's execution capabilities, enabling complex, multi-instruction workflows that were previously impossible to express safely within a single transaction. By adopting bundles, LI.FI can offer richer routes, reduce failure rates, support implicit swaps, and compose tools in ways that previously exceeded Solana's transaction size limit.

The shift to a dynamic bundle model ensures that LI.FI always chooses the most reliable and expressive execution method for each route. Developers integrating with LI.FI will soon benefit from a more robust system that adapts automatically, producing either a single transaction or a multi-transaction bundle when necessary.