Author: Arjun Chand Source: li.fi Translation: Shan Ouba, Golden Finance

While intent-based bridges can speed up the bridging UX, they risk becoming centralized solutions due to the lack of solvers.

The lack of solvers to execute user intent is a well-known problem. It is a recognized problem, and the solution sounds simple - just add more solvers - but it has not been solved yet.  

We realize that the implementation of intent is inseparable from solvers. We need to solve this unresolved problem of bringing in more solvers, otherwise we may face the risk of the financial industry being very similar to the traditional financial industry - 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 solve the solver shortage problem by solving the solver pain points.

Intents invert how trading works, focusing on the end goal or “intent” of the user rather than the specific steps to get there (more on that later). Intent-based design has two main benefits:

• User Experience —The user experience is seamless and typically fast. The user expresses the intent and the solver handles the rest. Gas abstraction and other features make the experience smoother than normal trading. Just-in-time (JIT) liquidity means there’s no waiting minutes for trades. Overall, the intent-based experience is less overwhelming for users, creating the “one-click” feel that most web2 applications can give to users.  

• Execution Efficiency —The solution provider is typically a professional market maker or protocol team that handles trade execution for the user. The argument here is that specialized solution providers are better equipped to structure trades for optimal on-chain execution than basic AMM contracts or end users navigating across multiple applications. Additional features like trade batching and order matching make intent execution more capital efficient. For users: no more silly mistakes, wasted resources, and frustrating on-chain experiences. For applications: no more reliance on simple, gas-inefficient contracts for complex trade paths. For LPs: no more potential liquidity stuck in stale on-chain contracts.

Intent-based design is at the heart of the bag of popcorn that gave birth to “chain abstraction” — that is, building an application that interacts with multiple chains while feeling like a single, interconnected “crypto” experience.   

With Intent, It’s All Solved

Intent-based protocols have three main parts:

• Intent Expression — Users specify a desired outcome on the application. For example, on the bridge, a user might say they want to exchange 1 ETH on Arbitrum for 1 ETH on Optimism.

• Intent Execution — Bidders bid to determine the most efficient way to execute the user’s intent. The winner (e.g. a Relayer in Across) fulfills the request (sending the user 1 ETH on Optimism).

• Intent Settlement — Solvers are paid for their services (e.g. 1 ETH from the user on Arbitrum + a small fee). Intent agreements prove that intent is met. However, this is only one aspect of settlement. The bigger picture is that intent settlement also facilitates the rebalancing of solvers’ capital between chains and assets.

Intents are great — smooth, fast, efficient, and simple. But intent-based design has a problem: a lack of solutions.

The Root of Intent Centralization

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

Ideally, solvers are a competitive environment where solvers compete to fulfill intents at the lowest price. However, becoming a solver is hard. However, solvers have certain barriers to entry:

• Collateral requirements - Some intent-based protocols have collateral requirements for solvers to participate in order flow auctions. For example, in 1inch Fusion, the top 10 solvers (called resolvers) are allowed to participate in the auction. These solvers are ranked and whitelisted based on their "unicorn power", a metric determined by the 1inch tokens they stake (either by the solver themselves or on behalf of them) and the length of the stake. These collateral requirements exist to discourage malicious behavior, which is a good thing. The problem? These collateral requirements can be a significant barrier to entry, especially for smaller players who may not have upfront capital.

• 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 the power of a unicorn, while in other systems like UniswapX Beta, participation may require being whitelisted by the protocol running the auction. These systems prioritize execution quality, ensuring that only reliable solvers are allowed to participate. This approach helps protocols provide a smooth and trustworthy user experience that gives users confidence in the quality of execution. However, while the permissioned nature has its benefits, it also limits a wider range of solvers from entering the auction.

• The cost of complexity — Solvers need to constantly rebalance to implement cross-chain intents. Additionally, the number of chains is growing, making it difficult for solvers to maintain cross-chain inventories, rebalance, and hold the right assets in the ecosystem because an L3 may become popular overnight or an L2 may decide to shut down on a whim. There is 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, which adds another layer of complexity.

• High fixed costs — writing complex code, managing custom integrations for each intent-based protocol, maintaining a cross-chain asset inventory, dealing with RPC costs, maintaining specialized hardware to win the speed race — these are just some of the barriers that add another layer of complexity and expense to solvers.

• Incentives and lack of order flow — As rational participants, solvers are not participating for charity. They need to see a return on investment to justify their participation. Taking on risk (e.g., cost, complexity, and money involved) should be rewarded with a higher return. Otherwise, the expected value may not be enough to justify the effort. Currently, few applications in the intent space have enough order flow to justify the effort for solvers (think volume and potential profitability vs. the hassle of integration). This is why while applications with significant order flow (1inch, CoWswap, UniswapX, Across) see sufficient solver participation and competition, others struggle to attract enough solvers due to lower order flow.

As a result, today we see a stark contrast between solver participation in the top few applications and the broader ecosystem. 

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

Cowswap has 16 independent solvers competing for user orders. No single solver is the top solver, and no single solver is operated by the CoWswap team.

Across has over 15 solvers (called relayers) actively competing to satisfy users’ cross-chain intents. While Risk Labs continues to run its own solvers, the chart below shows that, contrary to earlier data from our research, no single solver is able to dominate the auction. There is ample competition between solvers.

Order flow distribution across relayers. Note: Risk Labs operates the solvers represented in green and dark grey in the chart above.

Meanwhile, most other intent-based protocols have only solvers that are either well-capitalized market makers or the protocol teams themselves (who have a vested interest in enforcing the user intent collected on their applications).

There are many reasons for this discrepancy, but it all boils down to not having enough solvers. This may seem like a minor detail, but it’s actually a centralization time bomb.

Here’s the worry: a lack of solvers creates centralization problems. This means single points of failure, censorship risk, and the possibility of solvers jacking up fees.  

This isn’t the open, permissionless future we envisioned, is it? We’re basically slapping a fancy UI on top of a centralized system — it’s the antithesis of the whole open finance revolution, and we’re making the same mistakes as the legacy systems we’re trying to disrupt.  

We need to solve this solver bottleneck ASAP. Getting more solvers out ASAP is key to unlocking the true potential of intent-based systems.

The good news is that things are looking up. New projects are launching, and existing teams are collaborating to make it easier for more solutions to onboard.

In the next section, we’ll dive into some new solutions designed to make the solver’s job easier at each step of an intent-based system. The more solvers, the more fun, right?

Standardized Intent Expression — ERC-7683

Intent-based protocols have no clear way to collect user intents and broadcast them to solvers. This means that each intent-based application has created its own workflow and framework to determine what information an intent should contain and how it should be processed.  

The lack of standardization means more work for solvers to get familiar with how each intent-based protocol works (one could argue that fragmentation is increasing). Solvers must spend time and resources to understand each specific system and write custom code to support it.  

As the number of intent-based protocols on the market continues to grow, this approach is no longer sustainable for solutions. Fragmentation results in siloed solver networks for each application, weakening the network effect flywheel of intent as we continue to build within our own walled gardens.

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

• Simplified integration — Solvers only need to understand one format to implement intents for any ERC-7683-compliant protocol. This significantly lowers the barrier to entry for new solvers.

• Universal network of existing solvers - applications can tap into pre-existing solver networks without having to build and maintain their own. This also increases competition between solvers to fulfill intent, potentially reducing fees for users.

Many solver-based infrastructure protocols (e.g. Khalani, Nomial) are designed to be compatible with the ERC-7683 standard. This is a promising development that represents a win-win situation for all stakeholders - intent-based applications like UniswapX will benefit from an increasing number of solvers competing for order flow, while solvers in these infrastructure protocols will immediately have access to more order flow from day one.

This compatibility has several big benefits:

• New intent-based protocols can be launched without having to build their own network of solvers. This is similar to the benefit provided by EigenLayer, which allows projects to rent cryptoeconomic security.

• Solution providers will have the opportunity to compete for order flow in a larger global market, rather than being limited to smaller local markets where there are not enough incentives to attract more solution providers to join.

However, ERC-7683 also presents some potential drawbacks and limitations that could hinder its overall benefits and adoption:

• Potential for Competing Standards - The problem with standards is that it is difficult to manage incentives between all participants in the ecosystem. Unless the chain itself embeds the standard at the protocol level, people will question whether it truly becomes a public good that benefits everyone equally. In the case of ERC-7683, it can be argued that Across and Uniswap will have more to gain from adopting the standard, both from a marketing perspective and as early adopters of defined standards. We have seen similar bridge standards barriers in the past, such as the xERC-20 standard associated with the Connext brand or the OFT standard associated with LayerZero Labs, which illustrate similar barriers. Despite efforts to define standards as credibly neutral, people still doubt whether certain parties are gaining disproportionate benefits. This suspicion often leads to the creation of competing standards, which defeats the purpose of establishing a unified standard.

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

• In fact, solver market dynamics could worsen - ERC-7683 needs to ensure a level playing field is created where both new and established solvers can compete fairly. If the standard ends up creating a market dynamic where better-capitalized solvers like Wintermute end up winning the majority of order flow, then one has to question whether this is actually a benefit. The standard only covers the Ethereum and EVM ecosystem - intent-based applications are not limited to Ethereum and the broader EVM ecosystem. Today, Solana consistently has higher daily and monthly transaction volumes than Ethereum and its L2. Consideration must be given to making this standard chain and ecosystem blockchain-agnostic, although this would make coordination more difficult. The standard only covers cross-chain transfers and limit orders - ERC-7683 is primarily centered around cross-chain intents. This focus may limit its applicability to other forms of intent, and thus potentially its utility for a wider range of use cases in the intent-based protocol ecosystem. However, it is important to consider Across's argument: they argue that most cross-chain operations will be simple transfers, rather than complex, multi-step operations. These operations typically involve an initial cross-chain transfer followed by further execution on the target chain. In essence, the standard caters to the most common cross-chain use case: transfers. Moreover, it can be used in conjunction with single-chain operations to implement a variety of intents, rather than the standard itself covering all possible intents.

Solver Collaboration for Intent Execution — Platforms like Khalani

Most intent-based protocols focus on a narrow range of operations, such as swaps and bridges, on a limited number of chains.  

To truly become the dominant design architecture, intent-based systems need to go beyond swaps and bridges to support a wider range of operations, including staking, lending, fiat currency access, and more.  

One ​​way to support more types of intents is to hire specialized solvers. By hiring solvers that specialize in these specific areas, we can ensure that each intent is executed with the highest level of proficiency, resulting in more optimized results.  

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

Platforms such as Khalani propose a solution to enable collaboration between solvers. Instead of competing with each other, solvers work together to find the best solution for each user's intent. This allows many smaller, specialized solvers to collaborate effectively.

As Kevin Wang (co-founder of Khalani) describes: Khalani is a platform for peer-to-peer solutions "Coincidence of Can-do". Collaboration can break down complex intents into smaller specialized intents (or composable intents), which are more manageable pieces that can be handled by a single solver.

Khalani provides a platform for solvers to combine their resources and expertise to more efficiently solve specific user intents. Think of it as creating “solver pools” similar to staking pools — by pooling their resources, participants can achieve more consistent, and potentially higher-quality results than they could on their own.

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

Let’s say… Bob is an Ethereum user with USDC who wants to spend ETH on Arbitrum using an intent-based bridge.  

Here’s how a solver can use Khalani to fulfill this intent:

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

2. The intent-based bridge selects a dedicated solver to fulfill Bob’s intent, and we’ll call this solver Solver A — the selected solver.

However, Solver A does not have enough inventory on Arbitrum to fulfill Bob’s intent, so it decides to tap into Khalani’s pool of solvers to provide the required funds.

3. Solver A sends an intent to Khalani, asking another solver (or combination of solvers) to advance funds on Arbitrum in exchange for Bob’s locked funds on Ethereum.

4. Another solver, Solver B (Arbitrum Whale) who holds an inventory on Arbitrum, provides the required assets to Bob on Arbitrum.

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

6. Solver-Solver Settlement - Solver A settles with Solver B by submitting a proof of execution to the Khalani chain.

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

For example, Bob, an Ethereum user with USDC, wants to deposit ETH into the lending platform on Arbitrum.

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

• Solver A (Pricing Expert) - runs specialized software to find the most accurate price for same-chain or cross-chain trading pairs. It can be used to price USDC/ETH liquidity based on on-chain and off-chain information.

• Solver B (Arbitrum Whale) - holds inventory on Arbitrum and can be used to pre-deposit the desired amount of ETH on Arbitrum.  

• Solver C (Ethereum Executor) - Specialized in performing best execution on Ethereum, offering price/latency tradeoffs as options to users. It can be used to execute trades to obtain user deposits on Ethereum.

• Solver D (Arbitrum Executor) - Specialized in performing trades on Arbitrum. It can be used to perform local trades to deposit ETH into the lending platform on Arbitrum.

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

Solving via Khalani enables execution of generic intents, which would be a huge breakthrough for the intent-based paradigm. However, each step of this flow has potential bottlenecks that could affect the execution of intents:

• User errors when submitting intents — If your app’s UI is designed to collect specific intents, such as swap or bridge, the scope for user error is limited because users follow certain guidelines when submitting intents. However, designing interfaces for collecting generic intents can be more challenging and prone to user errors, as users may submit incorrect or incomplete intents, resulting in failed or incorrect intent fulfillment.

• Liveness Risk - For intent systems, there is a liveness risk where solvers become unavailable, which can cause the entire system to stall. Additionally, solvers may not be able to execute tasks correctly or in a timely manner, resulting in failed transactions.  

• Limited Solver Availability - The number of solvers available for different types of intents in the Khalani infrastructure may be limited. This reduces the likelihood of intent execution and the overall efficiency.

• Complexity of Solver-Solver Coordination - Coordinating multiple solvers can be complex and error-prone, as there are many moving parts involved, such as the availability of specialized solvers, market conditions, and factors related to the intent itself, such as the chains involved, the size of capital required, etc.

• Risks associated with atomic execution of intents - All solver operations are atomic and executed together on the Khalani chain. This means that solvers experience atomicity on Khalani, i.e. all parts of the process either succeed in a single operation or all of them succeed. If any part of a transaction fails, the entire transaction is rolled back, which can result in a high rate of intent failures. However, there is no risk of stranded funds or loss of funds here.

• Added latency to solver collaboration - While collaborative discovery happens off-chain and is nearly instant, some latency is added due to the following factors:

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

2) Security and validation steps: Implementing security checks and other steps to validate transactions to prevent fraud or malicious behavior can add latency.  

Despite these potential delays, to ensure the reliability and overall quality of intent execution, some intent-based protocols run permission auctions and choose to work only with trusted solvers, whitelisting solvers.

However, it is important to note that this latency is task-dependent and does not change if the task is executed by a single solver or multiple solvers collaborating - it will be similar across all intent-based protocols that rely on solver execution.

ERC 7683 x Khalani Flywheel

The Solver Base Platform will be compatible with standards such as ERC-7683 as this is a win-win for all participants. The main goal of all these projects and initiatives is to have more solvers in the ecosystem, and if we can do that, the compatibility between the two can start 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 Solution Collaboration – As more specialized solutions emerge, opportunities for collaboration increase. Solvers can combine their specialized skills to solve more complex problems.

• More expressive intents – Increased collaboration between solvers allows for more expressive and complex user intents. Users can request more complex actions that require multiple steps and expertise.

• A common standard is needed – As intents become more expressive, a common standard needs to be established for intent-based applications to ensure that solvers can simply plug into a common interface and collect intents from different applications.

Capital Efficient Intent Settlement – ​​Clearing Layers Like Everclear

During the intent settlement process, solvers are repaid on the source chain where the user intent was generated. This means they end up with funds spread across a dozen different chains that they need to constantly rebalance. Not only is this cumbersome to manage, but a lot of funds are just sitting there as useless assets. Additionally, the more chains there are, the thinner the liquidity of each solver becomes over time.

Currently, there is no shared system to coordinate the flow of capital between blockchains. Each solution provider is a lone wolf, managing liquidity in this fragmented mess. This is where Everclear aims to step in and solve the rebalancing problem for solution providers.

Everclear aims to solve this problem by coordinating the settlement of global liquidity between chains through a “clearing layer” - a decentralized network that coordinates the global netting and settlement of inter-chain capital flows.  

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 reduce the net payment (or number of payments). This means that instead of processing each transaction individually, the total amount owed between the two parties is calculated and then only the difference is paid. This makes the process much simpler and reduces the number of payments required.

For those of you who belong to the crypto nomads club, you must be familiar with Splitwise - it is an app that helps a group of people track shared expenses (for example during travel). The "Settle" feature in Splitwise is a perfect example of netting:

• Track expenses - Each member of the group logs their expenses into the app.

• Calculate balances - Splitwise calculates how much each person owes or is due.  

• Closing (Netting) - Instead of having everyone pay each other multiple times, Splitwise will calculate the simplest way to settle all debts.  

This concept of netting is also used by remittance companies such as TransferWise. Instead of moving money across borders, they match senders and recipients with opposite monetary needs and then settle with each other. This reduces the number of transfers actually required, making it more efficient and cost-effective.

Similarly, Everclear allows solvers to "settle" across chains, drastically reducing the total number of settlements required, minimizing costs for solvers as well as inventory and overall complexity. For those who know how CowSwap works, netting is essentially the mass fulfillment of needs between solvers every X period of time.

Everclear believes that about 80% of the flow of funds in and out of the blockchain can be netted every day. This means that on average, for every $1 transferred in, $0.80 is transferred out every day. This means that overall, 5 times more transactions are sent through the bridge than necessary, and because solvers work independently, they are rebalanced between blockchains much more often.  

Let's try to understand how a user (intent-based protocol, solver, or CEX) can utilize Everclear's stack.

Take Alice as an example, she is a solver who prefers to settle on Arbitrum. Alice needs to fill in a 10 ETH transaction from Optimism to Arbitrum. Here’s how the process works with and without Everclear:

We can see that the benefits of a clearing layer like Everclear for a user like Alice (solver, MM) are:

• Settlement preference — Alice prefers to settle on Arbitrum, and Everclear ensures that she gets reimbursed on Arbitrum, which is consistent with her preference.

• No Rebalancing - Without Everclear, Alice would need to bridge 10 ETH from Optimism to Arbitrum in order to rebalance. With Everclear, this step is eliminated, saving time and resources. With Everclear handling the rebalancing, the entire workflow becomes simpler. This may be particularly attractive to new entrants joining the solver pool.

• Reduced Operational Overhead - By eliminating the need to manually rebalance, Everclear reduces Alice's operational overhead, allowing her to focus on solving more trades.

• Cost Savings - Avoiding bridging funds between chains saves on transaction fees and potential slippage, making the process more cost-effective for Alice. This can also lead to more consistent work and higher income for solvers.

By removing a major pain point for solution providers, Everclear can incentivize more people to participate in the ecosystem, ultimately helping to create a flywheel effect that attracts more solution providers.

Everclear sits in the intent stack, so any protocol or infrastructure that involves solvers can leverage it to solve rebalancing problems and reduce costs and operational complexity for solvers.

For example, solution infrastructures such as Khalani will integrate with Everclear, enabling solutions collaborating through their stack to leverage Everclear for capital efficient settlement. Therefore, it can be said that the launch of Everclear is a positive development for the intent-based paradigm as it improves all different types of projects that belong to this ecosystem and expands the market for everyone.

To achieve this, "Everclear is designed to aggregate Arbitrum Orbit using EigenDA in partnership with Gelato RaaS". At the alpha mainnet launch (scheduled for early Q3 2024), Everclear will have some limitations and protections:

• Permissioned asset and chain support – Initially, only permission-listed chains and assets will be supported, which limits the openness and usability of the system. However, permissionlessness is planned for the future.

• Dependency on Eigenlayer – Everclear relies on Eigenlayer for security, but it currently does not support slashing. This limits economic security until slashing can be 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 to ensure security.

• Everclear will launch with upgradeable smart contracts – While upgradeable contracts offer flexibility, they also introduce risks if not managed properly, such as vulnerabilities that may arise during upgrades.

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

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

• System Failures - Liveness failures or downtime during upgrades could disrupt the clearing process, causing delayed or incorrect settlements. This would impact functionality for all users using Everclear. Everclear’s clearing window is estimated to be approximately every 3-6 hours, meaning that only prolonged downtime would impact user operations. Furthermore, if such an outage lasted for a long time, the primary impact would be on user experience, not fund security. This is because Arbitrum Nitro has a built-in “force update” feature. In the event of downtime, users can use this feature to exit transactions on L1, ensuring that users cannot be censored.

• Arbitrageur Role Reliance on Market Makers - Everclear seeks to offset settlements between solvers (via netting) whenever possible. However, if netting fails, they turn to arbitrageurs to purchase solver invoices. This creates a reliance on market makers, who need to continually purchase these invoices despite the discounted price. To launch the system, Everclear is actively working with major market makers to fill this critical role.

• Auction Dynamics - If netting is not possible due to, for example, a lack of solvers in the system, there is reliance on auctioning invoices to arbitrageurs, which can result in volatile and unpredictable repayments. However, the Everclear team believes that this impact should be manageable due to two key factors: 1) arbitrageurs will operate against a predictable pricing curve, reducing the uncertainty of bids, and 2) by creating an active and liquid pool of arbitrageurs, competition and potentially stable prices during auctions can be ensured. The combination of a fixed pricing curve and a liquid ecosystem of arbitrageurs should help provide solvers with more predictable payback outcomes, even in cases where an auction is necessary. Conclusion From time to time, a new idea comes along that dares to shake up the status quo. The intent-based paradigm is one such idea that aims to fundamentally change how users interact with blockchains.

  It’s still early days, and only time will tell if the philosophy of intent-based design will be successful. But one thing is clear: intent is always a solver, and if we’re going to usher in the era of encrypted intent, we’re going to need more solvers.