Solvers: The Backbone of Intent-Based Transactions
How Solvers Handle User Intents and Manage Cross-Chain Operations
This chain abstraction series article was made possible thanks to our partners, Particle Network and Everclear, two projects at the forefront of improving the web3 experience for users.
In the previous article of our Chain Abstraction series, we broke down the permission layer of chain abstraction, as shown here in the CAKE Framework.
As a quick recap, the permission layer serves as the interface between users and blockchains. It's where users interact with decentralized applications (dApps), connect their wallets, and initiate specific actions, referred to as "intents." This layer simplifies the user experience by consolidating blockchain interactions into a single interface, allowing users to seamlessly operate across multiple chains using a unified asset balance.
However, recall that Chain Abstraction is not one single product or solution, it’s the culmination of different projects across different layers working together to create this chain abstracted experience for users. So while the permission layer enables users to manage assets across multiple chains through a unified wallet interface, it doesn't solve all complexities—someone still needs to interact with the blockchains to fulfill these intents. This is where the solving layer comes into play.
The Role of Solvers in Chain Abstraction
In today's transaction-based model, the user specifies each step of the process, such as: "I want to swap 100 USDC for ETH on Uniswap with a 0.5% slippage tolerance." However, in the intent-based model, which the industry is shifting toward, the user only defines the desired outcome, not the exact path to achieve it: "I want to swap 100 USDC for the maximum amount of ETH at the lowest cost."
Once the user's intent is set through the permission layer, the solving layer takes over. This layer handles the complexities of fulfilling asynchronous, cross-chain transactions. Solvers are offchain agents responsible for interpreting the user's intent and efficiently executing it across the appropriate blockchains and dApps.
Solvers handle the execution of user intents by managing several key responsibilities:
Route optimization (Discovery): Finding the most efficient path across various chains and dApps to fulfill the user's intent.
Fee estimation: Calculating how much it would cost to execute the user's intent (e.g., swapping ETH for TIA)
Execution speed estimation: Predicting how long it will take for the transaction to settle.
Intent execution: Performing the transaction on behalf of the user, removing the need for the user to interact directly with multiple blockchains.
Verification
Since solvers are offchain agents tasked with finding the most optimal path to execute user intents, ensuring proper verification becomes a critical challenge. This applies to both the users and solvers involved in the process.
For end-users: It’s essential that users can verify whether the solver provided the best possible execution route. For example, if a user wants to swap 5 USDC for 5 USDT, they need assurance that the solver delivered as close to that exact value as possible, and that the transaction was completed efficiently.
For Solvers: Solvers must also verify that users have escrowed the required funds before expressing their intent. Since solvers often fulfill user requests by providing their own liquidity upfront, they need to guarantee that the user’s funds are locked in escrow. Once the solver fulfills the intent, they can recover the escrowed funds to replace the liquidity they initially used.
Currently, many solver networks rely on validator networks to ensure accuracy and fairness during this process. However, the ideal solution would involve using Zero-Knowledge (ZK) proofs for verification. That said, the widespread use of ZK proofs is still limited by factors such as high costs and slow proving/verification times. But projects like Risc Zero, Succinct, Aligned Network, and Nebra are working on improving ZK proof speeds and reducing costs of proving/verification, pushing us closer to making this a reality.
Benefits of Solvers
For users, solvers abstract away the complexities of blockchain interactions, such as bridging, or connecting to different chains. Instead, solvers handle these details, ensuring the intent is fulfilled based on the user's preferences—whether prioritizing speed, cost, or execution guarantee.
For developers, the solving layer offers a significant advantage. Applications can be deployed on a single chain, yet still access users and liquidity across the entire ecosystem, with solvers bridging the gaps between chains.
The Specialization of Solvers
The current landscape of solvers is highly specialized.
If you recall from our last article about the permission layer, there were two wallet teams, Particle Network and Arcana Network, which both provide a unified experience for end-users. However, aside from providing users with one single interface for interactions across all chains (the permission layer), they also operate their own internal solver network that fulfills these user intents on the backend, whenever expressed through their wallet solution (it’s specific to these respective solutions).
Or let’s take a look at a meta DEX aggregator like CoWSwap, which was one of the first teams to leverage intents and a solver network.
When you go on to CoWSwap, you as a user express your intent for some swap, or action. Then on the backend, a network of solvers bid for the right to fulfill your swap (in this case it’s the solver who “finds the most surplus”). However, each solver in such a network can have a specific focus:
DEX-specific solvers: Some solvers operate only on particular exchanges.
Asset-specific solvers: Others only handle certain assets, such as ETH or USDC.
Gas-constrained solvers: There are even solvers that only operate within specific gas price ranges.
Another interesting project we can look at is Mantis—this project is building a solver network specifically focused on solving intents between Solana and Ethereum.
This level of specialization ensures that user intents are fulfilled as efficiently as possible, given the solver's area of expertise. Plus, it allows solvers to own specific areas of the market.
How Do Solvers Get Selected?
Solvers are essentially those with access to a blockchain mempool, where they can batch and execute user intents in exchange for some reward for their service.
When a user expresses an intent, solvers bid for the right to execute that intent. This is typically done through some form of an order flow auction, where solvers compete based on various factors such as cost, speed, or surplus offered to the user.
Okay, but how do you decide who gets to bid for these rights? There are generally three types of solver access models:
Open Access: permissionless; within this permisisonless solver network, the selected solver could be the solver who bids the highest amount, the solver who offers users best pricing for their intent, or the solver who provides the fastest time of execution.
Gated Access: some gatekeeping involved, such as the staking of a certain amount, having your name on a whitelist, or some reputation system. Again, within this whitelisted group, the solver selected for any specific slot could be the solver who bids the highest amount, the solver who offers users best pricing for their intent, or the solver who provides the fastest time of execution.
Exclusive Access: there is some network of independent solvers, and within this network, only one solver is selected at a time.
Centralization Challenges in the Solver Ecosystem
While solvers simplify cross-chain operations, several challenges remain, with one of the key ones being centralization.
Today’s solver networks are often centralized due to two factors:
Cost
Learning Curve
Cost
One of the key factors determining which solver can fulfill a user’s intent is speed—who can execute the intent as quickly as possible, based on the user’s specific needs or parameters. Think about it: when you use a typical web2 app today, you don’t want to wait three seconds for a page to load—you expect instant results.
To achieve this kind of speed, many solvers often bring their own liquidity to the table. For instance, if I want to swap my ETH on Base to USDC on Polygon, instead of waiting for the bridging process or relying on sourcing liquidity from a public pool, a solver might front the USDC from their own locked liquidity on Polygon to complete the swap immediately.
However, in an ideal scenario, solvers wouldn’t need to provide their own liquidity. Instead, they could rely on a separate, public liquidity layer that aggregates funds from various sources. This would allow the solver layer to focus purely on finding the most efficient routes for transactions, optimizing speed and performance.
But doesn’t this create risk for solvers? After all, they’re the ones who will ultimately wait through the 7-day challenge period to verify whether the user’s intent was valid or malicious.
In short, yes. This is another key advantage for end-users comes—the risk of these cross-chain operations shifts from the user to the solver.
This is critical because, just as we want the fastest execution possible, we also demand guaranteed security. Users shouldn’t have to research every new dApp they interact with to ensure its safety or decentralization—especially in a chain-abstracted future, where much of this technical information will be hidden from the user.
Learning Curve
Aside from the financial cost of becoming a solver, there's also a significant learning curve involved. As discussed in our recent solver-focused panel, it typically takes about 5-6 months of preparation to become an effective solver. This involves learning the intricacies of the protocol you wish to solve for, and developing an efficient algorithm that can identify the best routes to maximize your chances of winning bids to fulfill user intents.
One interesting team looking to tackle this issue is Enso Network.
Enso Network
For those new to Enso, this is a team building an intent engine to power the intent-centric future. Specifically, Enso is developing a shared network state, connecting all ecosystems within a single network. When a developer or user interacts with Enso, they express an intent, or a specific outcome. Once this intent is expressed, a network of solvers fulfill these actions on the backend—selected solver is based on who can provide the best execution for users.
To make their network more approachable for solvers (to attract more solvers, thus decentralizing the network), they have essentially modularized their solver layer into distinct roles.
Graphers: These are the individuals who focus on building the winning algorithms, which are ultimately those who find the most optimal execution paths to solve consumer requests (intents).
Action Providers: These are developers who contribute pre-built smart contract abstractions to the Enso Network. These abstractions act as building blocks that Graphers can use to assemble the best solutions for fulfilling consumer intents. This makes it easier for Graphers to optimize their algorithms without reinventing the wheel for each new task.
Validators: These participants ensure the integrity of the network by validating the solutions proposed by Graphers and Action Providers. Validators are responsible for authenticating the abstractions and determining the winning solutions that will ultimately fulfill user intents. They play a key role in securing the network by verifying that the results are accurate and free from errors or manipulation.
Another team looking to tackle the issue of centralization is Khalani Network, which is taking a “collaborative solving” approach.
Khalani Network
Khalani Network is developing a permissionless solver network using a design known as collaborative solving. Instead of solvers competing through bidding wars, this approach fosters collaboration among solvers to collectively fulfill user intents. This model not only decentralizes the solving process but also helps address the issue of hyper-specialized solvers by creating a network that any dApp, that’ll like to take advantage of the intent-centric approach, can tap into.
Like Enso, Khalani also carries a modular architecture:
Intent Compatibility Layer: Converts user intents into a format solvable by the network.
Validity & Validity VM: A language and execution environment for processing intents.
Universal Settlement Layer: Ensures atomic settlement of intents across ecosystems.
Nodekit
Looking at the CAKE Framework image, we can see that sequencers can also play a role here. In this context, sequencers are considered solvers since they act as block builders, having access to blockchain mempools and facilitating cross-chain transactions for end users.
However, sequencers can also significantly improve the solving process for solvers. A prime example of this is Nodekit. Nodekit is developing a decentralized shared sequencer featuring a "superbuilder" called Javelin, which enables synchronous communication between chains.
Recall that we are headed to a world with thousands of chains/rollups, thus placing us in a world with asynchronous blockchain interactions. That said, there are still going to be cross-chain use cases that require synchronous composability (e.g., flash loans). In order for solvers to offer synchronous composability within an asynchronous world, they’ll need to leverage a team like Nodekit, which can bundle transactions across multiple chains, and ensure that they get done together at the same time, within the same block.
In fact, it sounds like Khalani Network will be leveraging Nodekit’s Javelin in order to allow Khalani’s solver network to offer synchronous composability—this was mentioned in our recent solver-focused panel discussion.
Other Challenges & Opportunities
Privacy
Another potential challenge to observe is privacy.
Since solvers access blockchain mempools, they can see transaction details, raising the potential for MEV (Miner Extractable Value) leakage. This issue will need to be addressed as solver networks grow, whether through ZK, TEE, or FHE.
Expressivity in Intents
As the solving layer matures, one exciting area of development will be the expressivity of user intents. Currently, most user parameters are determined by dApp developers, and event hey’re limited in what can be expressed given today’s landscape, but future advancements may allow users to define more specific preferences, such as which chains or liquidity pools to use.
Will the end-user even be able to specify exact parameters themselves (only use DEXs with a TVL > X, or only source from these four chains, etc), or will it always be up to what each dApp developer encodes?
I’m curious to see how this plays out!
Conclusion
Solvers represent a crucial component in the future of blockchain interoperability and chain abstraction. They shift the complexity of cross-chain operations from the end user to sophisticated agents, ensuring seamless, efficient, and safe execution of user intents across multiple blockchains. While the system faces challenges related to centralization, several exciting teams are working to change this through innovative approaches, such as with Enso Network, Khalani, and Mantis.
As the technology behind solvers evolves, it will unlock new opportunities for both users and developers, ultimately making blockchain interactions as easy as interacting with a web2 application—fast, simple, and reliable.
gmullet 🫡
& a huge thank you to our two additional partners who helped us craft this series: Arcana Network, and Nuffle Labs.