Bridge Aggregators and Intents: Routes, Relayers and Risk

Introduction

Ask an app to move USDC from Arbitrum to Base and it may not pick a bridge itself. It may hand the job to an aggregator, which asks many bridges and exchanges for a price and returns the route it ranks best. LI.FI, the aggregator this page uses as its main example, describes its API as an off-chain layer that retrieves quotes from bridges, decentralised exchanges and solvers to find the best price and route (LI.FI system overview, read 20 October 2026).

Intents change who moves first. You sign an order that describes the result you want, and a third party called a solver or relayer delivers it on the destination chain from its own funds, to be repaid out of your deposit once the protocol has checked the delivery. ERC-7683, the draft Ethereum standard for these orders, describes an order as an offer of payment in exchange for the fulfilment of a set of requirements (read 20 October 2026).

Both ideas change what you pay and whom you trust. An aggregator can find a cheaper or faster route, but its own contract sits in the path and usually needs permission to move your tokens. An intent can arrive within seconds, but the speed is bought with someone else's capital, and the rules that decide when that capital is repaid also decide who loses when a fill goes wrong.

This page is written for someone who has been offered a one-click transfer between chains by a wallet or a swap site and wants to know what happens after the click. It assumes you know what a blockchain, a token and a wallet are, and explains the rest as it comes up.

The sections below cover route search, the trust an aggregator adds, how intents work with deBridge and Across as live examples, what solvers charge, who absorbed the loss in Across's Solana incident of July 2026, chain abstraction and Hyperlane. If bridges themselves are new to you, our guide to how bridges work covers the basics first.

Every figure on this page names its source and the date it was read, and every source was read on 20 October 2026; where a figure can move within hours, its sentence also gives the time of the read in UTC. Nothing here recommends a protocol, and no route described below removes risk: each one moves it to a different contract, company or person.

What a Bridge Aggregator Does for Your Transfer

An aggregator does not move tokens itself. It finds the protocols that can, compares what each one would deliver, and builds the transactions that send your funds through the one it ranks first.

A route search across bridges and exchanges

LI.FI's system overview, read on 20 October 2026, describes the search from end to end. An app, which the documentation calls the dApp, forwards your request to LI.FI's API, which fetches pricing from bridges, decentralised exchanges and solvers and returns the route it identifies as optimal. You then sign a transaction to LI.FI's main smart contract, which LI.FI calls the Diamond, and the Diamond passes it to a facet contract written for the chosen bridge, exchange or solver, which carries out the transfer through that protocol's own contracts.

A route can be more than one hop. LI.FI's documentation on requesting routes, read the same day, says a route may include multiple steps, each its own transaction, which run in sequence because each depends on the output of the one before. A route that swaps ETH for USDC, bridges it and swaps again on arrival carries the contracts, and the chance of failure, of every step.

How the route gets ranked

The ranking is a setting, not a judgement about safety. LI.FI's route documentation, read on 20 October 2026, offers two orderings: CHEAPEST, which puts first the routes with the highest estimated return amount, and FASTEST, which puts first the routes with the shortest estimated execution time. An app can also allow, deny or prefer named bridges and exchanges, and can hide routes whose price impact reaches a limit it sets.

Neither ordering measures how a bridge verifies your transfer or who could upgrade its contracts. Two quotes a minute apart can name different bridges, because prices and available liquidity move, so the route to check is the one in front of you when you sign, not the one you saw last week.

Jumper: an app built on the aggregator

You may meet an aggregator through an app rather than through its API. LI.FI's changelog for its developer kit, read on 20 October 2026, records under April 2026 that version 4 of the kit was released and was "now adopted by Jumper". Jumper is therefore one consumer app that runs on LI.FI's own tools, and using it means trusting the app as well as the aggregator and the bridge behind it.

A front end adds risks of its own. You reach it through a web address, so a copied site at a lookalike address is a danger before any contract is involved, and the app chooses which routes to show you and which defaults to set. Our guide to defending against wallet drainers and phishing sites covers the checks that apply to any bridge or swap site.

What the headline quote leaves out

An app that uses an aggregator can add its own charge. LI.FI's route documentation, read on 20 October 2026, lists an integrator fee option, with 0.03 given as the example for a 3% fee, and says the integrator has to be verified to use it. The cost you see in an app can therefore combine the bridge's charge, the gas fee for each step and the app's own cut.

Slippage is the other moving part. The same documentation lets a route carry a slippage tolerance, expressed as a proportion such as 0.005 for 0.5%, and a route that includes a swap can deliver less than its estimate by up to that tolerance. Read the minimum amount received, not only the estimate, before you sign.

The Trust You Add When an Aggregator Sits in the Path

A direct bridge transfer asks you to trust the bridge. A transfer through an aggregator asks you to trust the bridge and the aggregator's contracts as well, and those contracts usually hold permission to spend your tokens.

One contract in front of many protocols

In LI.FI's system overview, read on 20 October 2026, the Diamond is the primary on-chain entry point for every route, and it reaches each bridge, exchange or solver through a separate facet contract. The design lets an aggregator add a new bridge without asking you to approve a new contract, because the contract you approved stays the same.

The same design means that a new facet changes what the contract you approved can be made to do. That is the risk LI.FI's own incident report describes.

Approvals: permission that outlives the transfer

Before a smart contract can move an ERC-20 token out of your wallet, you sign an approval that names the contract and an amount. A finite approval covers the transfer in front of you. An unlimited approval stays live after the transfer has finished, so whatever that contract can later be made to do, it can do with the full balance you allowed it to spend.

Wallets usually show the spender and the amount before you sign, and many let you lower the amount. Our guide to transaction signing and approval hygiene explains how to read an approval request and how to revoke one you no longer need.

LI.FI's incident of 16 July 2024

LI.FI's security incident report, published on 18 July 2024 and read on 20 October 2026, says that on 16 July 2024, shortly after a new facet was added, a vulnerability in that facet let an attacker reach self-custodial wallets that had set an infinite token approval for the LI.FI contract. LI.FI estimated the amount stolen at around $11.6 million, from 153 wallets on Ethereum and Arbitrum, and the assets drained included USDC, USDT and DAI.

The report gives the cause plainly. Calls through the new facet could reach any contract without validation, while LI.FI's other facets check such calls against a whitelist of approved contracts and functions, and LI.FI attributes the missing check to an individual human error in overseeing the deployment. Its response, the report says, was to disable the vulnerable facet across all chains.

What a finite approval changes

LI.FI's report says the vulnerability was limited to infinite approvals and did not affect finite approvals, which it describes as the default setting in its API, developer kit and widget. A finite approval does not make a contract safe. It caps what a later fault in that contract can reach, and in July 2024 that cap decided which wallets were drained.

Some protocols ask for more than the transfer itself. deBridge's fee documentation, read on 20 October 2026, tells apps either to request an unlimited allowance or to add a 30% buffer over the estimated operating expenses, so that a refreshed quote still fits the approval. If a wallet shows you an approval far larger than your transfer, lower it where the wallet allows, and revoke it once the transfer has arrived.

Intents: You Sign the Result, a Solver Delivers It

A conventional bridge moves your tokens and makes you wait for its verification. An intent reverses the order of events: someone delivers first, and the protocol checks the delivery afterwards, before it repays them.

What ERC-7683 calls an order

ERC-7683, Cross Chain Intents, is a draft Ethereum standard created on 11 April 2024 (eips.ethereum.org, read 20 October 2026). It says intent protocols let users express desired outcomes as orders, while specialised actors called solvers, also known as fillers, carry out the required actions and receive payment.

In bridge terms, the requirement is usually an amount of a token at an address on another chain, and the payment is your deposit on the chain you are leaving. The draft adds that the model is especially useful for cross-chain activity, where execution may require coordinating transactions, liquidity and settlement across several chains.

From signature to settlement

The draft, read on 20 October 2026, sets out a typical life for an order:

• You express an intent to an application, which creates an order for a specific protocol.
• The order is submitted to an order feed, where solvers can see it.
• A solver evaluates the order and decides whether filling it is worth the cost.
• The solver executes the required steps, such as paying you on the destination chain.
• Settlement pays the solver.

In an escrow-first design, your tokens stay locked on the source chain after the solver's money has reached you, and the solver waits for the protocol to release your deposit to it.

Escrow first or fill first

ERC-7683 leaves protocols free to differ in how users create orders, how funds are authorised, how settlement is verified and how prices are set, including whether execution is escrow-first, fill-first using resource locks, or auction-based (read 20 October 2026). In a fill-first design, the draft explains, your funds sit under a lock that the solver trusts, so there is no need to open the order on the source chain before it can be safely filled.

The current text says an earlier draft standardised more of the order's life, including how solvers filled orders on the destination chain, and that the present design moves the standard to the interface solvers use to read orders. It does not require protocols to use a common escrow, settlement contract or fill function, so a protocol's support for ERC-7683 tells you how solvers read its orders, not which contract holds your deposit.

What the standard does not promise

The draft is direct about its limits. Its security section says it standardises how a protocol describes an order to solvers and does not standardise or vouch for the security of the protocol that ultimately settles the order (read 20 October 2026).

It also names the solver's exposure: solvers are at risk from the time they commit capital, approvals or transactions to an order until their expected payment is final and spendable. That window is the economic core of every intent design.

How a pool bridge such as Stargate differs

Not every fast route is an intent. Stargate, whose documentation now sits within LayerZero's, is described there as a cross-chain liquidity protocol built on LayerZero V2 with unified liquidity pools for native assets such as USDC, USDT and ETH (read 20 October 2026). Between two chains that both have pools, native assets are locked in the pool on one side and unlocked from the pool on the other, and every transfer uses LayerZero messaging, its verifier networks and its executors.

The difference is whose money waits. In a pool design, the pools hold value between transfers, and the message system that releases them has to protect it all the time; in an intent design, a solver's capital is exposed only while a fill waits for settlement. On chains without a native pool, the same page says Stargate mints backed representations such as USDC.e, so the holder's token depends on the pools behind it.

Inside deBridge DLN: How a Live Intent Order Runs

deBridge's Liquidity Network, DLN, is an escrow-first intent design in production. Its protocol overview, read on 20 October 2026, describes two layers: on-chain smart contracts, and solvers who perform the off-chain matching and on-chain settlement of trades.

Creating and filling an order

A user, whom deBridge calls the maker, creates an order by calling a contract named DlnSource on the source chain, stating the destination chain, the token and amount to receive and the receiving address. The contract takes the input tokens and locks them until the order is either unlocked or cancelled, which can happen only through its counterpart, DlnDestination, on the destination chain. deBridge calls these orders limit orders, and our guide to exchange order types explains the term.

Solvers track new orders and fill those that meet their own requirements, which the overview says can include profitability, margin or whether the input token is on their list. A solver fills by calling DlnDestination on the destination chain and supplying the requested tokens, which the contract sends to the receiver before marking the order as fulfilled, so the same order cannot be handled twice. No cross-chain message is needed for the fill itself.

Unlocking the deposit, or cancelling it

The first solver to fill an order can then call sendUnlock on DlnDestination, which sends a message through deBridge's messaging network to DlnSource, telling it to release the locked deposit to an address the solver chooses. Before it acts, DlnSource checks that the message came from the DlnDestination contract it has on record (protocol overview, read 20 October 2026).

Cancelling runs the same way in reverse. A maker who wants out calls sendCancel on the destination chain, which succeeds only if the order is neither fulfilled nor already cancelled, and the message back to the source chain unlocks the funds to the maker. deBridge's fee page, read the same day, says both order-creation fees are fully refunded if the order is cancelled.

Who carries which risk, and for how long

deBridge's documentation splits the risk by time (protocol overview, read 20 October 2026). The maker bears the risk of the cross-chain infrastructure from the moment the order is created until it is fulfilled on the destination chain, which the overview calls typically a matter of seconds. The solver bears risk from the fulfilment until its liquidity is unlocked on the source chain.

The solver's risk has two parts. One is a reorganisation or fork of the source blockchain that reverses the maker's order after the solver has paid, which each solver manages by choosing how many block confirmations to wait for. The other is the messaging infrastructure that carries the unlock, whose messages deBridge's validators sign only after strict finality requirements are met.

What a DLN order costs

deBridge's fee page lists two fees taken when an order is created (read 20 October 2026): a flat fee in the source chain's native token, paid to deBridge validators for processing the eventual unlock message, and a variable protocol fee of 4 basis points, deducted from the input token. On top come costs built into the price: a taker margin of about 4 basis points, which is the solver's profit, and the gas a solver spends on three transactions, to fulfil the order, to send the unlock and to claim.

The page's own example sells 1,000 USDC on Arbitrum for USDC on Polygon: a flat fee of 0.001 ETH, a variable fee of 0.40 USDC, a taker margin of 0.40 USDC and operating expenses of about 0.03 USDC, so the user receives about 999.2 USDC on Polygon and sees 0.001 ETH leave the Arbitrum wallet. The flat fee is the line to watch on small transfers, because it is a fixed amount that does not shrink with the order.

Solver and Relayer Economics: Fees, Capital and Speed

A solver or relayer earns the gap between what you deposit and what it delivers, and that gap has to cover real costs, which both protocols' documentation states plainly.

What the fee pays for

Across's documentation defines the total fee as the amount deposited on the origin chain minus the amount received on the destination chain, and splits it into two parts (Fees in the System, read 20 October 2026). The liquidity provider fee compensates the providers whose capital lets the protocol rebalance between chains. The relayer fee covers the relayer's gas on the destination chain, the opportunity cost of capital locked until repayment, and the capital it puts at risk.

The same page names what puts that capital at risk: software bugs in the relayer's implementation, chain reorganisations that could reverse a filled transaction, and settlement delays. It also says the liquidity provider fee is zero when the relayer takes repayment on the chain where the deposit was made, because no rebalancing between chains is needed.

A dated quote, broken down

A live quote shows the parts in practice. At 04:59 UTC on 20 October 2026, Across's Swap API quoted 99.985859 USDC on Base for 100 USDC sent from Arbitrum, a bridge fee of 0.014141 USDC. The quote split that fee into 0.01 USDC for the relayer's capital, about $0.0041 of gas on Base and nothing for liquidity providers, and gave an expected fill time of one second.

That quote is one amount at one minute. Across's fee page tells integrators not to cache fee responses, because fees change with market conditions, pool utilisation and gas prices, so the only quote that applies to your transfer is the one you sign.

The capital in the middle

Relayers front their own capital on the destination chain and wait to be repaid. Across's documentation puts that wait at about 1.5 hours, the minimum interval between the bundles in which fills are settled, and says relayers can request repayment on any chain Across supports, not necessarily the one where the deposit was made (Actors in the System, read 20 October 2026).

Liquidity providers make that choice possible: the same page says their capital lets Across's HubPool contract on Ethereum rebalance funds between the SpokePool contracts on each chain to honour those requests. The fee page charges their fee only when repayment is taken on a chain other than the deposit's.

Speed, competition and stale quotes

Speed is what the capital buys. Across's documentation says relayers are the actors that make fills of about 2 seconds possible, and that some deposits give one relayer exclusive fill rights for a period, after which any relayer can fill (read 20 October 2026).

deBridge's overview describes a race of its own: an order to exchange 1,000 USDC on BNB Chain for 990 USDC on Solana would bring 10 USDC of profit to the solver that fills it first, so solvers compete for profitable orders. Its fee page warns that a quote goes stale if the user signs more than about 30 seconds after fetching it, which is why apps refresh quotes until the transaction has been sent.

Across: A Worked Example of Relayers and Settlement

Across is a relayer network that settles optimistically, and its documentation describes each actor's job in enough detail to follow one transfer from start to finish. This section sets out the design as described there on 20 October 2026; the next covers what happened on Solana in July 2026.

The deposit and the escrow

A transfer starts when the user, or a contract acting for the user, calls depositV3 on Across's SpokePool contract on the origin chain, specifying the destination chain, the output token and amount, the recipient, a fill deadline and an optional message (Intent Lifecycle, read 20 October 2026). The SpokePool pulls in the user's tokens and holds them in escrow until the intent is filled and settled.

The documentation explains why the escrow comes first: transfers between chains lack atomicity, so the relayer needs assurance that the user's funds exist before it fronts capital on the destination chain. The SpokePool then emits an event, V3FundsDeposited, carrying the intent's parameters, and relayers subscribe to those events to find intents they can fill.

The relayer's fill

A relayer fills by calling fillV3Relay on the destination chain's SpokePool with its own tokens, and names the chain on which it wants to be repaid. The SpokePool marks the intent as filled, so no other relayer can fill it again, and emits a FilledV3Relay event that apps use to show the user that the transfer has arrived (read 20 October 2026).

At this point the user has been paid and the relayer has not. Across's documentation lists the relayer's steps as monitoring deposit events, weighing fees against gas and capital lock-up, filling and requesting repayment, after which it receives the user's input amount minus the liquidity provider fee once the bundle settles.

Settlement: bundles, bonds and disputes

Settlement happens in the background. A dataworker, which Across's documentation describes as a whitelisted off-chain actor, validates fills against deposits across all chains, aggregates the valid fills into payment lists and proposes the result as a bundle to the HubPool on Ethereum, posting a bond with it (Actors in the System, read 20 October 2026).

Each bundle then enters a challenge period secured by UMA's Optimistic Oracle. Anyone can dispute a bundle by posting a bond of their own, a disputed bundle goes to a vote of UMA token holders, and the documentation says the system needs only a single honest actor willing to dispute invalid proposals to remain secure. Our guide to optimistic and zero-knowledge rollups explains the same assume-valid-unless-challenged idea as it applies to layer-2 networks.

If no relayer fills the deposit

A deposit that no relayer fills before its deadline is refunded, but not at once. Across's refunds page, read on 20 October 2026, says the expired deposit is included in the next settlement bundle, which must pass the challenge period before the refund is executed, so refunds can take several hours to arrive. By default the refund goes back to the depositor on the origin chain.

The same page calls such refunds rare on mainnet and gives extremely large transfers, unusual token pairs and temporary relayer downtime as the common causes, so a large transfer is also where an unfilled deposit ties up the most money for those hours.

Who stands behind Across in October 2026

Across's governance token is being wound down: after a Snapshot vote from 31 March to 7 April 2026 closed with voting power of 44,693,928 for and 4,144,952 against, Risk Labs announced on the Across forum on 17 September 2026 that Across Protocol had been transferred to a new company, Across, Inc.; until 8 January 2027 the exchange portal, read on 20 October 2026, lets ACX holders redeem 0.04375 USDC per ACX or apply, subject to KYC and a minimum, for equity in that company at one share per token, after which, the forum post says, ACX will be deprecated and have no governance, utility or economic function.

Risk Labs also ran the relayer at the centre of the incident below: Across's post-mortem of 24 July 2026 calls it the Risk Labs relayer.

When a Fill Goes Wrong: Who Absorbs the Loss

Every intent design has to say in advance whose money is gone if a solver or relayer pays out on a transfer that should not have been paid. In the two designs on this page, the rules put that loss on the party that paid, and Across's Solana incident of July 2026 is a dated case of the rule at work. The wider record of bridge failures is on our page on bridge hacks and why bridges get drained.

The design rule: only valid fills are repaid

Across's documentation, read on 20 October 2026, says every fill is matched against its deposit on the origin chain and only valid fills are aggregated into the lists of relayers to repay. It lists software bugs that could lead to invalid fills among the risks relayers carry, next to gas costs, capital lock-up and chain reorganisations. A relayer that pays out against a deposit that never happened therefore has nothing to be repaid from.

deBridge draws the same line in time: its overview puts the solver's risk between the fill and the unlock of the maker's deposit, and calls a reorganisation of the source chain a risk solvers take on consciously (read 20 October 2026). ERC-7683's security section asks auditors the matching question: whether a solver that follows a resolver's instructions correctly can be led into an insecure position.

The rule protects users only while the escrow and settlement contracts work as designed. A fault in the contract that holds deposits, or in the process that approves settlements, is a different kind of failure, and it can reach deposits and pooled funds rather than one relayer's capital.

Across on Solana, 17 July 2026

At 08:36 UTC on 17 July 2026, Across posted on X: "At ~5:30 AM UTC today, Across was attacked on Solana. User funds are safe. No users were affected, and all bridge transactions have been completed." The same post said Solana deposits had been disabled and the protocol was otherwise operating unaffected.

The Solana blockchain records the pause. Two transactions at 08:55:25 UTC that day, read through a public Solana node on 20 October 2026, each delivered a message to Across's SpokePool program on Solana that ended in an instruction named PauseDeposits in one and PauseFills in the other.

At 17:06 UTC the same day, Across posted an update: "Solana deposits are re-enabled. Across is fully operational." It added that no user funds were lost, that "All in-flight Solana transfers were completed or fully refunded" and that relayer losses were contained to Risk Labs and did not affect the protocol or users. On 24 July 2026 Across linked a post-mortem titled "Across Relayer Incident: Post-Mortem", which opens by saying that an attacker exploited a bug in the Risk Labs relayer's off-chain event-reading software for Solana.

This page gives no figure for the amount lost: none of the parts of Across's statements readable without an X account on 20 October 2026 states one.

The fix in Across's software

The mechanism can be read in Across's published code. Version 4.4.13 of the @across-protocol/sdk package, published to the npm registry at 09:50 UTC on 17 July 2026, added a check to the code that reads Across's events on Solana: only genuine event instructions of Anchor, the framework the Solana program is written in, which begin with a fixed 8-byte tag, are decoded, and anything else is skipped (registry record and package source, read 20 October 2026).

The comment beside the new check explains what it stops. Without it, any program could forge an event by calling into the SpokePool with crafted data, for example through a read-only instruction named GetUnsafeDepositId, and the client would decode the result as a real FundsDeposited or FilledRelay event: the deposit and fill records that relayers act on. In plain terms, the reading software trusted anything shaped like a deposit record, and the fix makes it check where the record came from.

Solana routes as read on 20 October 2026

Three dated observations describe the Solana side of Across, from the day of the incident to the day this page was written. They are listed as read, without a conclusion drawn on Across's behalf.

• 17 July 2026, 17:06 UTC: Across's update on X said "Solana deposits are re-enabled".
• 20 October 2026, 04:54 UTC: Across's API listed 1,041 routes and none to or from Solana, and answered a request for limits on USDC from Arbitrum to Solana with "Route is not enabled." At the same time, the state account of Across's Solana SpokePool read paused deposits and paused fills, both set by the transactions of 08:55:25 UTC on 17 July 2026, with no instruction in the account's history since then that lifts them.
• 20 October 2026, 04:59 UTC: a quote from Across's Swap API for USDC from Arbitrum to Solana named "cctp" as the bridge provider, while the same request for Arbitrum to Base named "across".

Whatever app you use, the route details in its quote name the protocol that will carry your transfer, and the same app can send two routes through two different mechanisms.

Chain Abstraction: What It Changes for You

Chain abstraction takes the intent idea one step further, from a single transfer to the whole experience of using an app on several chains.

The bridge you no longer choose

In Chainlink's explainer, last updated on 26 March 2026 and read on 20 October 2026, you sign a single message stating what you want, for example 100 USDC on one chain in exchange for ETH on another, and a network of solvers competes to deliver it, handling the bridging, gas payments and routing in the background. The explainer calls chain abstraction a user experience framework for using decentralised applications, or dApps, and says it relies on intent-based systems.

What changes for you is the choice. You no longer pick a bridge, a gas token or a route, because the app and its solvers pick them for you, and you no longer see them unless the app shows you. The trust does not change: the escrow, the settlement rules and the solvers are all still there, behind one signature.

What still depends on you

The same explainer notes that solvers often take on the wait by giving users soft finality, an early result, while on-chain settlement completes, and that doing so requires deep liquidity and risk management (read 20 October 2026). That early result is the solver's capital, exactly as in the intent designs above.

When an app offers to handle the chains for you, these are the questions to put to it:

• Which protocol carries the transfer, and does the quote name it?
• Where does my deposit wait, and for how long, if nobody fills the order?
• Which contract am I approving, and for how much?
• Who runs the solvers or relayers, and what happens if one of them is wrong?

Hyperlane: Permissionless Messaging, Chosen Security

Hyperlane works a layer below the products above. It carries messages between chains, and token transfers can be built on those messages, so the way a message is verified decides how safe the transfer can be.

Security chosen per application

Hyperlane's documentation, read on 20 October 2026, says it is secured by Interchain Security Modules: smart contracts on the destination chain that verify that a message being delivered there was really sent on the origin chain. An application can use the default module of Hyperlane's Mailbox contract, which is a multisig module, or configure, compose and customise a module of its own.

The documentation's own example of composing modules is an application that requires a message to be verified both by a multisig module with validators from the Hyperlane community and by a module that checks that a quorum of Wormhole's validator set verified it. Because each application decides, the name Hyperlane on a route tells you which messaging system is used, not which checks your transfer passes.

The default validators, by chain

Hyperlane publishes the validator sets behind its default multisig module. On its list for mainnet chains, read at 05:09 UTC on 20 October 2026, messages from Ethereum needed signatures from 6 of 9 listed validators, messages from Arbitrum, Base and Optimism needed 3 of 5, and messages from Solana needed 3 of 4.

Validators sign checkpoints, the Merkle roots of the messages sent through the Mailbox, and the documentation says Hyperlane has no enshrined validator set: anyone can run a validator, and it counts for an application only if that application's multisig module includes it. The thresholds above apply to applications that keep the default. Our guide to multisig wallets explains how an M-of-N threshold decides how many private keys an attacker has to steal.

Two different jobs called relayer

The word relayer means different things in different protocols. In Hyperlane, the relayer is a courier: the documentation says validator checkpoints are public, anyone can fetch the signatures and deliver a message, and the relayer merely provides a convenience service for message senders (read 20 October 2026). The destination's security module still decides whether the message is accepted.

In Across, the relayer pays you with its own tokens and waits to be repaid. When a protocol's documentation mentions relayers, check which job it means: a courier's exposure is the gas it spends on delivery, while a capital-fronting relayer's exposure is the amount it pays out.

When an Aggregator Earns Its Extra Contract

An aggregator is worth its extra contract when it does a job you would otherwise do worse by hand: comparing several bridges for the same transfer, or combining a swap and a bridge in one signed route. It is harder to justify when a simpler path exists.

• Your funds are on a cryptocurrency exchange that lists the destination network: the exchange holds them in custody until you withdraw, and a withdrawal straight to that network needs no bridge of your own, as our bridges guide on safer paths explains.
• You hold native USDC and both chains are on Circle's CCTP list: the issuer's own route burns USDC on one chain and mints it on the other, with no aggregator contract in front of it, as our guide to stablecoin bridging and CCTP explains.
• You can wait for a rollup's own bridge: the canonical route takes longer but adds no third party, as our guide to layer-2 fees and bridging sets out.

Five checks before you sign a route

• Read the route: which bridge, solver or provider it names, and whether that matches what you expected.
• Size the approval: approve the amount of this transfer, or close to it, and revoke the approval afterwards.
• Compare the numbers: the minimum received against the estimate, and the total cost against a direct route.
• Know the exit: the fill deadline, the refund or cancellation path and how long a refund takes.
• Test first: send a small amount, keep its transaction hash and wait for it to arrive before you send the rest.

Reach the app from an address you typed or bookmarked, never from a link in a message or an advert; our crypto scam protection guide covers the checks to run before you sign anything. Whether a swap inside a route counts as a taxable disposal where you live is a separate question, covered in our guide to taxable events in swaps and bridges.

If you are still deciding which network to keep your funds on, so that you need fewer transfers in the first place, our comparison of Arbitrum, Optimism and Base sets out how the three networks differ.

Conclusion

A bridge aggregator is a search engine with a contract attached. It can find a better rate or a faster route than you would by hand, but it adds one more contract in the path, usually with permission to move your tokens, and LI.FI's report on 16 July 2024 shows the price of that permission: wallets with infinite approvals were drained through a newly added facet, while finite approvals, the report says, were not affected.

Intents change the order of events rather than the amount of trust. You sign an outcome, a solver or relayer pays you first with its own capital, and the protocol checks the fill before it repays them. In deBridge's design and in Across's, the rules put the loss from a bad fill on the party that paid, and Across's statements of 17 July 2026 described its Solana losses as contained to Risk Labs, the relayer's operator, rather than falling on users.

That is a rule working as written, not a promise that every failure lands on a relayer. Chain abstraction hides the same machinery behind one signature, and Hyperlane shows how much of the security beneath it each application can choose. The questions stay the same: which protocol carries the transfer, where your deposit waits, what you have approved, and who pays if a fill is wrong.

The figures here will move. Fees, routes, validator sets and pause states change without notice, so check the quote, the documentation and the state of the route again on the day you transfer, and treat every figure on this page as the value read on 20 October 2026. If a quote names a protocol you do not recognise, read that protocol's own documentation and latest announcements before you sign, and look for any notice of a pause.

Sources

Every primary source below was read on 20 October 2026. Each entry names the document and what it supports on this page. The last entries point to the pages of this site that cover the neighbouring questions.

• LI.FI documentation, System overview — the API, the Diamond contract and its facets. docs.li.fi
• LI.FI documentation, Request routes — multi-step routes, route ordering, allow and deny lists, the integrator fee and slippage. docs.li.fi
• LI.FI documentation, SDK changelog — version 4, April 2026, adopted by Jumper. docs.li.fi
• LI.FI, Security Incident Report 16th July, published 18 July 2024 — the facet, the infinite approvals and the response. li.fi
• ERC-7683: Cross Chain Intents, draft, created 11 April 2024 — orders, solvers, the order lifecycle and the security considerations. eips.ethereum.org
• LayerZero documentation, Stargate Finance — Stargate's pools and the LayerZero messaging behind them. docs.layerzero.network
• The deBridge documentation, DLN protocol overview — creating, filling, unlocking and cancelling orders, and the split of risk. docs.debridge.com
• The deBridge documentation, DLN fee structure — the fees, the worked example, quote staleness and the approval advice. docs.debridge.com
• Across documentation, Actors in the System — relayers, liquidity providers, the dataworker and UMA's Optimistic Oracle. docs.across.to
• Across documentation, Fees in the System — the fee components and the advice not to cache quotes, which the Swap API returns. docs.across.to
• Across documentation, Intent Lifecycle — the deposit, the escrow, the fill and settlement. docs.across.to
• Across documentation, Refunds — expired deposits and how long a refund takes. docs.across.to
• Across on X, 17 July 2026, 08:36 UTC — the statement on the attack. twitter.com
• Across on X, 17 July 2026, 17:06 UTC — the update on deposits, transfers and relayer losses. twitter.com
• Across on X, 24 July 2026 — the link to Across Relayer Incident: Post-Mortem. twitter.com
• The npm registry, @across-protocol/sdk 4.4.13, published 17 July 2026 at 09:50 UTC — the event check. registry.npmjs.org
• Across API, limits for USDC from Arbitrum to Solana — the answer at 04:54 UTC. app.across.to
• Solana Explorer, the state account of Across's Solana SpokePool — the pause flags. explorer.solana.com
• Solana Explorer, the PauseDeposits transaction of 17 July 2026, 08:55:25 UTC. explorer.solana.com
• Across forum, The Across token buyout portal is now live, 17 September 2026 — the transfer to Across, Inc. and the end of ACX. forum.across.to
• ACX Token Exchange portal — the two routes and their 8 January 2027 deadline. exchange.across.to
• Snapshot, The Bridge Across proposal — the voting window and the final tally. snapshot.box
• Chainlink, What Is Chain Abstraction?, last updated 26 March 2026 — the definition and soft finality. chain.link
• Hyperlane documentation, ISM Overview — Interchain Security Modules and the default multisig module. docs.hyperlane.xyz
• Hyperlane documentation, Validators — checkpoints, open validator sets and the relayer's role. docs.hyperlane.xyz
• Hyperlane documentation, default ISM validators for mainnet chains — the thresholds at 05:09 UTC. docs.hyperlane.xyz
• How layer-2 networks work, and why moving funds between them needs a bridge at all, is on our layer-2 guide.
• Incidents by date, with their causes and what they teach, are on our bridge hacks guide.
• Native and bridged USDC, and how CCTP burns and mints it, are on our stablecoin bridging guide.
• How to read, limit and revoke a token approval is on our approval hygiene guide.
• Fake bridge and swap sites, and how drainers work, are on our wallet drainer defence guide.
• Canonical rollup bridges, withdrawal windows and fees are on our layer-2 fees and bridging guide.
• Optimistic verification and challenge periods are on our rollups guide.
• M-of-N signing thresholds are on our multisig guide.
• Limit and market orders are on our order types guide.
• The tax treatment of swaps and bridge transfers is on our taxable events guide.
• The checks to run before you sign anything on a bridge or swap site are on our scam protection guide.
• How Arbitrum, Optimism and Base differ as places to keep funds is on our Arbitrum, Optimism and Base comparison.

Frequently Asked Questions

What is a bridge aggregator?

A bridge aggregator compares routes across many bridges, exchanges and solvers and sends your transfer through the one it ranks best. LI.FI, for example, describes an API that fetches prices from those sources and a main contract that hands each transaction to a separate contract for the chosen protocol (documentation read 20 October 2026). It can find a better rate, but its own contracts join the bridge's in the path.

What is an intent?

An intent is a signed order that states the result you want, such as an amount of USDC on another chain, rather than the steps to get there. The draft standard ERC-7683, read on 20 October 2026, describes an order as an offer of payment in exchange for the fulfilment of a set of requirements, carried out by solvers, also known as fillers. In bridge designs, the solver usually pays you first and is repaid from your deposit.

How does Across work, and what happened in July 2026?

You deposit into Across's SpokePool contract, a relayer pays you on the destination chain from its own tokens, and the protocol repays the relayer after a bundle of fills passes a challenge period secured by UMA's Optimistic Oracle (documentation read 20 October 2026). On 17 July 2026, Across said on X that it had been attacked on Solana and had disabled Solana deposits, and later that relayer losses were contained to Risk Labs. On 20 October 2026, Across's API listed no route to or from Solana.

Who pays if a solver or relayer makes a mistake?

In the designs on this page, the solver or relayer does. Across's documentation says fills are matched against deposits and only valid fills are repaid, and deBridge's documentation puts the solver's risk between its fill and the unlock of the user's deposit (both read 20 October 2026). A fault in the contracts that hold deposits is a different failure, and it can reach users.

Should I give a bridge aggregator an unlimited token approval?

An unlimited approval lets the approved contract move your whole balance of that token for as long as the approval stands. LI.FI's report of 18 July 2024 says its incident of 16 July reached wallets with infinite approvals for its contract and did not affect finite approvals. Approve the amount you are moving where your wallet allows it, and revoke the approval afterwards.

What is chain abstraction?

Chain abstraction is the aim of letting you use an app without managing bridges, gas tokens or network details yourself. Chainlink's explainer, last updated 26 March 2026 and read on 20 October 2026, says it relies on intent-based systems in which solvers handle bridging, gas and routing in the background. The bridge still exists; you simply stop choosing it.

What does Hyperlane do?

Hyperlane is a permissionless protocol for sending messages between chains, on which token transfers can be built. Its documentation, read on 20 October 2026, says each application can choose its security through Interchain Security Modules, which verify on the destination chain that a message was sent on the origin chain. On its default list read at 05:09 UTC that day, messages from Ethereum needed 6 of 9 validator signatures.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.