At LI.FI, we’ve previously discussed that although intent-based bridges can speed up bridging UX, they are at risk of becoming centralized solutions due to a lack of solvers.

The lack of solvers to execute user intents is a widely known issue. It is an acknowledged problem with a simple-sounding solution – just onboard more solvers – that has not yet been, ahem, solved.

What we’ve realized is that with intents, it’s solvers all the way down. We need to solve this hanging problem of onboarding more solvers, or else risk building a future of finance that looks eerily similar to the traditional finance industry — one where order flow is concentrated in the hands of a few entities.

In this article, we define the structure of intent-based protocols and explore emerging solutions in the market that can potentially address the solver shortage problem by fixing the pain points for solvers.

Let’s dive in!

Intro to Intents

Note: Skip this section if you’re already familiar with intents or have read our previous article.

Intents flip the script of how a transaction works, focusing on the user’s end goal or “intent” rather than the specific steps to achieve it (more on this later). There are two main benefits of intent-based design:

• User experience — The UX feels seamless and is usually fast. Users express an intent and solvers handle the rest. Gas abstraction and other features make the experience smoother than normal transactions. Just-In-Time (JIT) liquidity means no more waiting minutes for transactions. Overall, intent-based experiences are less overwhelming for users, generating the “one-click” feeling that most web2 apps can grant users.
• Execution efficiency — Solvers, who are often professional market makers or protocol teams, handle transaction execution for users. The thesis here is that specialized solvers are better equipped to build a transaction for optimal execution onchain than a basic AMM contract or an end user navigating across multiple apps. Transaction batching and other features like order matching make the intent execution more capital efficient. For users: no more silly errors, wasted resources, and a frustrating onchain experience for users. For applications: no more reliance on simple, gas-inefficient contracts for complex transaction pathways. For LPs, no more latent liquidity sitting in stale on-chain contracts.

Intent-based design is the kernel that has birthed the bag of popcorn called chain abstraction – aka building an application that interacts with multiple chains while feeling like a single, interconnected “crypto” experience.

With Intents, It’s Solvers All The Way Down

Intent-based protocols have three main parts:

• Intent Expression — Users specify a desired outcome on an application. For instance, on a bridge, a user might say they want to exchange 1 ETH on Arbitrum for 1 ETH on Optimism.
• Intent Execution — Solvers, competing in auctions, determine the most efficient way to execute the user’s intent. The winner (e.g., a Relayer in Across) fulfills the request (sending 1 ETH to the user on Optimism).
• Intent Settlement — The solver gets paid for their service (e.g., receiving the user’s 1 ETH on Arbitrum + a small fee). Intent protocol proves that intent was satisfied. However, this is just one aspect of settlement. The bigger picture is that Intent settlement also facilitates capital rebalancing between chains and assets for solvers.

Intents are all well and good – smooth, fast, efficient, simple. But there’s a catch to intent-based design: a lack of solvers.

The Root of Centralization with Intents

Solvers are the backbone of intent-based protocols. They are the entities that actually execute a user’s intent, such as delivering an asset to chain A from chain B.

In a perfect world, solving is a competitive environment, with solvers fighting to fulfill intents at the cheapest price. However, being a solver is tough. However, there are certain barriers to entry for solvers:

• Staking requirements – Some intent-based protocols have a staking requirement for solver’s to participate in their order-flow auctions. For instance, in 1inch Fusion, the top 10 solvers (called resolvers) are allowed to participate in the auctions. These solvers are ranked and whitelisted based on their ‘unicorn power’, that is a metric determined by their staked 1inch tokens (by their solver themselves or by delegates) and the duration of their stake. These staking requirements exist to deter malicious behavior, which is a good thing. The problem? These stakes can be a significant barrier to entry, especially for smaller players who might not have the capital upfront.
• Permissioned systems – Many intent-based protocols are permissioned, meaning they have gatekeepers who decide who can participate. For example, in the case of 1inch Fusion, access is based on unicorn power, while in other systems like UniswapX Beta, participation might require being whitelisted by the protocol that runs the auction. These systems prioritize execution quality, ensuring that only reliable solvers are allowed to participate. This approach helps the protocol deliver a smooth and trustworthy user experience, providing users with confidence in the execution quality. However, while the permissioned nature has its benefits, it also limits entry to the auctions for a broader range of solvers.
• The cost of complexity – Solvers need to constantly rebalance to fulfill cross-chain intents. Moreover, the number of chains is growing, making it difficult for solvers to maintain inventory across chains, rebalance, and hold the correct assets in an ecosystem where an L3 might grow popular overnight or an L2 decides to shut down at a whim. There’s also the issue of fragility. Intent-based protocols are relatively new solutions in the market and are constantly evolving as new edge cases emerge. This requires frequent updates on the solver side, adding another layer of complexity.
• High fixed costs – Writing complex code, managing custom integrations for each intent-based protocol, maintaining an inventory of assets across chains, dealing with RPC costs, maintaining specialized hardware to win speed competitions – these are just some of the hurdles that add another layer of complexity and expense for solvers.
• Incentives and lack of order flow – Solvers, being rational actors, aren’t in it for charity. They need to see a return on their investment to justify their participation. Taking on risks — such as costs, complexity, and funds at stake — should be compensated with higher returns. Otherwise, the expected value might not be attractive enough to justify the effort. Currently, the intents landscape has very few applications with sufficient order flow to make the effort worthwhile for solvers (think volume and potential profitability vs. the hassle of integration). This is why while apps with significant order flow (1inch, CoWswap, UniswapX, Across) see sufficient participation and competition of solvers, other apps struggle to attract enough solvers due to their lower order flow.

As a result, today, we find ourselves in a position where there’s a stark contrast in what solver participation looks like for the few apps at the top versus the wider ecosystem.

For instance, let’s look at two benchmarks for intent-based protocols: Cowswap for swap intents and Across for cross-chain intents:

Cowswap has a competitive auction with 16 independent solvers competing for user orders. No single solver dominates, and none of the solvers are run by the CoWswap team.

Across has over 15 solvers (called relayers) actively competing to fill users’ cross-chain intents. While Risk Labs continues to run its own solver, the chart below shows that, contrary to earlier data in our research, no single solver dominates the auctions anymore. There is sufficient competition among the solvers.

Distribution of order flow among Across relayers. Note: Risk Labs operates the solvers denoted in green and dark gray in the chart above. Source: Across Internal Data.

Meanwhile most other intent-based protocols only have solvers who are either well-capitalized market makers (hello Wintermute!) or the protocol team itself (who has a vested interest in executing user intents collected on their app).

There are a few reasons for this disparity, but the bottom line is there just aren’t enough solvers. This might seem like a minor detail, but it’s actually a ticking time bomb for centralization.

Here’s the worrying part: a lack of solvers creates centralization issues. That means single points of failure, censorship risks, and the potential for solvers to jack up fees.

Not exactly the open, permissionless future we envisioned, right? We’re basically slapping a fancy UI on a centralized system – the antithesis of the whole open finance revolution, where we’re making the same mistakes of the legacy system we’re out to disrupt.

We need to fix this solver bottleneck, and fast. More solvers, and soon, are the key to unlocking the true potential of intent-based systems.

The good news? There are signs of improvement. New projects are launching, and existing teams are collaborating to make it easier for more solvers to be onboarded.

In the next section, we’ll dive into some new solutions that aim to make life easier for solvers at every step of the intent-based system. More solvers, more fun, right?

Standardizing Intent Expression — ERC-7683

There’s no defined way for intent-based protocols to collect user intents and broadcast them to solvers. This means each intent-based app has created its own workflows and frameworks for what information an intent should consist of and how it should be processed.

This lack of standardization means more work for solvers to familiarize themselves with the workings of each intent-based protocol (proliferation of fragmentation, one might suppose). Solvers have to spend time and resources to understand each specific system and write custom code for supporting it.

As the number of intent-based protocols in the market increases, this approach is unsustainable for solvers to support. The fragmentation leads to isolated solver networks for each app, crippling the flywheel of network effects for intents, as we continue to build within our walled gardens.

To address these issues, Uniswap Labs and Across proposed ERC-7683, a standardized format for cross-chain intents. This standard offers several benefits:

• Simplified integration — Solvers only need to understand one format to fulfill intents from any ERC-7683 compliant protocol. This significantly lowers the barrier to entry for new solvers.
• Universal network of existing solvers — Applications can plug into a pre-existing network of solvers, eliminating the need to build and maintain their own. This also increases the competition among solvers to fulfill intents, which can potentially lead to lower fees for the users.

Many solver-based infra protocols, like Khalani, Nomial, are aiming to be compatible with the ERC-7683 standard. This is a promising development and represents a win-win scenario for all stakeholders involved – intent-based applications like UniswapX will benefit from an increased number of solvers competing for order flow, while solvers within these infrastructure protocols will gain immediate access to more order flow from Day

1.This compatibility has several big benefits:

• New intent-based protocols can be launched without the need to establish their own solver networks. This is analogous to the benefits provided by EigenLayer, which allows projects to rent crypto-economic security.
• Solvers will have the opportunity to compete for order flow in a bigger, global market for intents, rather than being confined to smaller, local markets where there aren’t enough incentives for more solvers to join in.

However, there are also some potential downsides and limitations that could hinder the overall benefits and adoption of ERC-7683:

• The possibility of competing standards – the problem with standards is that it’s hard to manage incentives amongst all the players in the ecosystem. Unless a standard is embedded at the protocol level by the chain itself, questions will persist about whether it truly serves as a public good that benefits everyone equally. In the case of ERC-7683, it can be argued that Across and Uniswap stand to gain more from its adoption, both from a marketing perspective and as early adopters defining the standard. We’ve seen similar obstacles with bridge standards in the past, such as the xERC-20 standard associated with the Connext brand or the OFT standard linked to LayerZero Labs, illustrate similar obstacles. Despite efforts to define a standard as credibly neutral, skepticism remains about whether certain parties benefit disproportionately. This skepticism often leads to the creation of competing standards, undermining the very purpose of establishing a unified standard.

The problem with standards – there will always be more than one.

• Solver market dynamics may in fact worsen – ERC-7683 needs to ensure that it creates a level playing field where both new and existing solvers can compete fairly. If the standard ends up creating a market dynamic where the more well-capitalized solvers like Wintermute end up winning most of the orderflow, then it must be questioned if there’s really a benefit of doing this at all.
• The standard only covers Ethereum and the EVM ecosystem – Intent-based applications are not limited to Ethereum and the wider EVM ecosystem. Today, Solana constantly does more volume than Ethereum and its L2s on a daily and monthly basis. There must be consideration to make this standard chain and ecosystem agnostic, albeit this would make it an even bigger effort to coordinate.
• The standard only covers cross-chain transfers and limit orders – ERC-7683 is largely centered around cross-chain intents. This focus may limit its applicability to other forms of intents, potentially restricting its utility for a broader range of use cases within the intent-based protocol ecosystem. However, it’s important to consider Across’ thesis: they believe most cross-chain actions will be simple transfers, not intricate multi-step actions. These actions would typically involve an initial cross-chain transfer followed by further execution on the destination chain. In essence, the standard caters to the most common cross-chain use case: transfers. And, It can be used in conjunction with single-chain actions to fulfill various intents, rather than the standard itself encompassing all possible intents.

Solver Collaboration for Intent Execution — Platforms like Khalani

Most intent-based protocols focus on a narrow range of actions, like swaps and bridging, on a limited number of chains.

To truly become the dominant design architecture, intent-based systems need to move beyond swaps and bridging to support a wider array of actions, including staking, lending, onramping fiat, and more.

One way to support more types of intents is to onboard specialized solvers. By onboarding solvers who specialize in these specific areas, we can ensure that each intent is executed with the highest level of proficiency, leading to more optimized outcomes.

These specialized solvers must work together rather than in isolation. This collaboration will allow intent-based protocols to execute more generalized intents, combining multiple actions to fulfil a wider range of intents.

Platforms like Khalani propose a solution for enabling solver-solver collaboration. Instead of competing PvP against each other, solvers work together to find the best solution for each user’s intent. This enables a multitude of smaller, specialized solvers to collaborate effectively.

Source: Introducing Khalani

As Kevin Wang (co-founder of Khalani) describes: Khalani is the platform for peer-to-peer solver “Coincidence of Can-do”. Collaboration allows for breaking down complex intents into smaller specialized intents (or composable intents), more manageable pieces that individual solvers can handle.

Khalani offers a platform where solvers can combine their resources and specialized skills to tackle specific user intents more effectively. Think of it like creating ‘solver pools’ similar to staking pools — by pooling their resources, participants can achieve more consistent and potentially higher results than they could on their own.

To understand how Khalani enables solver-solver collaboration, let’s consider an example.

Let’s say that…Bob, an Ethereum user with USDC, wants ETH on Arbitrum and uses an intent-based bridge.

Here’s how a solver could use Khalani to execute this intent:

1. Bob submits his intent: “I want ETH on Arbitrum in exchange for USDC on Ethereum”.

2. The intent-based bridge selects an exclusive solver to fill Bob’s intent, let’s call this solver, Solver A – the chosen one.

However, Solver A runs out of inventory on Arbitrum to fulfill Bob’s intent and decides to leverage Khalani’s pool of solvers to front the required capital.

1. Solver A sends an intent into Khalani to ask another solver (or combination of solvers) to front the capital on Arbitrum in exchange for Bob’s locked funds on Ethereum.

2. Another solver, Solver B (Arbitrum whale) who holds inventory on Arbitrum fronts the desired assets to Bob on Arbitrum.

3. User - solver settlement – Once Solver B completes Bob’s request, Solver A settles with the user by providing the proof to the settlement platform, which in this case is the intent-based bridge. As a result, Solver A receives Bob’s USDC on Ethereum.

4. Solver - solver settlement – Solver A settles with Solver B by presenting the proof of execution to the Khalani chain.

While this is a simplified example of how a solver can collaborate on Khalani to fulfill intents, Khalani can execute more complex intents using the same process.

For instance, Bob, an Ethereum user with USDC, wants to deposit ETH on a lending platform on Arbitrum.

In this case, the chosen solver could collaborate with multiple specialized solvers on Khalani, depending on the required expertise:

• Solver A (pricing expert) – runs specialized software to find the most accurate prices for trading pairs on the same chain or across chains. It could be used to price USDC / ETH liquidity based on both onchain and off-chain information.
• Solver B (Arbitrum whale) – holds inventory on Arbitrum that can be used to front the desired amount of ETH on Arbitrum.
• Solver C (Ethereum executor) – specializes in performing the best execution on Ethereum, offering price/latency tradeoffs as options to the user. It could be used to execute a transaction to take the user’s deposits on Ethereum.
• Solver D (Arbitrum executor) – specializes in executing transactions on Arbitrum. It could be used to execute the local transaction to deposit the ETH into the lending platform on Arbitrum.

Similarly, other specialized solvers on Khalani can also be called upon to break down complex intents into simplified tasks executed by a combination of solvers, rather than relying on a single solver to do all the work.

Solving via Khalani can enable the execution of generalized intents and would be a huge unlock for the intent-based paradigm. However, there are potential bottlenecks at each step of this flow that can impact the intent execution:

• User error while submitting the intent— When an application’s UI is designed to collect specific intents (like swaps or bridging), the scope of user error is limited as the user is operating within certain guidelines to submit their intent. However, designing UI for collecting generalized intents can be more challenging and prone to user errors as the user might submit incorrect or incomplete intent, leading to failed or incorrect intent fulfillments.
• Liveness risks – with intent systems, there’s a liveness risk of solvers simply not being available, which could stall the entire system. Moreover, it’s possible solvers might fail to execute their tasks correctly or on time, leading to transaction failures.
• Limited solver availability – There might be a limited number of solvers available within the Khalani infrastructure for different types of intents. This can reduce the possibility and overall efficiency of the intent execution.
• Solver-solver coordination complexity – Coordinating multiple solvers can be complex and prone to errors due to a multitude of moving factors involved like availability of specialized solver, market conditions, as well as factors related to the intent itself like chains involved, size of capital required, etc.
• Risks related to atomic execution of intents – All solvers’ actions are atomic and are executed together on the Khalani chain. This means that solvers experience atomicity on Khalani, i.e., either all parts of the flow succeed in a single action, or none do. If any part of the transaction fails, the whole transaction is rolled back, which might lead to a high intent failure rate. However, there’s no risk of stuck capital or loss of funds here.
• Solver collab adds latency – while the collaboration discovery happens off chain and is almost instant, there’s some added latency due to factors such as:

1) Task dependencies: Some tasks may depend on the completion of others. Coordinating these dependencies and handling errors can introduce delays as solvers wait for prerequisite tasks to complete.

2) Security and verification steps: Implementing security checks and additional steps to verify transactions to prevent fraud or malicious actions can add to the latency.

To ensure the reliability and overall quality of intent execution despite these potential delays, some intent-based protocols run permissioned auctions and choose to work only trusted solvers, whitelisted solvers.

However, it must be noted that this latency is dependent on the tasks and doesn’t change if the tasks are being executed by a single solver or multiple solvers collaborating – it will be similar in all intent-based protocols that rely on solvers for execution.

ERC 7683 x Khalani Flywheel

Solver infra platforms will be compatible with standards like ERC-7683 as it’s a win-win for everyone involved. The main goal of all these projects and initiatives is to onboard more solvers in the ecosystem, and if we’re able to do that, the compatibility between the two can kickstart a flywheel effect for the intent-based paradigm:

• More solvers – as the number of solvers increases, it becomes possible to execute a wider variety of intents.
• More solver collaboration – with more specialized solvers available, there are greater opportunities for collaboration. Solvers can combine their specialized skills to tackle more complex intents.
• More expressivity of intents – increased collaboration among solvers allows for the execution of more expressive and complex user intents. Users can request more complex actions that require multiple steps and specialized knowledge.
• Need for a common standard – As the expressivity of intents grows, there arises a need for a common standard for intent-based applications that ensures solvers can simply plug-in to a common interface and collect intents from different applications.

Capital Efficient Intent Settlement — Clearing Layers like Everclear

During the intent settlement process, solvers get repaid on the source chain where the user’s intents are generated. This means they end up with funds scattered across a dozen different chains, which they need to constantly rebalance. Not only is it a pain to manage, but a lot of that capital just sits there as dead weight. Plus, the more chains there are, the thinner each solver’s liquidity gets spread over time.

Currently, there’s no shared system to coordinate these capital flows between chains. Every solver is a lone wolf, managing liquidity in this fragmented mess. That’s where Everclear aims to step in and fix the rebalancing problem for solvers.

Everclear aims to solve this by coordinating global liquidity settlement between chains through a ‘Clearing Layer’ — a decentralized network that coordinates global netting and settlement of capital flows between chains.

The key to Everclear’s value proposition is the concept of netting.

Netting is a mechanism that aggregates (or combines) multiple payments between different parties to achieve a reduced net payment (or number of payments). This means that instead of handling each transaction separately, netting calculates the total amount owed between parties and only the difference is paid. This makes the process easier and reduces the number of payments needed.

For those of you who are part of the crypto nomad’s club, you must be familiar with Splitwise – an app that helps groups of people track shared expenses, such as during a trip. The “Settle Up” feature in Splitwise is a perfect example of netting:

• Tracking Expenses – Each member of the group logs their expenses into the app.
• Calculating Balances – Splitwise calculates how much each person owes or is owed.
• Settle Up (Netting) – Instead of each person paying each other multiple times, Splitwise calculates the simplest way to settle all debts.

This concept of netting is also used by remittance companies like TransferWise. Instead of moving money across borders, they match senders and receivers with opposing currency needs and settle them against each other. This reduces the number of actual transfers needed, making it more efficient and cost-effective.

Similarly, Everclear lets solvers ‘settle up’ with each other across chains, slashing the total number of settlements needed, which minimizes cost for solvers, as well as inventory and overall complexity. For those of you aware of how CowSwap works, essentially netting is a coincidence of wants on a grand scale, between solvers every X period of time.

Source: Introducing Everclear

Everclear believes that ~80% of daily flows to and from chains can be netted. This means that for every $1 transferred into the average chain daily, $0.80 is transferred out. This implies that overall, there’s 5x more volume being sent through bridges than necessary, and solvers are rebalancing across chains significantly more since they’re working in isolation.

Let’s try and understand how users (intent-based protocols, solvers, or CEXs) would leverage Everclear’s stack.

Consider the example of Alice, a solver that prefers to settle on Arbitrum. Alice needs to fill a 10 ETH transaction from Optimism to Arbitrum. Here’s how the flow would work with and without Everclear:

We can see that the benefits of a clearing layer like Everclear for its users (solvers, MMs) like Alice are:

• Settlement preference – Alice prefers to settle on Arbitrum, and Everclear ensures she gets repaid on Arbitrum, aligning with her preference.
• No need for rebalancing – Without Everclear, Alice would need to bridge 10 ETH from Optimism to Arbitrum to rebalance. With Everclear, this step is eliminated, saving time and resources. With Everclear handling rebalancing, the overall workflow becomes simpler. This could be particularly attractive for new entrants to join the solver pool.
• Reduced operational overhead – By eliminating the need for manual rebalancing, Everclear reduces the operational overhead for Alice, allowing her to focus on solving more transactions.
• Cost savings – Avoiding the need to bridge funds between chains can save on transaction fees and potential slippage, making the process more cost-effective for Alice. This could also lead to more consistent work and potentially higher income for solvers.

By eliminating a major pain point for solvers, Everclear can incentivize more participation in the ecosystem, ultimately contributing to the flywheel effect of onboarding more solvers.

Everclear is positioned in the intents-stack such that any protocol or infra involving solvers can leverage it to fix the rebalancing problem and cut costs and operational complexity for solvers.

For instance, solver infra like Khalani would integrate with Everclear, enabling the solvers that collaborate via its stack to leverage Everclear for capital efficient settlement. Thus, it can be said that Everclear’s launch is a positive development for the intent-based paradigm and as it improves all the different types of projects that are part of this ecosystem and grows the market for everyone.

To enable this, ‘Everclear is designed as an Arbitrum Orbit rollup using EigenDA in partnership with Gelato RaaS’. At the time of alpha mainnet launch (planned for early Q3 2024), Everclear would under some limitations and guardrails:

• Permissioned asset and chain support – Initially, only allowlisted chains and assets are supported, which restricts the system’s openness and usability. However, the plan is to make both permissionless in the future.
• Reliance on Eigenlayer – Everclear relies on Eigenlayer for security, but currently, it doesn’t support slashing. This limits the economic security until slashing is implemented. Users must trust that Eigenlayer will implement slashing in the future to enhance economic security. However, until slashing is implemented, Everclear plans to use Hyperlane’s validator set ISM for security.
• Everclear will launch with upgradeable smart contracts – While upgradeable contracts allow for flexibility, they also pose risks if not managed properly, such as potential exploits during upgrades.

Note: Alpha mainnet is like Everclear’s public testnet stage. The full launch will feature permissionless chain expansions, allowing chains to define their own security preferences.

Moreover, there are certain potential risks and trust assumptions associated with Everclear as a clearing mechanism:

• System failures – Liveness failures or downtime during upgrades could disrupt the clearing process, leading to delays or incorrect settlements. This would impact the functioning of all users leveraging Everclear. Everclear’s clearing windows are estimated to be roughly every 3-6 hours, meaning that only prolonged downtime would impact user operations. Moreover, if such failures occur for an extended duration, the main impact would be on UX, and not on security of funds. This is because Arbitrum Nitro has a built-in “forced update” feature. If there’s downtime, users can use this feature to exit transactions on L1, ensuring there’s no way to censor users.
• Dependency on market markers for the role of arbitrageurs – Everclear looks to offset settlements between solvers (through netting) whenever possible. However, if netting fails, they turn to arbitrageurs to buy solver invoices. This creates a dependency on market makers who are expected to consistently purchase these invoices, albeit at a discount. To kickstart the system, Everclear is actively partnering with major market makers to fill this crucial role.
• Auction dynamics – the reliance on auctioning invoices to arbitrageurs if netting isn’t possible due to any reason like a lack of solvers in the system, could introduce volatility and unpredictability in repayments. However, the Everclear team believes this impact should be manageable due to two key factors:

1) Arbitrageurs will operate based on predictable pricing curves, reducing uncertainty in their offers, and

2) launching with an active and liquidity pool of arbitrageurs will ensure competition and potentially stable prices during auctions.

This combination of fixed pricing curves and a liquid ecosystem of arbitrageurs should contribute to a more predictable outcome for repayments for solvers, even when auctions are necessary.

Closing Thoughts

Every so often, a new idea comes along that dares to change the status quo. The intent-based paradigm is one such idea, aiming to fundamentally transform how users interact with blockchains.

It’s still early days, and only time will tell if the intent-based design philosophy will succeed. But one thing is clear: with intents, it’s solvers all the way down; if we’re going to usher in an era of intents in crypto, we’re going to need a lot more solvers.

At LI.FI, we’ve developed an extensive distribution of 250+ apps, wallets, onramps, and other DeFi protocols that have integrated our product. We directly touch the frontends where users express the most common intents – swaps, cross-chain transfers and multi-step actions like zaps. This unique vantage point allows us to capture the value generated at the intent expression layer.

As the landscape of underlying executors (bridges, DEXs, solvers, and solver-based infra) evolves, the role of aggregators becomes increasingly more crucial. This presents a significant opportunity for new entrants, like solver-based infrastructure protocols, to build compatible technology that can seamlessly integrate with LI.FI and tap into our extensive user base and order flow.

Our mission is to aggregate all relevant execution infrastructure, inherit their features, and provide our integration partners with a range of options through our execution middleware. We encourage them to choose providers based on factors like use-case, required features, target audience, average transfer sizes, expected transfer frequency, supported chains, and more.

We’re heads down, focused on building the best abstraction and aggregation solution on the market. Our goal is to help teams access all the liquidity and users in DeFi, enabling them to dominate the multi-chain crypto ecosystem.

If you’re a chain, bridge builder, intent-based app developer, solver, or solver infrastructure developer, come talk to us. Let’s work together.

Disclaimer：

1. This article is reprinted from [li.fi/]. All copyrights belong to the original author [Arjun Chand]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.