Jupiter vs 1inch: Cross-Chain Routing for Arb Bots

A cross-chain arb bot that quotes both Solana and an EVM chain lives or dies on two aggregators: Jupiter on Solana and 1inch on Ethereum, Arbitrum, Base, and the rest of the EVM set. They solve the same problem — find the best price across fragmented liquidity — but the machinery underneath is different enough that you cannot write one abstraction and expect it to behave. Metis (Jupiter's router) and Pathfinder (1inch's router) have different latency profiles, different failure modes, and completely different ideas about who pays gas. If you treat them as interchangeable behind a getQuote() interface, your fill rate on one leg will quietly rot.

Here's what actually matters when you're wiring both into the same bot.

Quote latency: the number that sets your edge

On Solana, a Jupiter Quote API call typically returns in 40–120 ms from a well-placed server, and the quote is a snapshot of on-chain reserves as of a recent slot. Metis does a two-phase search — it prunes the DEX graph, then runs a split-route optimizer across pools like Orca Whirlpools, Raydium CLMM, and Meteora DLMM. The output is a route plan plus a swapTransaction you sign. Because Solana blocks are ~400 ms, a 100 ms quote is fresh enough that you're mostly racing other bots, not the clock.

1inch Pathfinder is a heavier search. On mainnet with deep liquidity, /quote and /swap calls from the public API commonly land in 200–500 ms, and Pathfinder splits across dozens of protocols with multi-hop paths that can span three or four pools. That latency is fine for a manual swap. For an arb bot it's a problem, because the EVM state you quoted against may have moved by the time your transaction is mined 12 seconds later. The mitigation is to quote aggressively, but that runs straight into rate limits (below).

Practical consequence: your Solana leg can be near-just-in-time, but your EVM leg needs a staleness buffer baked into the spread threshold. I usually widen the required edge on the 1inch side by the expected price drift over one to two blocks, estimated from recent volatility, rather than trusting a quote that's already 400 ms old. This is the same class of latency-vs-freshness tradeoff that shows up when you compare Meteora DLMM and Orca Whirlpools for an LP bot — the routing math is only as good as the state it ran against.

Slippage models are not the same field

Both APIs take a slippage parameter, but they mean subtly different things.

• Jupiter enforces slippageBps at the program level — the swap instruction reverts on-chain if the out-amount falls below the minimum. You can also hand it a computed minOutAmount directly and skip Jupiter's slippage entirely, which is what you want in a bot: compute your own floor from your own price feed, don't let the aggregator pick it.
• 1inch returns toAmount and you set slippage (a percentage) on the /swap build. The router contract enforces the min return, but on EVM you're also exposed to sandwich MEV between quote and inclusion, so your effective slippage is worse than the number suggests unless you route privately.

That private-routing point is where the two chains diverge hard. On Solana you fight MEV with priority fees and Jito bundles; on EVM 1inch gives you Fusion.

Gasless fills: Fusion changes the arb math

1inch Fusion (and Fusion+) turns a swap into a Dutch-auction intent. You sign an order, resolvers compete to fill it, and the resolver pays gas. For an arb bot this is genuinely useful for two reasons: your EVM leg no longer needs the chain's native gas token pre-funded on every wallet, and the fill is submitted through a private channel, so the sandwich risk on that leg drops sharply.

The catch is that Fusion is an auction, not an instant swap. The price starts favorable to you and decays over the auction window until a resolver finds it profitable. So you trade execution certainty for gaslessness and MEV protection. For a latency-sensitive arb where you need both legs to land in a tight window, a decaying auction on one side introduces timing risk you have to model. A rough decision rule I use:

# EVM leg execution mode for a cross-chain arb
def evm_leg_mode(edge_bps, native_gas_funded, urgency):
    if urgency == "must_land_this_block":
        return "classic_swap"           # pay gas, deterministic inclusion
    if not native_gas_funded or edge_bps < 25:
        return "fusion"                 # resolver eats gas, MEV-protected
    return "classic_swap_private_rpc"   # gas + private tx, tight timing

Jupiter has no direct Fusion equivalent — there's no gasless resolver network on Solana. What you get instead is cheap base fees plus a priority-fee auction and optional Jito bundles for atomic landing. If your strategy needs the Solana buy and the EVM sell to be near-atomic, understand that these are two different inclusion mechanisms with no shared guarantee. The Solana-side landing question is worth its own study; the tradeoffs in bloXroute versus Jito for MEV bundle landing apply directly to how you get the Jupiter leg included on time.

API rate limits will shape your architecture

This is the boring detail that decides whether your bot works at scale.

• Jupiter runs a free public tier that's fine for testing but throttles hard under real polling, plus paid tiers and self-hostable infrastructure. Many serious Solana bots self-host the Jupiter API or run their own routing so they aren't sharing a rate bucket with the whole ecosystem. If you're quoting a dozen pairs several times a second, the hosted free endpoint is not it.
• 1inch gates the Dev Portal API by API key with per-second and monthly caps that vary by plan. Pathfinder quotes are expensive to serve, so the limits bite quickly. You cannot brute-force freshness by polling /quote in a tight loop — you'll get 429s and your effective quote age gets worse, not better.

The architectural answer on both sides is the same: keep a local order-book / pool-state cache, price most opportunities off your own state, and only hit the aggregator to confirm and build the transaction on candidates that already look profitable. Treat the aggregator call as the last mile, not the scanner. This is one of the first things I flag in a strategy consultation — teams burn their rate budget scanning when they should be scanning locally and quoting selectively.

A concrete side-by-side

	Jupiter (Metis)	1inch (Pathfinder / Fusion)
Typical quote latency	40–120 ms	200–500 ms
State freshness vs inclusion	~400 ms blocks, near-JIT	~12 s blocks, quote drifts
Slippage control	On-chain min-out, or your own minOutAmount	slippage %, MEV-exposed unless Fusion
Gasless option	None (priority fee / Jito)	Fusion Dutch auction, resolver pays gas
Rate limits	Public tier throttles; self-host common	API-key tiers, 429s under tight polling

What I'd actually build

Quote Solana off a self-hosted Jupiter route API or your own pool state, compute your own min-out, and land via priority fees or a Jito bundle when atomicity matters. On the EVM side, default to Fusion for anything that isn't time-critical to shed gas funding and sandwich risk, and fall back to a classic swap through a private RPC only when you need deterministic same-block inclusion. Keep the two legs decoupled with an inventory buffer on each chain so you're not forced into a synchronous cross-chain fill that neither aggregator can guarantee.

Two mistakes I see constantly: assuming Fusion's auction fill is instant, and polling both aggregators as your scanner. Both come from copying single-chain patterns into a cross-chain bot. If you're wiring Metis and Pathfinder into one system and want the routing, inventory, and landing logic pressure-tested before it touches mainnet, a code review and architecture audit is the cheapest way to catch the leg that's silently losing money.