Mental Models for Intent-Solver Systems - Part 2

Special thanks to Kevin Wang ( Khalani Network), Mike ( Nomial ), Vishwa Naik ( Anera Labs ), Victor Alagbe ( Across Protocol ) and Manank Patni ( Epoch Protocol ) for their feedback and review.

Intent-solver systems are the silent engine behind Chain Abstraction.

In fact, they are one of the most crucial pillars that take us closer to a Chain Abstracted web3. It's imperative to understand how they work.

Therefore, I have been deeply researching 10+ intent-solver systems and created mental models of their imperative components, zones, players, and their positions in these systems.

My previous article argued why an intent-solver system works best for Web3 Interoperability.

In this article, I want to share the mental models to understand how intent-solver systems work, behind the scenes.

Let's dive right in.

Bare Basics of Intent-Solver-Based Systems

Here is a quick overview of how these systems usually work :

• The user expresses an intent, i.e., an on-chain action they wish to take. ( let's say bridge token X from Ethereum to Polygon )
• The system uses its solver-competition mechanism to pick a winning solver.
• The winner solver is responsible for fulfilling the user's intent. In this case, the solvers use their liquidity to send the required funds to the user on the destination chain ( polygon) in seconds, thus taking the finality risk. ( URL )
• The user receives the funds instantly without dealing with any on-chain intricacies or risks or waiting for finality - a.k.a users happy.
• Solvers provide proof of intent fulfillment to the system.
• The system provides a settlement for the solvers, i.e., reimbursement of solvers for all valid executions they performed - a.k.a solvers happy.

The diagram below can give an eagle-eye perspective of what intent-solver-based bridging looks like in action

Now that we have the basics, let's dive deep and create our mental models of how these systems work.

The 5 Components of Intent-Solver-based System

A typical Intent-Solver system has the following 5 core components:

1. Intent Expression
2. Solver Selection
3. Intent Fulfilment
4. Proof of Completion
5. Solver Settlement

The system's approach toward implementing each of these components determines its overall efficiency, decentralization, speed, as well as liveness.

1. Intent Expression

This component allows users to express their intent for any on-chain action.

The core responsibility of this component is to:

• Accurately capture the user’s intent.
• Organize captured intent for solvers to interpret accurately.

Although that sounds simple, it isn’t.

A user’s intent can range from being too simple to extremely complicated.

Bob might be happy bridging his 100 tokens from chain A to B
( a.k.a, simple intent),

while Alice wants to sell token X on chain A only if a specific governance proposal number #112 passes
( a.k.a, complicated conditional intent ).

Therefore, we can lazily categorize intents into two different types for now:

• Simple Intents: Cross-Chain Bridge, Limit order execution ( the classic intent use case, lol ), etc.
• Advanced Intents: Cross-chain swaps, Generalized Intents, Conditional Intents, Multi-Step Intents, or Intent Graphs, etc.

To capture a user's intent, systems usually provide an interface/app where users can express their intents with a few clicks (Cowswap UI or UniswapX are good examples).

The expressed intent is then captured and organized to make it easy for solvers to interpret the user's requirements accurately.

Since these systems are still nascent, no widely adopted standards for organizing user intent exist yet. Thus, different systems define their ways of organizing intents.

For instance:

1. DLN, an intent-based system, uses the following structure to organize the user's intent ( ref: contract code ):

    /// @dev Struct representing the creation parameters for creating an order on the (EVM) chain.
    struct OrderCreation {
        
        address giveTokenAddress;
        
        uint256 giveAmount;
        
        bytes takeTokenAddress;
        
        uint256 takeAmount;

        uint256 takeChainId;

        bytes receiverDst;

        address givePatchAuthoritySrc;

        bytes orderAuthorityAddressDst;
   
        bytes allowedTakerDst;

        bytes externalCall;

        bytes allowedCancelBeneficiarySrc;
    }

2. While, another intent-based bridging system, i.e., Across, uses the following
   ( contract code ) :

    struct V3RelayData {
        address depositor;

        address recipient;

        address exclusiveRelayer;

        address inputToken;

        address outputToken;

        uint256 inputAmount;
        
        uint256 outputAmount;

        uint256 originChainId;

        uint32 depositId;

        uint32 fillDeadline;

        uint32 exclusivityDeadline;

        bytes message;
    }

The lack of standardization around intent expression ( and organization ) is concerning. Here are a few reasons behind this concern:

1. When systems define their own app-specific rules, it makes a solver's job quite challenging. Solvers are required to invest a plethora of time and effort to support the system and remain competitive, for every new standard or system. Failing to do so means less or no intent for solvers to fill, as we'll see in the next component).
2. This eventually leads to diminishing solver support for new systems - which makes intent-filling centralized, expensive, and inefficient. That's the reason why most intent protocols have their own set of solvers, as it's challenging to onboard more solvers.
3. There is a financial cost attached to wrongly interpreting user's intents. If there are no specific standards, solvers are required to build different scripts to support different systems. This increases the chances of errors which can eventually lead to financial losses as most on-chain intents are tied to money.

On the other hand, having an open and widely agreed-upon standard makes it easier for such a system to onboard or tap into the existing solver network, instead of having to create one from scratch.

A significant attempt at standardizing cross-chain intent expression and organization was made through ERC-7683, raised by the Across protocol and Uniswap Labs to establish a unifying framework for intent-based systems to specify cross-chain intents.

With ERC7683, intents should have a specific framework and look like this. And then see how Vitalik feels about it.

Another such standard is EIP-7521 which aims to provide a generalized intent specification for smart contract wallets.

While creating a cross chain standard is a difficult problem, ERC-7683 is by far the closest to achieve this. With more than 35 protocols supporting this standard, it will most likely be the global standard for organizing cross-chain intents soon.

Intent Expression along with Authorization

Finally, this component also involves authorization. The user must authorize the system/solvers to use his/her funds that are required to fulfill the intent.

In our example, Bob must authorize the system to use his 100 token X to execute his bridging intent.

For instance:

• Across requires users to deposit or sign the authorization to use their funds, which are deposited on an escrow-like contract on the source chain.
• Or, when performing a limit order, CoWSwap requires users to sign and authorize the use of their funds by the protocol.

Once the user expresses their intent and authorizes the required funds, the system moves to the next phase.

2. Solver Selection

Solver selection is the process where specialized on-chain actors (solvers) compete to fill user's intents. While some systems have permissioned solver networks, there are others that are permissionless and allow anyone to become a solver - me likey.

Ideally, the system should have a fair mechanism to select the right solver for the job.

But wait...

Why a Fair mechanism? And, who is the Right Solver?

The Right Solver

The definition of a right solver can vary with the user's need or what the system is designed to offer. However, the following metrics are the most common ones:

• Faster Solvers: Solvers who can fill your intent quickly.
• Efficient Solvers: Solvers who can provide efficient results, i.e., better rates for cross-chain swaps, for instance.

We are still talking about Simple Intents.
The metrics could change with Generalized or Advanced Intents

Why a Fair Mechanism?

• A fair mechanism for solver selection indicates healthy competition in the network which is far better than a handful of solvers executing most intents.
• Without fair competition between solvers, the system ends up having a monopoly ( a.k.a, centralized solver network). This opens up new challenges:
  • The dominant solver ( or solver group ) could easily manipulate the system with their high fees, delayed executions, frontrunning or sandwiching orders, exploiting order flows, etc. Without a fair & decentralized selection mechanism, there is little to no resistance to these actions.
  • The system itself is at a liveness risk if it relies on just a handful of solvers. Relying on a select few solvers could potentially halt the entire system if solvers aren't available or stop participating.
  • Additionally, lack of competition leads to terrible UX. Users won't get better rates and will have to adhere to the rates and fees offered by the dominant solver in the network, thus adversely affecting the fairness of the system and overall UX.
• Solvers are crucial actors and it's in the best interest of the users ( and the system ) to have decentralized solver networks.

That said, let’s explore a few solver-selection mechanisms across different intent-solver-based systems today:

• Request for Quote (RFQ): In RFQ auctions, users submit an order, and solvers have a limited timeframe to bid. RFQs optimize for price, as solvers compete to provide the best bid within the time window. The bid offering the highest execution quality wins.
  
  This method is ideal for optimizing transaction prices, though it introduces a slight delay for solvers to participate.
  Used in: Across, Uniswap, etc.
• First Come, First Served (FCFS): FCFS prioritizes execution speed, immediately accepting the first solver bid that meets the order’s minimum requirements. This approach ensures rapid order fills but may sacrifice optimal pricing as no competitive bidding occurs.
  Used in: DLN, Nitro, Synapse
• Batch Auctions: Orders are grouped together into batches and processed simultaneously. Here solvers compete to find the optimal liquidity sources for each batch. The one with the best outcome wins.
  
  The key feature of this approach is how each batch clears at the best uniform price, reducing arbitrage risk. This mitigates MEV attack risks as the order of a transaction becomes irrelevant due to uniform clearing prices.
  Used In: CowSwap
  
• Dutch Auctions: In this mechanism, the auction begins with an initial high price, which gradually decreases until a solver accepts it.
  
  Solvers aim to execute the trade profitably before others do, encouraging competitive bidding without an explicit bidding window.
  
  This model is effective for quickly identifying buyers, offers added MEV protection, and minimizes reliance on AMMs, though it requires solvers to have sufficient liquidity on hand.
  Used In: UniswapX

Batch Auctions could be a bit slower than Dutch Auctions as batches need to be live for some time to collect orders.

However, they are also quite efficient as batch auctions allow liquidity to be shared between p2p, thus providing better value than any on-chain venue.

Check - Batch Auction vs Dutch Auction

A good comparison of the fair solver selection mechanism can be found on intent.markets. Unfortunately, most systems aren't fair enough yet as you can see below - but it's just the beginning.

3. Intent Fulfilment

Now that the solver is selected, it is time to fulfill the intent.

The core aspect of this component lies in how quickly and efficiently the selected solver can fulfill the user’s intent.

Unlike traditional interoperability, which waits for the chain's finality to move users' funds, the solvers in these systems don't. They take the finality risk and front the required liquidity as efficiently and quickly as possible to the user on the destination chain. ( ex: Across does it in a mere 2-3 seconds).

Solvers use different techniques and strategies to prove their efficiency in the system such as algorithms to find the best route for swaps, mechanisms to protect users from MEV, implementing optimized mechanisms to save gas, efficient routing algorithms, etc.

However, the crucial aspect is the access to liquidity.

The easier the access to liquidity,
the faster & more efficiently
the solvers can fill the orders,
resulting in Better UX for users...

As of today, there are multiple ways a solver leverages liquidity to execute.

1. Solver’s Inventory—The Simple Way:
   The solver can use its funds to execute intent orders and earn fees. Needless to say, being profitable with this approach requires solvers to have a massive inventory. The bigger, the better.
   
   There are a few common sources of liquidity available for solvers in this category can leverage:
   1. AMMs: Leverage existing AMMs like Uniswap, Sushiswap, Balancer, etc as liquidity sources.
   2. Dex Aggregators like 1inch, Paraswap, etc.
   3. Private Market Makers who operate outside of public DEXs
2. Direct P2P Order Match—The “Coincidence of Wants” way:
   This innovative approach was introduced by CoW protocol where they connect matching similar orders to fill intents. The "Coincidence of Wants" (CoW) theory is a classical economic principle where two parties directly swap assets, each holding what the other desires, thereby eliminating the need for an intermediary.
   
   For instance,
   - if Alice wants 500 DAI for 0.25 ETH,
   - while Bob wishes to exchange 0.25 ETH for 500 DAI,
   the system can directly match these two orders.
   
   Instead of executing two separate transactions on an AMM, Alice and Bob’s trades are matched peer-to-peer. If a trade cannot be fully fulfilled through CoW matching (e.g., Bob wants to trade a larger amount of ETH than Alice’s order covered), the unmatched portion is routed to on-chain liquidity pools to complete the transaction.
   
   Another system, i.e., Everclear also uses the CoW approach for clearing and settlement purposes. We discuss this in detail below.
   
   A few benefits of this approach:
   • Lower Fees: Peer-to-peer trades bypass liquidity provider fees and reduce gas costs by eliminating the need for complex interactions. Unlike the typical AMM model where users pay fees to liquidity providers.
   • Protection from MEV: Since CoW trades are matched off-chain and do not rely on traditional AMMs, they are immune to MEV attacks.
   • Reduced Price Impact: By fulfilling a portion of these trades via direct matching, CoW Swap minimizes price impact, making it particularly beneficial for sizable trades or illiquid assets.
3. Borrow Liquidity—The “Nomial” way:
   Another innovative solution to solvers' liquidity crisis is by Nomial team.
   
   The Open Liquidity Network by Nomial is designed to address liquidity challenges in intent-based bridging systems. Unlike traditional filler-based liquidity models that require fillers to maintain a fragmented inventory across chains, Nomial introduces a network of cross-chain liquidity pools accessible to fillers on demand.
   
   This approach decouples the roles of liquidity providers and fillers, allowing any user holding assets on an L2 chain to participate as an LP by passively contributing to a liquidity pool.
   
   Fillers act as sophisticated relay agents who borrow liquidity from these pools to execute cross-chain intents, reducing the complexity and risk associated with managing liquidity across multiple chains.

A few benefits of this approach:

• Decentralized Liquidity Access: Nomial pools allow any user to contribute liquidity passively, thereby democratizing access to intent settlement opportunities.
• Bond Mechanism for Security: Fillers post a bond on the Nomial Rollup, which acts as a security measure to ensure they repay what they borrow. If a filler fails to repay, challengers can initiate a liquidation process, converting pooled assets to ETH, thus maintaining the pool's integrity and ensuring LPs are protected.
• Optimistic Settlement and Pool Rebalancing: The system utilizes an optimistic settlement model, where fillers can instantly access liquidity to fulfill intents and settle their input obligations later. Additionally, pools are balanced by market arbitrage rather than a lock-and-mint model, making it more adaptable to fluctuating asset values and non-atomic swaps.

A detailed guide to understand Nomial's approach can be found here

Through this design, Nomial empowers both small token holders and advanced fillers, enabling efficient cross-chain intent fulfillment without capital inefficiency or high operational barriers associated with traditional liquidity models.

4. Solver Co-operation instead of Competition—The “Khalani” Way:
   One of my favorite approaches is by the Khalani team.
   
   Khalani proposes a collaborative framework for solvers, addressing limitations in the traditional competitive landscape of intent-solving systems.
   
   Traditional intent-based protocols often rely on solvers that operate in a competitive "winner-takes-all" setup. Only a few powerful solvers with extensive resources and vertically integrated operations manage to thrive, thus pushing solvers toward centralization, eroding decentralization principles, and creating high barriers for new entrants.
   
   Khalani’s model shifts from this competitive paradigm to a collaborative "solver-collab infra," where solvers work in synergy rather than isolation.
   
   This Khalani way allows solvers to specialize in specific tasks—such as pricing, liquidity provision, or execution—while combining their strengths to fulfill complex user intents across various use cases, including swaps, lending, and bridging.

In Khalani’s collaborative model, solvers can pool resources, like in staking pools, enabling smaller participants to contribute without needing to independently handle every aspect of the transaction.

Let’s understand with an example:

• Users want to bridge their assets for a unique, multi-chain staking operation involving staked ETH on Ethereum and receiving stETH on another Layer 2 like Optimism.
• Solver A receives this intent and initiates the transaction but doesn’t have the required liquidity on Optimism.
• Instead of failing or incurring additional costs by sourcing liquidity independently, Solver A can reach out to Khalani's collaborative network, where Solver B, a liquidity-rich agent on Optimism, agrees to front the required stETH.
• Solver A and Solver B work together seamlessly: Solver B provides the stETH to the user on Optimism immediately, while Solver A secures the original staked ETH from the user on Ethereum.
• After the user's request is fulfilled, Khalani’s platform manages the post-settlement process, ensuring that Solver B receives compensation from Solver A.

This collaborative process demonstrates how multiple solvers, each specializing in different assets and chains, can pool their strengths to execute more complex, cross-chain staking intents.

The benefits of this cooperative structure are significant such as increased decentralization, reduced monopolization, and enhanced resilience against MEV risks.

4. Proof Of Fulfillment

So far, we have mostly covered user-specific components.

Bob expressed his bridging intent > solver was selected after competition > solver fronted the require tokens to BOB > Bob happy.

Now, it's time to get to the solver-specific components of this system.

What is Proof of Fulfillment?

After successfully filling the intent on the destination chain, the solver needs to provide some proof to the source chain to prove that the intent was accurately filled.

This is crucial because the solvers have risked finality and used their liquidity to fill Bob's intent. However, without proof of their work, the system cannot settle ( reimburse) the solver.

So, how can Chain B talk to Chain about some imperative action that happened on Chain B? - the classic interoperability problem.

There are a few ways to solve this. Some Trust-Based, some Trustless.

1. Cross Chain Messaging ( General Message Passing )
   The most widely used option is to leverage general message-passing systems.
   message-passing
   Once an intent is filled, the solver can initiate a cross-chain message to the source contract.
   
   This is already used in systems like UniswapX, DLN, etc.
   
   Let's understand this with an example of how the DLN bridge achieves this:

• Solver fulfills the user’s intent on the destination chain with their own money by calling DlnDestination.fulfillOrder() function.
• The DlnDestination contract calculates the order ID (hash) from the provided structure and checks it against the order ID to confirm it hasn't been fulfilled or canceled yet. It then sends the solver's funds to the user, marking the order as 'fulfilled.'
• The first solver to fulfill an order gets to call DlnDestination.sendUnlock() function. This is where the cross-chain messaging part starts.
• sendUnlock()sends a cross-chain message via deBridge to the DlnSource smart contract. This message instructs the DlnSource ( on the source chain ) to unlock the funds initially held for that order and send them to the solver's address.
• The DlnSource checks the message sender's identity (address, chain ID, etc) before executing the unlock command. If all checks pass, the funds are unlocked and solvers are settled - a.k.a, solver happy.

Note: The DLN bridge uses their own messaging infra for this cross chain message passing.

2. Oracle-based Systems:
   Another option is to rely on oracles.
   
   Oracles are used to provide data about states or events of chain A to chain B. Based on this information, chain B can take appropriate actions, such as releasing the solver's funds.
   
   A good example of this is how Across leverages UMA’s optimistic oracle to verify the repayment records for solvers. Once these records ( bundles, in Across’ language ) are verified optimistically - the solvers are repaid immediately on their preferred chains. We will dive deep into this in the next section.

So far, what we have been exploring are trust-based systems. Let’s explore some trustless proof systems.

3. Storage Proofs ( herodotus)
   One of the most promising trustless proof mechanisms that can be used for verifying cross-chain information is Storage Proof.
   
   Storage proofs can simply be understood as a proof system that leverages the cryptographic properties of chains themselves to securely access and validate on-chain data from any given point in the chain’s history ( or even from other chains).
   
   The most important part here is unlike trust-based systems like oracles, they don’t require any third party to validate any proof or data. Hence trustless.
4. Light Clients
   Another trustless solution is to enable a proof system with the help of Light Clients.
   
   These blockchain clients do not store the entire blockchain but instead maintain a minimal amount of data necessary to verify transactions. They rely on full nodes for the complete blockchain data but can independently verify the validity of transactions and blocks using cryptographic proofs.
   
   For instance, in the context of proving an action from Chain A to Chain B, a light client on Chain B can validate that a specific transaction occurred on Chain A by checking the relevant block headers and Merkle proofs. This allows the light client to confirm that the action was indeed recorded on Chain A without needing to download the entire blockchain.
   
   A battle-tested example of this can be seen in the Cosmos ecosystem, where light clients are at the core center of the IBC Transport layer. Cosmos employs light clients to facilitate interoperability between its various zones, enabling them to securely communicate and validate transactions across different chains while maintaining a lightweight and efficient architecture.
5. ZK-Proofs:
   ZK proofs can be used as a proof system for this component as well.
   
   Zero-knowledge proofs are cryptographic methods that allow one party to prove to another that a statement is true without revealing any specific information about the statement itself.
   
   In the context of proving actions from Chain A to Chain B, ZK Proofs enable solvers to demonstrate that a transaction or action occurred on Chain A without disclosing the details of that transaction.
   
   For example, a solver could generate a ZK Proof that confirms they fulfilled a specific intent on Chain A, which can then be verified by Chain B. This ensures that the action is valid while keeping sensitive information private and enabling a trustless proof system.
   
   The hurdles with ZKs, however, are cost and speed. Generating proofs is quite time-consuming and it's also not cost-effective as compared to other approaches. Given the critical importance of efficiency and cost-effectiveness in intent-solver systems, the widespread adoption of ZKs in this component of intent-solver systems is yet to be realized.

5. Solver Settlement

This is the final and crucial component.

This is where solvers are reimbursed/settled for all the liquidity they fronted to execute the user's intents ( Bob's 100 X token bridging, for example ).

Imagine this component as the closing act of a theater performance.

The audience (users, BOB) has already enjoyed the show already and left satisfied, while behind the curtains, the performers (solvers) are now collecting their well-deserved applause and payment for their roles in making the performance a success.

It's important for any Intent-Solver system to design this component conscientiously so that it can ensure the following:

• Reliable Settlement: This component should be able to retain the solver’s trust. A solver must be paid accurately and deterministically with as minimal friction or delays as possible.
• Fast & Efficient Settlement: Quick settlement is essential for solvers to maintain liquidity, enabling them to fulfill more intents.
  
  The faster a solver is settled, the more liquidity in the solver’s inventories, and the better the execution price of intents. Conversely, slow and inefficient settlements can drain liquidity, leading to system inefficiencies and potentially unfavorable prices for users.
• Fair & Secure Settlement: Fairness and security must be upheld at all times for both users and solvers.
  This means solvers must always be settled for exactly the intents they filled. Moreover, a solver must not be able to claim or game the system to get more than what they deserve from the protocol. In such scenarios, adequate mechanisms like slashing, banning, etc, should be in place to punish bad actors accordingly.

Let’s quickly dive into some settlement mechanisms that exist today:

1. Cross Chain Messages & Smart-Contract-Based Settlements:
   A widely used approach ( in intent-based bridges and traditional bridges ) is cross-chain messages.
   
   As previously explained in the Proof of Fulfilment component, some systems use cross-chain messages to update Chain B about the actions on Chain A.
   
   Now, in terms of settlement, Chain A ( the source chain ) can have a smart contract that receives these messages ( from Chain B) and performs settlement logic for the solvers, provided that all imperative conditions are fulfilled.
   
   There are a few examples of this approach, such as:
   1. UniswapX’s Reactor contract to verify and transfer funds from relayers to users based on specific conditions set by the protocol
   2. DLN Bridge also uses cross-chain and smart contracts to settle their solvers. ( as explained in the Proof of Fulfillment section above)
   3. CowSwap uses its GPv2Settlement contract to handle settlement for users/solvers.
2. Optimistic Settlement via Oracles
   Optimistic settlement is one of the most cost-effective and battle-tested approaches for settlement.
   
   The core idea behind optimistic settlement is to assume that transactions ( intent fulfillment) are valid by default unless someone challenges their accuracy. This significantly reduces the time and resources needed for verification.
   
   Due to this optimistic approach, this mechanism doesn't require proofs via cross-chain messages for every fulfilled intent, which saves tons of gas costs.
   
   Instead, it is assumed that this list of filled intent transaction bundles is correct ( hence optimistic ) unless someone challenges it in the challenge period.
   1. If a dispute occurs, the bundle is rejected.
   2. If no one challenges the bundle, it's posted on-chain, which eventually repays all solvers in that bundle.

There are protocols like Across and Mach that use optimistic settlement in their systems.

Let's take an example of how Across protocol uses UMA's optimistic oracle for settlements:

• Considering the first 3 phases are already done, let's explore the next steps through the lens of Across protocol.
• The Bundle: All the intents filled by solvers are periodically grouped and form a bundle. This bundle becomes a Merkle root object where each leaf contains specific details like which solver should get settled, the settlement amount, the preferred chain for settlement, etc. The root of this tree is then proposed on the HubPool contract of Across protocol.
• The DataWorkers are actors the protocol has whose job is to periodically aggregate all filled events ( events triggered when a solver fills a user’s intent) and create a bundle.
• The Bond: It should be noted that every new root proposed by DataWorkers requires them to also post a bond ( money ) along with it. This is to ensure DataWorkers behave adequately. If they don’t, they get slashed, and their bond is forfeited.
• The Challenge Period: Once the root is proposed on the HubPool contract, the challenge period begins. Any challenger can raise a dispute to verify the correctness of the Merkle root if they believe it's invalid. If the challenger is right, the DataWorkers is slashed for proposing an invalid root, and the challenger is rewarded.
• The Final Settlement: Once the challenge period is passed successfully, it is optimistically verified that the root is accurate. The proposer can then simply call the executeRootBundle() function, which uses the canonical bridges of respective chains and distributes the funds back to the solvers.

Optimistic Settlement excels in two key areas:

• Cost: It's cheaper to verify and settle solvers optimistically, as it avoids costly cross-chain messages for each intent, benefiting both solvers and users with better pricing.
• Security: Optimistic settlement is more secure than externally verified bridges due to its reliance on a single honest verifier. This model requires only one watcher to report fraud, making attacks economically unfeasible. The permissionless and anonymous nature of watchers further reduces the likelihood of successful fraud, ensuring a negative expected value for any fraudulent attempts.

This article explores the security aspect quite extensively, check it out.

3. Settlement via Everclear:
   Everclear is another infra project that sits precisely at the solver-settlement component of any intent-solver system - and it solves a crucial problem.
   
   One key challenge in intent-based systems is the complexity and cost of rebalancing funds after solvers are reimbursed for fulfilling orders.
   
   Traditionally, solvers have relied on CEXs and bridges for this process, which can be inefficient and expensive.
   
   Everclear addresses this by allowing most of the rebalancing activities ( approx 80% ) to be netted against one another, leading to a potential tenfold reduction in costs.
   
   The key word here is - NETTING.
   
   Netting is a financial process where multiple transactions between parties are consolidated to determine a single net amount owed. Instead of settling each transaction individually, parties offset their obligations against each other, resulting in a simplified payment process.
   
   Here is a dumbed-down example to understand better:
   
   Imagine two companies, Company A and B, that frequently trade with each other. Over a week, Company A owes Company B $1,000 for goods purchased, while Company B owes Company A $600 for services rendered.
   
   Instead of each company making separate payments, they can net their transactions:
   1. Company A owes Company B: $1,000
   2. Company B owes Company A: $600
   3. Net Amount: Company A pays Company B: $1,000 - $600 = $400

In this case, Company A only needs to pay $400 to settle their accounts, simplifying the transaction process and reducing the number of payments made, thus improving efficiency and reducing transaction costs.

Now, the crux of Everclear is the fact that it allows solvers, or fillers, to socialize the costs of rebalancing by netting settlements against each other, significantly reducing the financial burden associated with moving funds across chains.

Additionally, this protocol acts as a programmable layer, enabling users to implement various mechanisms for rebalancing and settling funds, whether through messaging systems, liquidity pools, or centralized exchanges (CEXs).

In a nutshell, Everclear makes settlement and rebalancing quite efficient for solvers. With netting, Everclear minimizes the number of transactions needed to settle and rebalance, thus significantly enhancing the efficiency of intent-solver systems.

Read this to understand the complete flow of Everclear's settlement process

Finally, Let's Wrap

That's a wrap, Decipherers.

With this two-part article on intent-solver systems, you now have the mental models to understand:

• why these systems are important, and
• How these systems work behind the scenes.

I believe these systems will play a major role in enhancing the UX for Web3 applications and helping expand the boundaries of Web3.

With Intent-Solver systems, we are headed towards Chain-Abstracted Web3, which is the need of the hour.

Cheers 🍷

For Further Readings

1. Introducing the CAKE framework
2. Why Intents are the Answer to Interoperability
3. How Nomial Works with Intent-Based Bridging
4. With Intents, its Solvers all the way down by LiFi
5. The Order Flow Auction Design by Fronteir Research
6. An Introduction to Intents and Intent-centric Architectures
7. Introducing Khalani: The Decentralized Solver Infrastructure
8. Everclear: The Endgame for Optimizing Cross-Chain Liquidity