Don't get stuck on the surface of intent narratives: lacking a solver will only make intent increasingly centralized
TechFlow Selected TechFlow Selected
Don't get stuck on the surface of intent narratives: lacking a solver will only make intent increasingly centralized
If we are to enter the era of intent in cryptocurrency, we will need more solvers.
Navigating Web3 tides with focused insightsAuthor: Arjun Chand
Compiled by: TechFlow
At LI.FI, we've previously discussed how intent-based bridging can improve user experience but may become centralized due to a lack of solvers.
The shortage of solvers capable of fulfilling user intents is a well-known issue. While the solution might seem simple—just add more solvers—in practice, this problem remains unresolved.
We recognize that solvers are critical for intents. Without addressing the challenge of onboarding more solvers, we risk building a future similar to traditional finance—one where order flow is concentrated in the hands of a few entities.
In this article, we will define the architecture of intent-based protocols and explore emerging market solutions that could address solver shortages by tackling solver pain points.
Let’s dive in!
Introduction to Intents
Note: If you're already familiar with intents or have read our previous article, feel free to skip this section.
Intents change how transactions work by focusing on the user's end goal—the "intent"—rather than specific steps to achieve it (more on this later). Intent-based design offers two main benefits:
-
User Experience—The experience feels seamless and often fast. Users express an intent; solvers handle the rest. Gas abstraction and other features make the experience smoother than standard transactions. Just-in-time (JIT) liquidity means no more waiting minutes for transaction confirmation. Overall, intent-based experiences are less complex for users, delivering the “one-click” simplicity common in most Web2 applications.
-
Execution Efficiency—Solvers are typically specialized market makers or protocol teams handling transaction execution for users. The idea is that professional solvers can build better on-chain execution than basic automated market maker (AMM) contracts or end users operating across multiple apps. Transaction batching and features like order matching make intent execution more capital-efficient. For users: no more silly mistakes, wasted resources, or frustrating on-chain experiences. For apps: no longer relying on simple, gas-inefficient contracts for complex transaction routing. For liquidity providers (LPs): no more idle liquidity stuck in outdated on-chain contracts.
Intent-based design is central to achieving chain abstraction—building applications that interact with multiple chains yet feel like a single, interconnected "crypto" experience.
For Intents, Solvers Are Key
Intent-based protocols consist of three main components:
-
Intent Expression—Users specify desired outcomes within an application. For example, in a bridging app, a user might state they want to swap 1 ETH from Arbitrum to Optimism.
-
Intent Execution—Solvers compete in auctions to determine the most efficient way to fulfill the user’s intent. The winner (e.g., a relayer in Across) completes the request (sending 1 ETH to the user on Optimism).
-
Intent Settlement—Solvers are compensated for their service (e.g., receiving the user’s 1 ETH on Arbitrum plus a small fee). The intent protocol proves the intent was satisfied. However, this is only one side of settlement. The bigger picture is that intent settlement also facilitates capital rebalancing among solvers across chains and assets.
While intent design is smooth, fast, efficient, and simple, there's one problem: a lack of solvers.
Centralization Risks of Intents
Solvers are the core of intent-based protocols. They are the entities that actually execute user intents, such as transferring assets from Chain A to Chain B.
In an ideal world, solving would be competitive, with solvers bidding to fulfill intents at the lowest price. However, becoming a solver isn’t easy and comes with several barriers to entry:
-
Staking Requirements: Some intent-based protocols require solvers to stake tokens to participate in order flow auctions. For example, in 1inch Fusion, only the top 10 solvers (called resolvers) are allowed to participate. These solvers are ranked and whitelisted based on their staked 1INCH tokens (staked by themselves or on their behalf) and their "unicorn power," which considers staking duration. Staking requirements aim to prevent malicious behavior, but they can pose significant entry barriers, especially for smaller players without sufficient upfront capital.
-
Permissioned Systems: Many intent-based protocols are permissioned, meaning they have decision-makers who decide who can participate. For instance, in 1inch Fusion, access is based on unicorn power, while in other systems (like UniswapX Beta), participation may require being whitelisted by the protocol running the auction. These systems prioritize execution quality, ensuring only reliable solvers are allowed. This approach helps deliver a smooth and trustworthy user experience but limits broader solver participation.
-
Cost of Complexity: Solvers must constantly rebalance to meet cross-chain intents. Additionally, the number of chains is increasing, making it harder for solvers to maintain inventory, rebalance, and hold the right assets across the ecosystem. For example, an L3 might suddenly become popular overnight, or an L2 might shut down unexpectedly. Intent-based protocols are new solutions in the market, evolving rapidly with new developments, requiring frequent updates from solvers and adding complexity.
-
High Fixed Costs: Writing complex code, managing custom integrations for each intent-based protocol, maintaining cross-chain asset inventory, handling RPC costs, and operating dedicated hardware to win speed races—all these increase solver complexity and expenses.
-
Lack of Incentives and Order Flow: As rational actors, solvers need to see returns on investment to participate. Taking on risks (costs, complexity, capital) should yield higher rewards; otherwise, the expected value may not justify the effort. Currently, only a few applications in the intent space have enough order flow to make solver efforts worthwhile (considering trading volume and potential profitability relative to integration hassle). That’s why, despite strong order flow, applications like 1inch, CoWswap, UniswapX, and Across see sufficient solver participation and competition, while others struggle to attract enough solvers due to lower order flow.
As a result, today we find ourselves in a stark contrast between the solver participation seen in top-tier applications versus the broader ecosystem.
For example, let’s look at two intent-based protocol benchmarks: Cowswap for swap intents and Across for cross-chain intents:
Cowswap has a competitive auction with 16 independent solvers vying for user orders. No single solver dominates, and none are operated by the CoWswap team.
Across has over 15 solvers (called relayers) actively competing to fulfill users’ cross-chain intents. Although Risk Labs continues to run its own solver, data shows that, contrary to earlier findings in our research, no single solver now dominates the auction. There is sufficient competition among solvers.
Centralization risks from solver shortages
Distribution of Across relayer order flow. Note: Solvers operated by Risk Labs are marked green and dark gray in the chart. Source: Internal Across data.
Currently, most other intent-based protocols only involve well-funded market makers (such as Wintermute) or the protocol teams themselves (who have a vested interest in executing user intents collected on their apps).
Several factors contribute to this disparity, but ultimately, there just aren’t enough solvers. This may seem like a minor issue, but it’s actually a ticking centralization bomb.
Here’s what’s concerning: A lack of solvers leads to centralization issues. This means single points of failure, censorship risks, and potential for solvers to raise fees.
This isn’t the open, permissionless future we envisioned, right? We’re essentially putting a fancy UI on a centralized system—going against the entire open finance revolution we aimed for, repeating the very traditional systems we sought to disrupt.
We need to solve this solver bottleneck quickly. More solvers, faster, are key to unlocking the true potential of intent-based systems.
The good news is, there are signs of improvement. New projects are launching, and existing teams are collaborating to make it easier for more solvers to join.
In the next section, we’ll dive into some new solutions designed to make every step easier for solvers in intent-based systems. More solvers, more fun, right?
Standardizing Intent Expression—ERC-7683
Currently, there’s no standardized way for intent-based protocols to collect user intents and broadcast them to solvers. This means each intent-based application creates its own workflow and framework to determine what information an intent should include and how it should be processed.
This lack of standardization means solvers spend extra time learning how each intent-based protocol works (think fragmentation creep). Solvers must invest time and resources understanding each unique system and writing custom code to support it.
As the number of intent-based protocols grows, this approach becomes unsustainable for solvers. Fragmentation leads to isolated solver networks for each app, weakening the network effects of intents because we’re still building within 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.
-
Shared Network of Existing Solvers: Applications can tap into a pre-existing network of solvers without building and maintaining their own. This also increases competition among solvers to fulfill intents, potentially lowering user fees.
Many solver infrastructure protocols, such as Khalani and Nomial, are working toward compatibility with the ERC-7683 standard. This outlook is promising and represents a win-win for all stakeholders. Intent-based applications like UniswapX will benefit from increased solver competition, while solvers in these infrastructure protocols will gain access to more order flow from day one.
This compatibility brings several clear advantages:
-
New intent-based protocols can launch without building their own solver network. This is similar to the benefit EigenLayer provides, allowing projects to rent cryptographic security.
-
Solvers will have the opportunity to compete for order flow in a larger, more global intent market, rather than being limited to smaller local markets, increasing incentives and attracting more solvers.
However, there are also potential drawbacks and limitations that could affect the overall effectiveness and adoption of ERC-7683:
-
Potential for Competing Standards: The challenge with standards is aligning incentives across all ecosystem participants. Unless a standard is embedded at the protocol level by the chain itself, questions remain about whether it truly serves as a public good benefiting everyone equally. In the case of ERC-7683, Uniswap and Across arguably benefit more—both from a marketing perspective and as early adopters defining the standard. We’ve seen similar hurdles with past bridging standards, such as Connext’s xERC-20 or LayerZero’s OFT, illustrating the same issues. Despite efforts to position standards as trust-neutral, skepticism persists about disproportionate benefits to certain parties. This often leads to competing standards, undermining the goal of unified standardization.
-
Solver Market Dynamics Could Worsen: ERC-7683 must ensure a level playing field where both new and established solvers can compete fairly. If the standard ends up funneling most order flow to well-capitalized solvers (like Wintermute), then its real benefit must be questioned.
-
The Standard Only Covers Ethereum and the EVM Ecosystem: Intent-based applications aren’t limited to Ethereum and the broader EVM ecosystem. Today, Solana frequently surpasses Ethereum and its L2s in daily and monthly transaction volume. The standard must consider chain-agnosticism, though this makes coordination more difficult.
-
The Standard Only Covers Cross-Chain Transfers and Limit Orders: ERC-7683 primarily focuses on cross-chain intents. This focus may limit its applicability to other forms of intents, potentially restricting its broader use in the intent-based protocol ecosystem. However, it’s important to consider Across’s argument: they believe most cross-chain operations will be simple transfers rather than complex multi-step actions. These typically involve an initial cross-chain transfer followed by further execution on the destination chain. Essentially, the standard addresses the most common cross-chain use case: transfers. And it can be combined with single-chain operations to satisfy various intents, rather than covering all possible intents within the standard itself.
Solver Collaboration to Execute Intents—Khalani as an Example
Currently, most intent-based protocols focus on a limited set of operations across a small number of chains, such as swaps and bridges.
To truly become a dominant design architecture, intent-based systems need to go beyond swaps and bridges, supporting a wider range of operations including staking, lending, fiat on-ramps, and more.
One way to support more types of intents is by introducing specialized solvers. By bringing in solvers with expertise in these specific areas, we can ensure each intent is executed with the highest level of professionalism, leading to more optimized outcomes.
These specialized solvers must work together, not in isolation. This collaboration will allow intent-based protocols to execute a broader range of intents, combining multiple operations to satisfy more diverse user goals.
Platforms like Khalani propose a solution enabling solver collaboration. Instead of competing, solvers cooperate to find the best solution for each user intent. This allows many smaller, specialized solvers to collaborate effectively.
Image:Introducing Khalani Platform, Source: Introducing Khalani
As Kevin Wang, co-founder of Khalani, describes it: Khalani is a peer-to-peer platform for solver “coincidence of wants.” Collaboration enables breaking down complex intents into smaller, specialized (or composable) intents, each handled by individual solvers.
Khalani provides a platform where solvers can combine their resources and expertise to handle specific user intents more efficiently. Think of it as a solver pool akin to staking pools—by pooling resources, participants can achieve more consistent and potentially higher results than operating alone.
To understand how Khalani enables solver collaboration, let’s consider an example.
Suppose Bob is an Ethereum user holding USDC who wants ETH on Arbitrum via an intent-based bridge.
Here’s how solvers using Khalani execute this intent:
-
Bob submits his intent: “I want to exchange my USDC on Ethereum for ETH on Arbitrum.”
-
The intent-based bridge selects an exclusive solver to fulfill Bob’s intent—we’ll call this Solver A, the chosen one.
However, Solver A lacks sufficient inventory on Arbitrum to fulfill Bob’s intent, so it decides to leverage Khalani’s solver pool to source the needed capital.
-
Solver A sends an intent to Khalani requesting other solvers (or a combination) to provide capital on Arbitrum in exchange for Bob’s locked funds on Ethereum.
-
Another solver, Solver B (an Arbitrum whale), holding inventory on Arbitrum, provides the required assets to Bob.
-
User-Solver Settlement—Once Solver B fulfills Bob’s request, Solver A provides proof to the settlement platform (in this case, the intent-based bridge) to settle with the user. As a result, Solver A receives Bob’s USDC on Ethereum.
-
Solver-Solver Settlement—Solver A provides execution proof to the Khalani chain to settle with Solver B.
While this is a simplified example showing how solvers collaborate on Khalani to fulfill intents, Khalani can use the same process to execute more complex intents.
For example, Bob is an Ethereum user holding USDC who wants to deposit ETH into a lending platform on Arbitrum.
In this case, the selected solver can collaborate with multiple specialized solvers on Khalani based on required expertise:
-
Solver A (Pricing Specialist)—Runs specialized software to find the most accurate prices for on-chain or cross-chain pairs. It can price USDC/ETH liquidity using on- and off-chain data.
-
Solver B (Arbitrum Whale)—Holds inventory on Arbitrum that can be used to supply the required amount of ETH on Arbitrum.
-
Solver C (Ethereum Executor)—Specializes in optimal execution on Ethereum, offering users trade-offs between price and latency. It can be used to execute transactions to acquire the user’s deposit on Ethereum.
-
Solver D (Arbitrum Executor)—Specializes in executing transactions on Arbitrum. It can be used to execute local transactions depositing ETH into the lending platform on Arbitrum.
Similarly, other specialized solvers on Khalani can be called upon to break down complex intents into simplified tasks executed by multiple solvers, instead of relying on a single solver to do everything.
By solving problems through the Khalani platform, a wide range of intent executions become possible—a major breakthrough for the intent-based paradigm. However, potential bottlenecks may exist at each step of this process, affecting intent execution:
-
User Errors When Submitting Intents: When an app’s user interface (UI) is designed to collect specific intents (like swaps or bridges), the scope for user errors is limited because users receive clear guidelines when submitting intents. However, UIs designed to collect broad intents may be more challenging and prone to users submitting incorrect or incomplete intents, leading to failed or erroneous intent execution.
-
Liveness Risks: In intent systems, there’s a risk solvers may be unavailable, potentially stalling the entire system. Additionally, solvers may fail to correctly or timely perform their tasks, causing transaction failures.
-
Limited Solver Availability: There may be only a limited number of solvers available on the Khalani infrastructure for different types of intents. This could reduce the likelihood and overall efficiency of intent execution.
-
Complexity in Coordinating Solvers: Coordinating multiple solvers can be complex and error-prone due to many factors, such as availability of specialized solvers, market conditions, and intent-specific factors (like involved chains, required capital scale, etc.).
-
Risks Related to Atomic Execution: All solver operations are atomic and executed together on the Khalani chain. This means solvers experience atomicity on Khalani—either all parts succeed in a single operation, or none do. If any part fails, the entire transaction is rolled back, potentially leading to a higher intent failure rate. However, there’s no risk of funds getting stuck or lost.
-
Solver Collaboration Adds Latency: While discovery happens off-chain and nearly instantaneously, some latency is added due to the following factors:
-
Task Dependencies: Certain tasks may depend on the completion of others. Coordinating these dependencies and handling errors may introduce delays as solvers wait for prior tasks to complete.
-
Security and Validation Steps: Implementing security checks and additional steps to validate transactions and prevent fraud or malicious behavior may add latency.
To ensure reliable and high-quality intent execution, despite these potential delays, some intent-based protocols run permissioned auctions and choose to work only with trusted, whitelisted solvers.
However, it’s important to note that this delay depends on the task and doesn’t differ whether a task is executed by a single solver or multiple solvers collaborating—it’s similar across all intent-based protocols relying on solver execution.
The Flywheel Effect of ERC-7683 and Khalani
Solver infrastructure platforms will likely be compatible with standards like ERC-7683, as it’s a win-win for all participants. The primary goal of these projects and initiatives is to attract more solvers into the ecosystem. If we can achieve that, compatibility between the two can kickstart a flywheel effect for the intent-based paradigm:
Figure: More solvers—As the number of solvers increases, so does the variety of executable intents
-
More Solver Collaboration: As more specialized solvers emerge, opportunities for collaboration grow. Solvers can combine their specialized skills to handle more complex intents.
-
Greater Expressiveness of Intents: Collaboration among solvers increases the expressiveness and complexity of user intents. Users can request more complex operations requiring multi-step processes and specialized knowledge.
-
Need for a Common Standard: As intent expressiveness grows, intent-based applications need a shared standard to ensure solvers can easily plug into a common interface and collect intents from different apps.
Capital-Efficient Intent Settlement—Everclear as an Example of a Clearing Layer
During intent settlement, solvers receive repayment on the source chain where the user generated the intent. This means their funds become scattered across multiple chains, requiring constant rebalancing. Not only is this cumbersome to manage, but it also ties up significant capital. And the more chains there are, the more fragmented liquidity becomes for each solver.
Currently, there’s no shared system to coordinate these inter-chain capital flows. Each solver operates like a lone wolf, managing liquidity in this fragmented environment. Everclear was created to solve solver rebalancing challenges.
Everclear coordinates global liquidity settlement across chains via a “clearing layer”—a decentralized network responsible for netting and settling global inter-chain capital flows.
At the heart of Everclear’s value proposition is the concept of netting.
Netting is a mechanism that aggregates multiple payments between different parties to reduce the total number of net payments. Instead of processing each transaction individually, netting calculates the total owed between parties, and only the difference needs to be paid. This simplifies the process and reduces the number of payments.
For those familiar with crypto nomad life, you probably know Splitwise—an app that helps groups track shared expenses, like during travel. The “Settle Up” feature in Splitwise is a perfect example of netting:
-
Track Expenses: Each group member logs their expenses into the app.
-
Calculate Balances: Splitwise computes how much each person owes or is owed.
-
Settle (Netting): Instead of multiple pairwise payments, Splitwise calculates the simplest way to clear all debts.
This netting concept is also used by remittance companies like TransferWise. Instead of physically moving money across borders, they match senders and receivers with opposite currency needs and settle internally. This reduces actual transfers, making the process more efficient and cheaper.
Similarly, Everclear allows solvers to “settle up” with each other across chains, drastically reducing the total number of settlements needed, thereby lowering solver costs, inventory needs, and overall complexity. For those familiar with how CowSwap works, netting is essentially large-scale demand matching among solvers over a given period.
Figure:Introducing Everclear Platform, Source: Introducing Everclear
Everclear estimates that about 80% of daily cross-chain capital flows can be settled via netting. This means that for every $1 flowing into a chain daily, $0.80 flows out. This suggests that overall, five times more capital is sent across bridges than necessary, and solvers rebalance far more frequently than needed because they operate in isolation.
Let’s examine how users (such as intent-based protocols, solvers, or centralized exchanges) can leverage Everclear’s tech stack.
Consider Alice, a solver who prefers settling on Arbitrum. Alice needs to complete a 10 ETH transaction from Optimism to Arbitrum. Here’s the process with and without Everclear:
We can see the benefits of a clearing layer like Everclear for users such as solvers and market makers like Alice:
-
Settlement Preference: Alice prefers settling 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. By handling rebalancing via Everclear, the overall workflow becomes simpler. This is particularly attractive for new participants joining the solver pool.
-
Reduced Operational Overhead: By eliminating the need for manual rebalancing, Everclear reduces Alice’s operational overhead, allowing her to focus on solving more transactions.
-
Cost Savings: Avoiding bridging funds across chains saves transaction fees and potential slippage, making the process more cost-effective for Alice. This could also lead to more stable operations and potentially higher income.
By eliminating a major pain point for solvers, Everclear can incentivize more participants to join the ecosystem, ultimately fostering a flywheel effect of more solvers entering the space.
Everclear’s positioning within the intent tech stack allows any protocol or infrastructure involving solvers to leverage it for rebalancing and to reduce solver costs and operational complexity.
For example, solver infrastructures like Khalani will integrate with Everclear, enabling collaborating solvers via its tech stack to leverage Everclear for capital-efficient settlement. Thus, Everclear’s launch can be seen as a positive development for the intent-based paradigm, improving various projects in the ecosystem and expanding the market.
To achieve this, Everclear is designed as an Arbitrum Orbit rollup using EigenDA technology, in partnership with Gelato RaaS. At alpha mainnet launch (planned for early Q3 2024), Everclear will operate under certain restrictions and safeguards:
-
Permissioned Asset and Chain Support: Initially, only whitelisted chains and assets will be supported, limiting system openness and availability. However, plans exist to eventually become permissionless.
-
Reliance on Eigenlayer: Everclear relies on Eigenlayer for security but currently does not support slashing. This limits economic security until slashing is implemented. Users must trust that Eigenlayer will implement slashing in the future to enhance economic security. Until then, Everclear plans to use Hyperlane’s validator set ISM for security.
-
Upgradeable Smart Contracts: Everclear will launch with upgradeable smart contracts. While this allows flexibility, it also introduces risks if mismanaged, such as potential vulnerabilities during upgrades.
Note: The alpha mainnet is similar to a public testnet phase for Everclear. Full launch will support permissionless chain expansion, allowing chains to define their own security preferences.
Additionally, as a clearing mechanism, Everclear carries certain potential risks and trust assumptions:
-
System Failure: Downtime or failures during upgrades could interrupt the clearing process, causing delayed or incorrect settlements. This would affect all users leveraging Everclear. Everclear’s clearing window is estimated every 3–6 hours, so only prolonged downtime would impact user operations. If such a failure lasts long, the main impact would be on user experience, not fund safety. This is because Arbitrum Nitro has a built-in “force update” function. In case of downtime, users can use this to exit transactions on L1, ensuring they cannot be censored.
-
Reliance on Market Makers as Arbitrageurs: Everclear offsets settlements among solvers via netting whenever possible. If netting fails, they turn to arbitrageurs to buy solver invoices. This relies on market makers purchasing these invoices at a discount. To bootstrap the system, Everclear is actively partnering with major market makers to fill this critical role.
-
Auction Dynamics: If netting fails, relying on auctions to arbitrageurs may introduce volatility and unpredictability in repayments. However, the Everclear team believes this impact is manageable for two reasons:
1) Arbitrageurs will operate based on predictable pricing curves, reducing uncertainty in their bids;
2) An active and liquid pool of arbitrageurs will ensure competition and possibly stabilize prices during auctions.
This combination of fixed pricing curves and a liquid arbitrage ecosystem should help provide solvers with more predictable repayment outcomes when auctions are needed.
Conclusion
Every once in a while, a new idea dares to challenge the status quo. The intent-based paradigm is exactly such a concept, aiming to completely transform how users interact with blockchains.
Currently, this concept is still in its early stages, and only time will tell if it will succeed. But one thing is clear: With intents comes the need for many solvers; if we are to enter the age of intent in crypto, we will need many more solvers.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@lifiprotocol
