Crypto Aggregation Theory (ft. Bridges)

Written by Arjun Chand and Mark Murdock

 

Introduction

Previously, we defined crypto aggregation theory by tweaking a framework introduced in Stratechery during the 2010s that described web2 business models pioneered by Airbnb, Netflix, and Uber.

In this article, we narrow down the scope of crypto aggregation theory to bridge aggregation: specifically analyzing the complex state of the bridge industry, how bridge aggregators work, why bridge aggregators are necessary, and the challenges in building a bridge aggregator.

Snapshot of the Bridge Ecosystem

There are now 100+ bridges connecting various EVM and non-EVM chains, each with a different set of strengths and tradeoffs.

The key to understanding the complex “bridge ecosystem” starts with something called the interoperability trilemma. This basic theory, originally introduced by Connext, leads to design tradeoffs in bridge verification methods, creates what we call a “trust spectrum” across different bridging solutions, and is the reason that “bridge” has grown into such a loaded term.

Let’s jump in.

The Interop Trilemma: Choose Your Bridge Tradeoff

Connext’s interoperability trilemma states that bridges (or interoperability protocols) can only have two of the following three properties:

• Trustlessness - security equal to the security of the underlying blockchain.
• Extensibility - ability to support any blockchain.
• Generalizability - capable of transferring arbitrary cross-chain data.

As per our extensive research, we do not believe the “bridge ecosystem” includes a single bridge that is perfectly secure, able to connect to every chain instantly, and capable of sending any type of message. In truth, the “bridge ecosystem” is known for hacks (bad trustlessness), slow endpoint deployments on new chains (bad extensibility), and low development of natively cross-chain applications (bad generalizability).

Therefore, due to the Interop Trilemma, bridges are forced to optimize for factors like speed, cost, or security and make design decisions that maximize, minimize, or compromise on trust, extensibility, generalization. Because of these tradeoffs, many bridge designs exist, with different architectures, characteristics, and verification methods — which we will dive into below.

Bridge Verification Mechanisms

Based on the properties of the interop trilemma, developers have produced roughly four bridge verification mechanisms for transferring data across chains:

• Externally verified: multi-party custody (MPC) systems — These systems rely on a third-party group of validators to confirm transactions between blockchains. Oftentimes externally verified bridges are faster and cheaper to transact on, though less secure due to reliance on third-parties to confirm blockchain transactions. Example: Multichain.
• Locally verified: atomic locks — These systems use self-executing smart contracts to exchange assets on the source chain for assets on the destination chain. Here, the smart contracts replace third-party validators, which makes this mechanism trust-minimize (though expensive and slow). Example: Thorchain.
• Hybrid verification: conditional transfers — These systems offer the speed of atomic swaps and the security of optimistically verified protocols. Here, users receive funds on the destination chain almost instantly via LPs who front liquidity to users in exchange for a fee. The LPs receive a user’s funds on the source chain and rebalance their assets using the bridge. As a result, on the condition that an LP is available and able to front liquidity to the user, transactions are executed; if this condition fails, a slow route is activated where the messaging bridge is utilized to bridge user funds. Example: Hop — users get their desired assets immediately, while liquidity providers (Hop Bonders) obtain assets within a day through the Hop optimistic messaging system.
• Natively verified: light client relays — These systems verify the state of one blockchain on other blockchains to confirm cross-chain transactions. Here, actors monitor events on the source chain, generate proof of work, and forward those proofs to light clients on the destination chain. Then, the validity of proofs for specific transactions on the destination chain is checked against the records kept by the light clients on the source chain. Natively verified bridges are considered the most secure way to move data across chains, but are notorious for lacking extensibility and for being very expensive to build with. Example: IBC.

Now, that is a rather technical explanation for “verification” mechanisms. Thankfully, Catalyst founder 0xjim created a simple mental model for understanding bridge verification mechanisms that is much easier to follow. In 0xjim’s words, bridge verification mechanisms can be boiled down to “what team” is confirming a certain transaction:

• Team Human — these bridges use multi-signature implementations that require third-party entities to run full nodes and verify transactions by attesting to the validity of a transaction. If a transaction receives threshold signatures, it is considered verified. Such implementations make the trust assumption that entities care about their reputation and thus won’t be dishonest. Team Human is a bridge verification mechanism based on a few large wallet/node operators voting on whether a transaction 1) happened on the source chain and 2) should be executed on the destination chain. These bridges are normally fast and cheap, but make many trust assumptions. Examples: Multichain, Wormhole.
• Team Economics — these bridges also use multi-signature implementations — but add a Proof of Stake safeguard that adds monetary risk as well as reputational risk to multi-sig voters. The implementation is similar to ‘Team Human’ but in addition to trusting external entities to vote on transactions truthfully, there’s an economic incentive for them to not lie as their collateral can be slashed if they act maliciously. Like with Team Human, these bridges are normally fast and cheap, but make many trust assumptions. Example: Celer’s cBridge, Axelar, deBridge.
• Team Game Theory — these bridges break up the bridging process into two (or more) separate jobs done by two (or more) separate entities, thereby ensuring security by dis-incentivizing coordination between entities. These bridges are often a bit more expensive and slower than Team Human or Team Economics designs, but rely on fewer trust assumptions. Examples: LayerZero or Optimistic bridges like Rainbow, Beamer.
• Team Math — these bridges perform on-chain light client verification by leveraging zk tech and succinct proofs. However, since Zero Knowledge SNARK research is still in an early stage, zk light clients are limited in scope. These bridges are considered highly secure but are difficult to build and expand to different chains. Examples: Succinct, Electron Labs, and Polymer.

At this point it should be clear that decisions made at the “interop trilemma” have major consequences on how a bridge verifies transactions between blockchains.

Being able to understand and rank interop trilemma tradeoffs between bridges is crucial for developers and users, as the specific use-cases users/devs are going to a bridge for will most likely determine what type of tradeoff they want to make. To help developers and users do so, we coined the term that “with bridges, trust is a spectrum” at LI.FI.

The “trust spectrum” shows that on one end, there are “trusted” bridges that rely on external verification methods to confirm transactions while on the other end, there are “trustless” bridges that attempt to only confirm transactions based on native chain communication, and, in the middle, there are TONS of different bridges relying on economics and game theory.

The “trust spectrum” is not a judgement — it is just a way to visualize tradeoffs between verification methods that arise after a bridge chooses its path along the interop trilemma. Nothing is right or wrong, it’s just tradeoffs.

Here’s how LI.FI sees the current landscape of bridges playing out on the “trust spectrum”:

Types of Bridges: Choose Your Bridging Style

In addition to varied verification methods, bridges also differ in the types of transactions that are conveyed between blockchains. In other words, “bridge” has become a very popular term.

Here are just a few ways to differentiate the umbrella term of “bridge” in the crypto space (with each having certain design tradeoffs mentioned above):

1. Token Bridges - third-party bridges built to facilitate token transfers.

• a) Liquidity networks

  Enables the exchange of assets on source chain for the desired asset on the destination chain using liquidity pools. For example, Bob has ETH on Ethereum and wants to bridge it to Arbitrum. The liquidity network matches Alice with Bob, an LP who is willing to swap ETH on Arbitrum for ETH on Ethereum for a fee. Examples: Hop, Across, Connext Amarok.

• b) Wrap and Mint bridges

  Enables tokens to be minted on new chains by securing tokens on the source chain via a third party multisig setup. Examples: Portal, Multichain.

2. Data Bridges — third-party bridges built to facilitate data transfers.

• a) Arbitrary messaging bridges (AMBs) 

  Enables the transfer of any type of data, (including tokens, contract calls, the state of a chain) from blockchain to blockchain. These protocols provide the foundation on which cross-chain applications, including token bridges, are built. Examples: LayerZero, Axelar, Wormhole.

• b) Storage proof protocols 

  These are cross-chain infrastructure systems that leverage storage proofs (a way to track information across chains) to enable dApps to read the state of different chains and facilitate cross-chain use-cases. These protocols are still in the early stages of development but could effectively remove the need for messaging bridges to share information across different chains. Examples: Lagrange, Herodotus.

3. Native Bridges — first-party bridges built to facilitate data and token transfers.

• a) Canonical bridges

  Built to bootstrap liquidity on a specific blockchain. Such bridges typically support bridging between two chains and are originally designed by the foundation or team behind the blockchain in question. Examples: Rollups like Arbitrum bridge, Optimism bridge and foundation led bridges like Avalanche bridge, Binance bridge.

• b) Stablecoin bridges

  Enables stablecoins to be sent across chains natively (i.e., without locking it on one chain and minting a wrapped version on the other). These bridges make it possible for stablecoins issuers (like Circle and Maker) to mint virtually unlimited amounts of stablecoins on a destination chain. This improves the liquidity of the stablecoin and allows dApps/users to bridge large amounts in a capital efficient manner. For instance, if a dApp wants to bridge 100M USDC from Arbitrum to Optimism, Circle’s stablecoin bridge, CCTP, can simply burn 100M USDC on Arbitrum and mint 100M USDC on Optimism. Examples: Circle’s CCTP for USDC and Maker’s Teleport for DAI.

4. Miscellaneous Bridges

• a) NFT bridges

  Operate similarly to any other bridge type but these bridges specialize in enabling the movement of NFTs across chains. Typically, to move an NFT from Chain A to Chain B, the NFT is locked or burned on Chain A and minted on Chain B. Examples: Wormhole NFT Bridge, NFTHashi.

• b) Centralized Exchanges 

  These are not known as ‘bridges’ as we know them today but they have effectively served the same purpose (enabling users to move tokens across chains) for a long time — although in a highly centralized manner with an arguably clunk and multi-step user experience. For instance, if a user had funds on the Ethereum network and wanted to bridge them to Polygon, they could withdraw their funds from a centralized exchange, convert them to a stablecoin, and then use that stablecoin to purchase MATIC tokens that could be withdrawn on the Polygon network. Examples: Coinbase, Binance.

Bridge Industry TL;DR

As we’ve shown above, “bridging” is just tradeoffs all the way down.

No bridge is a perfect solution in terms of security, speed, or connectivity across every blockchain. As a result, the bridge ecosystem has a wide range of designs and flavors.

In our opinion, this leaves the “bridge ecosystem” with four major problems:

1. Liquidity fragmentation — despite bridges originally being introduced to unify liquidity across chains, we see that liquidity is now fragmented across various token standards, wrapped assets, and bridge specific liquidity pools on different chains.
2. Developer overhead — developers have an abundance syndrome — there’s a problem of plenty when it comes to choosing a bridge to build on and deciding which one to use is simply a headache.
3. Single point of failure — when a dApp or business decides to build on a single bridge, therein lies a single point of failure for future business logic to be corrupted (if the bridge were to ever be successfully attacked).
4. Bad user experience — bridges are clunky and specialized, with different bridges offering varying degrees of UX depending on the token/chain combination a user requests. No bridge offers the best experience from a liquidity perspective on EVERY chain, forcing users to manually hunt for the best bridge given unique priorities.
5. Bridge discovery problem — users find it challenging to identify the most suitable bridge for their specific transaction requirements.

Entering Stage Left: Bridge Aggregation

The wide variety (and lack of a perfect solution) of bridge design, verification mechanisms, and bridge types pave the way for the aggregation of bridges.

Why Bridge Aggregation

Bridge aggregation is a crucial innovation in the rapidly evolving multi-chain ecosystem. As the number of blockchains and liquidity across chains continues growing, the need for simple cross-chain transactions becomes increasingly essential. Bridge aggregators address this need by connecting bridge-specific liquidity sources and offering users and dApps a range of bridging options for cross-chain transactions.

Above is a TL;DR of the following three sections, which outlines the case for bridge aggregation by examining the lack of a “winning” bridge type, fragmented liquidity, and the ability to create an above-average UX:

No Bridge-Type Rules Them All

No single bridge-type is perfect for every use-case, as each bridge has its own strengths and weaknesses based on the trade-offs made at the interop trilemma level. Bridge aggregators recognize this diversity and incorporate multiple bridge-types into their platform, ensuring that users and dApps can access the best possible bridging solution for their specific needs.

This is very important from a security perspective because, cards on the table, bridges have historically acted as honeypots for hackers to attack. Five of the largest 15 DeFi hacks of all time stem from bridge-related exploits, resulting in $2 billion+ in value drained in roughly 24 months.

Notably, bridge hacks have not been condensed to a single bridge verification mechanism — instead, hackers have exploited a variety of bridge designs. Ronin employed a 4/9 multi-sig. Wormhole operated as a PoA network with 19 well-known validators. Nomad depended on an optimistic design. Yet, each time, an attacker circumvented these bridge designs to drain protocols (by phishing or by contract flaw).

With all of this in mind, it cannot be said that any one bridge design is better than another. Theoretically, as a crypto-native company, we want trustless bridges utilizing light clients, optimistic verification, and/or liquidity networks to thrive. However, these bridges are oftentimes slow, expensive, and lack extensibility. Bridges relying upon multi-sigs or other external validation systems are less optimal from a security standpoint, but necessary at this point and can bring major benefits like cheap and fast transactions.

Every bridge-type has flaws. Canonical bridges rely on either 1) rollups working correctly or 2) the reputation of the team behind the bridge. Liquidity networks are limited by 1) only being able to send tokens and 2) the number of tokens available on the destination chain. Externally validated bridges require a user to trust a small group of validators to sign off on each transaction. Even optimistically verified bridges (Nomad), bridges that rely on game theory (LayerZero), and even zk-based bridges (Succinct) make trust assumptions a few steps above native verification between blockchains.

The core idea for a bridge aggregator is that if one of these bridges goes down or is under maintenance, the aggregator is fine, because there are other bridges and their requisite routes to fall back on. If a dApp has built out an xChain feature via an aggregator, be it bridging, cross-chain LP deposits, or just basic any-2-any swaps, a single bridge hack cannot take the feature offline.

Any crypto-native company prioritizes liveness — which is why implementing many bridge designs into a protocol via an aggregator may be a better solution than relying on a single bridge.

To really bring this point home, it is educational to look into the contagion effects of the hacks mentioned above. For instance, Nomad was exploited for $190M and ecosystems like Moonbeam, Milkomeda, and Evmos that relied on Nomad as their go-to bridge for minting wrapped assets saw massive amounts of funds bridge away. Furthermore, dApps that were building on top of Nomad had to find other alternatives (example: Connext was forced to use an alternative approach to build Amarok).

Reduced Fragmentation

Bridge aggregators integrate disparate liquidity sources into one solution, streamlining the user and developer experiences.

In the quest to solve the problem of blockchains existing in siloed environments, a new issue has been created in the form of liquidity fragmentation.

Overall, more connectivity between chains is a good thing, as developers are given more flexibility and features to play with and users can experiment and move funds without friction. However, connectivity granted via bridges comes with one massive issue: instead of at the blockchain level, liquidity is now locked across bridges. Therefore, an individual liquidity source may occasionally become depleted, face capacity constraints, or lack adoption (in the case of token wrappers), thereby leaving users and developers stranded on a certain chain with a token they did not want.

Let’s take a closer look at this, specifically considering liquidity fragmentation (rather than data fragmentation, as this is not an issue yet):

• Locked capital across bridges

Many bridges operate as liquidity networks, connecting pools of tokens across different chains. When users engage in bridging through these systems, they essentially deposit assets into a pool on the source chain and withdraw desired assets from the pool on the destination chain. This design offers simplicity and facilitates fast transactions. However, it also presents a few drawbacks, as capital becomes locked across various liquidity pools of bridges, resulting in capital inefficiencies and also making bridges ‘honeypots’ for attackers.

Users often face challenges when it comes to determining the optimal bridge for their specific needs. Each liquidity network bridge has varying amounts of capital, resulting in different exchange rates, making it difficult for users to assess which bridge offers the best rate. Similar concerns extend to factors like speed and security. Furthermore, liquidity across bridges is often limited and can run low, particularly for popular assets such as gas tokens and stablecoins, especially during periods of high activity or high volume transfers. Consequently, users may encounter prolonged waiting times and delayed transactions or be compelled to seek out alternative bridges. Additionally, finding alternative bridges is not always straightforward because users may be unaware of all their options, and other liquidity network bridges might be facing similar liquidity shortages.

Bridge aggregators address these issues by consolidating multiple liquidity network bridges, allowing users to tap into multiple liquidity sources. This enables users to explore alternative routes and successfully complete bridging transactions by pulling together multiple liquidity sources into a single solution.

• Wrapped bridge assets

Numerous wrapped or synthetic versions of tokens exist across blockchains thanks to bridges “wrapping” a token via lock and mint bridging mechanisms, which makes it difficult for users to identify what wrapped token is being used for the majority of DeFi activities on a certain chain. When it comes to lock and mint bridges, no one bridge is considered standard. Thus, each lock and mint bridge has its own wrapped version assets. For example, USDC on Ethereum has many wrapped versions based on the bridge in question, like Wormhole USDC, anyUSDC for Multichain, etc. As a result, liquidity for one asset is now fragmented into different versions of wrapped bridge assets across chains. Furthermore, if a third-party bridge is hacked, its wrapped tokens are most likely at risk of losing value or being used maliciously on other chains.

Bridge aggregators help alleviate some of the friction in interacting with wrapped tokens by giving users a single portal to move wrapped assets from.

Creating a Simplified User and Developer Interface

By consolidating multiple bridge options into a single platform or tech stack (SDK, API), bridge aggregators significantly reduce the complexity associated with cross-chain transfers.

For users, this is an easy upgrade to understand, as aggregator customers should be able to easily find the most suitable route for their cross-chain transaction based on their unique requirements and preferences without navigating between multiple platforms. (In essence, a bridge aggregator is to cross-chain transactions as Expedia is to hotel bookings.)

We believe that aggregation is an even more powerful unlock for developers.

For dApps, crypto businesses, or web2 payment providers that want to add bridge functionality, bridge aggregators become a no-brainer solution as they offer all the benefits of each of their bridges in a single SDK and/or API.

As discussed at length already, the bridge ecosystem grew at a nearly exponential rate from 2021 to 2023, leading to what we call “abundance syndrome” at LI.FI, referencing the overwhelming amount of research and maintenance required to stay up-to-date in the bridging industry. While it’s often better for the market when users and developers have more options… given the nuances of different bridge designs, there’s also too much complexity in finding the right one for the right use-case.

In reality, neither developers nor users should be expected to keep up with and analyze the technical specifications, security tradeoffs, and upgrades of 100+ bridges — it is not feasible.

For example, from a developer’s perspective, the abundance syndrome comes into the picture when looking to integrate bridges into a dApp. It lies in the different types of bridging solutions (based on both functionality and design) available in the market. For instance, there exists liquidity networks, arbitrary messaging bridges, native bridges (aka canonical bridges), stablecoin bridges, and NFT bridges. Each of these bridges have wildly different validation techniques, security tradeoffs, smart contract risk, and chain connectivity, along with 10+ other differentiating factors.

In addition to an overwhelming amount of information to digest, abundance syndrome also takes into consideration how much developer overhead goes into a dApp building a bridge solution from scratch. For dApps looking to build their own bridging solution, the logistics can quickly get out of hand, as the reality of the bridging ecosystem sets in. For example, single bridge implementations…

• Offer a small # of chains (low extensibility)
• Have limited liquidity available (fragmented liquidity)
• Suffer frequent downtimes or upgrades (maintenance)

Implementing a single bridge results in a risky and maintenance-heavy dependency. Of course, this leads to some dApps attempting to build on top of multiple bridges, becoming a quasi aggregator themselves (ex: PancakeSwap, Sushiswap). However, based on our experience, this type of aggregation is a company in and of itself and maintenance and tech debt will soon pile up quickly — which is why we believe it is a more logical conclusion for dApp to implement an aggregator from the start.

Overall, research and maintenance overhead are major reasons to go with a bridge aggregator from a developer’s perspective. Instead of building a bridging solution from scratch, aggregators exist to take that developer load off of individual dApps. Aggregators also shoulder the responsibility of research overhead on what types of bridges do what, in addition to keeping up with trends in the bridge ecosystem. Furthermore, once a bridge is added to an aggregator’s smart contract, every subsequent upgrade of the bridge should be kept up-to-date by the aggregator, which takes maintenance out of dApp developers hands.

— — —

With these few points in mind, we think it’s clear that bridge aggregation is a necessary innovation for the evolving multi-chain landscape of crypto, and we believe aggregation will play a pivotal role in fostering connectivity across the ecosystem.

To further this case, let’s take a look at how bridge aggregators practically work, specifically in the context of token bridging (be it NFT, ERC-20, etc).

How Bridge Aggregators Work

Bridge aggregators work through a combination of off-chain and on-chain components that cooperate to facilitate efficient cross-chain transactions.

Let’s dive deeper into the workings of bridge aggregators, focusing on the differences between on/off-chain components.

Off-chain Components

• Routing Algorithm

Off-chain routing algorithms are responsible for determining the most efficient route for cross-chain transactions. By comparing quotes from different liquidity sources, such as bridges (and sometimes DEXs), for a specific trade, the aggregator’s algorithm filters, ranks, and recommends routes based on predefined rule sets and user preferences — usually based on security, speed, cost, and number of clicks.

It’s only possible to execute such a routing algorithm off-chain because bridges provide their quotes and routes off-chain. But overall, such a setup benefits the aggregator as it enables it to provide users with all the different routes quickly and cheaply.

• API Communication

Once the optimal route is identified, the off-chain component communicates this information to front-end components via an Application Programming Interface (API). This allows users to view and select from the recommended routes or dApps to execute trades on the user’s behalf.

Onchain Components

• Smart Contracts

When a user selects a specific route for their transaction, the aggregator’s smart contract executes the transaction on-chain.

However, an aggregator’s smart contract does not directly integrate the smart contracts of bridges. Instead, an aggregator’s smart contract executes transactions via “interfaces” which allows them to interact with smart contracts of bridges and DEXs.

For example, to execute a bridging transaction via Stargate, a bridge aggregator would need to import the interface of its smart contract, which would allow the aggregator to call the bridging function of Stargate’s smart contract.

An aggregator’s smart contract abstracts away the complexities of interacting with multiple bridges for developers, as one set of smart contracts can interact with numerous smart contracts via interfaces.

Let’s understand these components by looking at a typical bridging flow via an aggregator:

1. User initiates a bridging transaction on the user interface of the aggregator by inputting required data (source chain, source token, destination chain, and destination token).
2. The routing algorithm in the backend compares quotes from different bridges and filters based on criteria like security, speed, cost, no. of clicks, to find the most efficient route between the inputted source and destination token combination.

It’s important to note again that routing computation is done off-chain, as bridges provide quotes and routes off-chain. Overall, an off-chain algorithm allows aggregators to compute routes quickly and cheaply.

3. Once the best route is identified, the information is communicated to the aggregator’s front-end via an API. From there, the user can select the desired route, and give token approval to the aggregator’s smart contract to initiate the bridging transaction.

4. Lastly, the aggregator’s smart contract calls the specific function of the bridge’s smart contract via an interface and executes the transaction, thereby moving tokens from source to destination chain.

Obstacles for Bridge Aggregators

Building bridge aggregation protocols involves interacting with several interfaces, smart contracts, programming languages, and development environments for various protocols and blockchains. As a result, users and developers must be aware of these risks and conduct thorough due diligence when interacting with bridge aggregators. For instance, one must consider things like whether the aggregator’s smart contracts have been audited, if the deployed contracts have source code uploaded and verified on Etherscan, if the code is open source, etc.

As an aggregator ourselves, we think it is important to point out these considerations and risks, as nobody should use a tool or build on top of a tool without being aware of shortcomings.

Below, we will outline the four most concrete risks associated with bridge aggregation and analyze a few challenges that hinder bridge aggregator developers from creating perfect products.

Risks

1. Trust Assumptions and Smart Contract Risk

Bridge aggregator smart contracts introduce an additional layer of smart contract risk on top of bridges. Bridge aggregators are essentially wrappers for bridges. For example, LI.FI is built on EIP-2535 and uses a diamond contract that executes transactions via bridges by interacting with them through interfaces. As a result, users need to trust the security of the aggregator’s smart contracts.

Considerations:

• Do aggregators introduce additional trust assumptions in the form of smart contracts beyond the underlying bridge?
• Is the aggregator’s smart contract audited?
• When was the most recent audit?
• What was the scope of the audit?
• Is the smart contract code uploaded and verified on Etherscan?

2. Bridge Risk

Aggregators interact with a diverse set of protocols (different bridges), each having different security features and associated risks. When using an aggregator, users rely on them to provide a curated selection of options to minimize potential risks. However, it raises questions about how aggregators decide which bridges to integrate and how they communicate security and risk-related information to users.

Considerations:

• What criteria do aggregators use to select and integrate bridges?
• How do aggregators assess the security of bridges? Do they conduct due diligence on the bridges they integrate?
• How do aggregators ensure transparency in risk and security considerations for users?

3. Off-Chain Components

Aggregators’ off-chain components include parts of their backend infrastructure that are responsible for ensuring that the routing algorithm and all its related aspects are operational. If there’s a failure in any of the off-chain components, the aggregator will be unable to provide quotes and routes to its users — both the ones interacting with its frontend and the ones requesting quotes via its SDK or API.

Considerations:

• How do failures in off-chain components affect users? Will this only result in a delay in quotes or does it also affect user funds?
• Most routing takes place off-chain. Is this a tradeoff that users can live with? Should users live with it?
• Does the aggregator have any backup mechanism in place for when off-chain components are affected and/or fail?

4. Handling Failed Transactions

Bridge transactions via an aggregator can fail for many reasons like slippage, wrong gas price estimates, asset and gas price fluctuations, RPC issues, insufficient gas, and network congestion, among others.

Considerations:

• How do aggregators manage or mitigate potential transaction failures?
• Do they offer features such as bridge insurance in case users experience loss of even a % of their funds due to some of these issues?
• Do they leverage monitoring tools to avoid transaction failures?

Challenges

In addition to the risks above, there are tons of unresolved challenges that aggregators must face.

The most glaring is the lack of standardization across bridges, which makes life difficult for aggregators and keeps developers busy updating APIs, interfaces, and adapting transaction call data requested by various bridges into the correct format. Lack of standardization poses a significant challenge for aggregators, creating complexity and demanding continuous efforts to refactor and ensure transactions execute smoothly. In addition, with the support of a new bridge comes constant maintenance.

The need to enhance and expand chain/bridge/token selection also adds to challenges faced by aggregators. After a certain point, integrating a new bridge may not necessarily enhance the aggregator’s offering. As a result, it’s necessary for aggregators to carefully consider different factors such as supported chains, synergies, and potential integrations on the B2B side when making such decisions. But even then, if a bridge does support a new ecosystem that other bridges don’t, like Solana or Cosmos, there are many challenges for aggregators in terms of adapting to new languages and systems unique to that development environment, while scaling their backend at the same time.

Monetization presents an additional obstacle, as DeFi is not typically favorable to aggregators, leaving them without clear revenue streams. Finding sustainable business models becomes a pressing concern.

On top of all this lies the constant research overhead of answering tough questions that not many people know much about like:

• Is messaging aggregation worth building?
• What do shared sequencers do to bridges in general?
• To more existential crisis questions like — what is a bridge? And when does aggregation end?

— — —

Of course, we didn’t go 5,000 words to give up on the aggregation now.

If you were not convinced by the case for bridge aggregation in the “why aggregation” section and find yourself nodding along to the “risks and challenges,” then we have one extra, bonus argument for you, which is based on Crypto Aggregation Theory.

The Case for Bridge Aggregation

The Bridge Aggregator Flywheel

Ok, so here we’ll be a bit optimistic. The end game for bridge aggregators can be found in the roots of Web2, where Ben Thompson wrote about Aggregation Theory long ago, describing how teams at Uber, Airbnb, and Netflix disrupted incumbents by leveraging the internet for network effects, cheap distribution, and, well, aggregation.

The same thing could happen for bridges, in our opinion. Rather than a single bridge structure to rule them all, bridge aggregation could be the key to an interop future — with different levels of speed, cost, and security being dictated by teams building on top of the aggregator.

It could look something like…

Let us explain.

The optimistic case for bridge aggregators is grounded in their potential to build network effects by acting as essential tools of convenience on the B2B side and building strong user engagement on the B2C side — meaning bridge aggregators can build network effect flywheels by serving powers users (aka degens) on the B2C side by offering novelty in a complex product niche and protocols on the B2B side by becoming a tool of convenience for developers to build cross-chain application on top of.

On the B2B side, bridge aggregators have the opportunity to gain widespread adoption through integrations at the dApp level. By offering a novel solution in a complex product niche, these aggregators can become tools of convenience for dApps, establishing a strong network effect flywheel — bridge aggregators can leverage the efforts of other protocols to drive user acquisition. As more dApps integrate with aggregators, these aggregators can serve as the gateway to accessing a wide range of blockchain networks for consumer-facing dApps, making it easier for them to retain and also attract new customers (integration partners) achieving a strong product-market fit.

On the B2C side, bridge aggregators can build strong user retention moats by owning distribution within a niche and become the central hub for all things related to that niche. This allows bridge aggregators to position themselves as the go-to platform for all types of users that need to bridge funds.

Moreover, an aggregator’s concentrated focus allows it to deeply understand the needs and preferences of power users within the niche, enabling them to tailor their offering accordingly. By offering unique and specialized features, tools, and services, aggregators can provide novelty that differentiates them from general-purpose platforms. This convenience factor would then enhance user engagement, as power users can focus on exploring opportunities, rather than being bogged down by bad UX and a lack of features.

Closing Thoughts

Going back to first principles, we believe that ‘the why bridge aggregators exist in the first place’ is a problem worth solving in order to improve the crypto space.

Despite there being some big hurdles and challenges for aggregators, we believe there’s a scenario where aggregators come out on top in the bridge wars.

Thank you for your time.