Why Intent-Solver System Works? - Part 1

Table of contents:

1. Brief glance at the Past

2. So, what's wrong with Traditional Interoperability Systems?
2.a Finality Risks
2.b The Faliure of UX
2.c The Curse of Liquidity Pools
2.d Excessive Trust Assumptions

3. Intent in 100 words
4. Solvers in 100 words
5. Intent-Solver-based systems
6. Do these Intent-Solver Systems solve Traditional Interop Problems?

A major shift in Web3 interoperability is around the corner.

We are witnessing a massive change in how value is transferred between chains.

The shift has already begun, but this is only the beginning.

I have used and studied both interop models as a user and a researcher/developer—adequately enough to write a two-part article on them.

The new intent-solver-based system is far better, faster, cheaper, and perhaps more secure.

In this article, I present my arguments for why intent-based interoperability systems could potentially surpass traditional bridging models. And then, I will explain these systems and their significance as simply as possible.

But first, let me throw in some solid numbers to strengthen my argument:

1. Here is a snapshot of the total value filled/bridged by intent-solver systems in the last 90 days - a whopping 4.1 billion USD.
   

2. Across Protocol, one of the top intent-solver-based interop systems currently, has the following transfer count.👇

• Time comparison of a typical bridge transfer between Across ( intent-solver system) vs other traditional bridges. Take a good look at the chart and see who is winning.

Now, let's dive in and understand Why Intent-Solver Systems for Interop work better.

Brief Glance at the Past

Feel free to skip this section if you are an interop nerd and know it all.

We will explore the traditional interop model quickly to see what’s wrong with it.

A typical blockchain bridge enables asset and data transfers across disparate blockchains.

They have 2 main models:

1. Lock-and-Mint Model:
   1. In this model, a user’s assets are first “locked” in a smart contract on the source blockchain.
   2. A corresponding “wrapped” token, representing the locked asset, is then “minted” on the destination chain.
   3. If the user wishes to redeem their original asset, the wrapped token is “burned,” and the initial token is released back to them on the original blockchain.
2. Liquidity Pool Model:
   1. Here, the bridge maintains pools of assets on both blockchains, provided by liquidity providers who earn fees from transfers.
   2. Users who want to transfer an asset trade it in one chain’s pool and receive an equivalent amount from the pool on the destination chain.
   3. This model eliminates the need for wrapping and minting but relies heavily on liquidity.

Additionally, a traditional interop system typically relies on the following components:

• Smart Contracts act as the gateway for interop on any chain and help automatically handle complex logic, such as minting, burning, locking, or releasing user funds.
• Validators or relayers verify and transmit messages across chains, ensuring that the transaction is recognized and completed on both sides. They provide critical consensus to prevent double-spending or fraudulent transactions, although by introducing trust assumptions.
• Oracles play a vital role by collecting and validating off-chain data and ensuring that state changes (like locked assets) are reliably reported across chains.

So, what’s wrong with Traditional Interoperability Systems?

Traditional interoperability protocols (bridges) face several technical challenges, each impacting their security, reliability, scalability, or overall UX.

Below are just a few of those issues:

1. Finality Risks

Finality in any blockchain is the point after which transactions or blocks are considered irreversible and unchangeable.

When you send 10 DAI from wallet A to B on Ethereum, the transaction might appear to be “confirmed” within seconds, but it isn't final yet.

In other words, the transaction could still theoretically be retracted or reorganized due to events like network latency, forks, reorgs, exploits, etc.

Ethereum's typical transaction reaches finality after approximately 12-13 minutes or 2 epochs (each epoch has 32 slots, and each slot takes 12 seconds - do the math, anon ). Thus, after two epochs, the transaction becomes fully immutable.

Now, think about cross-chain value transfer for a moment.

In a cross-chain operation, state changes must occur on both chains and be coordinated accurately.

The source chain could say a state X is valid and the destination chain believes it and performs an action Y -

but what if the X is retracted later. Its possible because X was valid but not final .

This finality risk is greater in cross-chain operations as transactions between chains depend on the finality of more than one chain. Each blockchain operates on unique consensus rules and may reach finality at different speeds, affecting the dependability of cross-chain actions.

In bridging, if a transaction on Chain A is considered "final," but Chain B takes additional time to confirm, this discrepancy can create a vulnerability window. In worst-case scenarios, this could even lead to double-spending concerns.

Additionally, relying on the varying finality of different chains increases the delay in the overall cross-chain action — which is slower, riskier, and overall bad UX.

When bridging with traditional interop systems, users bear all of the finality risks and delays in the entire bridging process due to finality confirmation between chains.

2. Failure of UX

Let’s talk about UX now.

With a traditional interop solution:

• users select a bridge,
• construct the payload (message/action) that they wish to relay,
• provide the destination chain ID for the payload
• manages & provides gas tokens on the source chain
• switches between chains
• achieves the desired outcome on the destination chain
• and, all while taking the finality risks

The user must perform to achieve their desired outcome. All of them ( some aren't even mentioned above).

While interoperability solutions resolve chain interactions, the overall UX remains complex.

Why?

Well, because there is no abstraction in Interop Solutions. 

A typical bridge doesn't necessarily abstract away the on-chain complications for a user. Users are still required to learn, understand, and navigate multiple chains and perform on-chain tasks themselves to achieve simple desired outcomes/states.

In the process, they might even expose themselves to many security risks that can lead to unwanted losses —and they have.

3. The Curse of Liquidity Pools

Most traditional bridges use liquidity pools to facilitate asset transfers between chains, but these pools come with substantial risks.

The core issue is the requirement for large amounts of capital to be locked in liquidity pools to ensure sufficient liquidity for cross-chain transactions.

This locked capital creates a substantial honeypot that attracts malicious actors, increasing the risk of exploits and financial losses. The pooled funds in smart contracts have historically led to significant bridge hacks.

Another concern is that liquidity pools inherently suffer from capital inefficiency. They require liquidity providers to lock assets for extended periods, which becomes unsustainable when yields drop below market expectations.

Furthermore, to attract and retain liquidity providers, these liquidity pools are bound to offer high incentives, which technically is unsustainable in the long term. As yields diminish, the attractiveness of these pools decreases, leading to a potential liquidity drain.

4. Excessive Trust Assumptions:

A typical interop solution facilitates value or data transfers between chains using validators or relayers to verify transactions.

This process, however, introduces multiple points of potential security failures, such as breaches of centralized validators or relayers, inadequate multi-sig schemes, heavy reliance on complex and unsecure smart contracts, unsafe external calls, etc.

Moreover, most lock-and-mint models of traditional bridges heavily rely on centralized custodians to manage the locked assets, which demands a certain level of trust. These vulnerabilities have led to significant security incidents, resulting in substantial financial losses, as we have seen in the past.

So far, I have argued about why I am not a fan of the traditional interop/bridging model.

Let me now explain why Intent-Solver Systems for Interoperability is the way forward.

To begin with, let's break it down and understand each of them in the simplest way possible - Intents, Solvers, and then the System.

Intents in 100 words

Intents are a user’s on-chain wants.

Any action that any user wants to perform on-chain is basically an intent.

It's important to note that intent only indicates what a user desires to achieve on-chain without extensively including any details of how or where to achieve it.

If there is an action X that you need to execute on-chain, X is your intent. As simple as that.

However, the efficiency of execution and the underlying details of the on-chain execution, the chain on which the intent is executed, are not required to be included in the user's intent. That’s where solvers come in.

Solvers in 100 words

Solvers are specialized on-chain actors responsible for fulfilling a user’s intent.

These actors decide on efficient on-chain routes and handle all on-chain complexities and risks required to execute the user's intent and achieve the desired output state.

Ideally, the more efficient, faster, and reliable a solver is, the more likely it is for the solver to execute more intents.

Solvers are imperative in this system because they provide better results to users, abstract away most of the on-chain complexities, and significantly enhance the UX of decentralized applications.

Solvers lead to a chain-abstracted future.

Intent-Solver-based systems

Intent-solver systems are designed to interpret a user’s on-chain intent and select a solver who can fulfill the intent faster, cheaper, and more efficiently.

These systems can be designed for a wide range of applications.

Different solvers ( or solver groups ) can have different types of expertise, and an application can leverage the solver network based on its needs.

For instance:

• Intent-solver-based bridges might require solvers to help fronting liquidity between chains for users, enable instant bridging, take financial risks, etc.
• Lending-borrowing protocols built with intent-based design might require solvers to help resolve bad debt by liquidating such positions.
• Cross-chain swapping apps will require solvers to provide efficient solutions and optimal on-chain routes for swap-specific intents.

In order to understand these systems, let's take the bridging example with intent-solver-based design:

Let's say Bob wants to bridge 100 token X from Ethereum to Polygon.

• Bob expresses an intent, i.e., an on-chain action they wish to take.
• In addition to expressing his intent, Bob authorizes the system to use the 100 X tokens from his wallet.

In most systems, this 100 X token is locked in the system's escrow contract on the source chain (the Eth chain in this case ).

Note: Bob can either lock this 100 x token himself, or just sign a transaction for solvers to perform the on-chain operation.

• The system initiates its solver-competition process. This competition is to pick the best solver for the given intent. The one who can provide faster results, better pricing, etc.
• Solvers compete to win the right to execute the user's intent.

A good solver competition indicates better pricing and UX for users. The more the competition, the better experience for users.

• The winning solver then uses their liquidity on the destination chain to send the required funds (1oo X tokens ) to the user on Polygon in just a few seconds. This means the user no longer waits for the two chains to achieve finality. Instead, finality risk is now delegated to solvers as solvers front the liquidity for the user without waiting for finality.
• Users receive the funds instantly without dealing with any on-chain intricacies or finality risks - a.k.a users happy. But solvers aren't happy yet.
• Now, the solvers must provide proof to the system indicating they accurately executed the user's intent on the destination chain. This is important because the system cannot release the user's locked funds to the solvers without valid proof.
• Once solvers have provided the required proof and the system successfully verifies it, the user's locked funds on the source chain ( in step 2 ) are released to the solvers, i.e., the solvers are settled for their valid executions—a.k.a. solvers now happy.

There you go.

You just got a brief glimpse at how an intent-based interoperability system works. If necessary, check the diagram again.

Now, in case you are curious about:

1. What happens if solvers cheat?
2. How does solver settlement happen?
3. Can users express any kind of intent?
4. What happens if there is no solver competition?
5. Can solvers interpret any intent from any app?
6. What are the different ways of solver selection?
7. How can solver prove their valid execution to the system?
8. How does solver get liquidity to front the funds for users ?

Congratulations, you have the right set of questions in mind.

And I have answered all of it extensively in the Part 2 of this article. coming up soon.

Do these Intent-Solver Systems solve the Traditional Interop Problems?

Now, let's revisit the previously discussed issues of traditional bridging to check if intent-based-interop systems resolve them.

Finality Risks:

In these systems, the solvers front the liquidity on the destination chain for the users. This means users no longer wait for chains to reach their finality. Instead, the solvers take the finality risk away from the user.

Solvers handle all the intricacies and risks of dealing with on-chain complexity throughout the bridging process. They use their own funds to bridge the assets ( which will later be settled by the protocol after verifications ), manage their inventory on different chains, handle the risks, and deliver faster and more efficient results.

Users receive their funds instantly without waiting for confirmations across chains. This interop mechanism improves UX and eliminates latency issues for traditional interop solutions.

I will again post the time comparison chart between Across and other bridges to validate this.

What about Liquidity Pool Risks?

Unlike liquidity pool-based models, intent-solver systems don’t rely on large pools of locked funds. This minimizes the “honeypot” problem and capital inefficiency.

Instead, solvers provide liquidity per transaction, which is dynamically allocated rather than pre-deposited, reducing security risks.

The solver can use its own funds to execute intent orders and earn fees.
There are a few common sources of liquidity available for solvers to 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

Apart from this, there are other innovative solutions for solvers to access liquidity and fulfill intents, such as:

• The Open Liquidity Network by Nominal
• Solver Collaborative framework by the Khalani Team
• Or, the netting mechanism proposed by the Everclear team

I have explained these in detail in Part 2 of the article. coming up next.

The imperative part to remember is how intent-based interop eliminates the large attack surface as it doesn't require a liquidity pool. Instead, it limits the risk to individual transactions as solvers manage their inventories, thus minimizing on-chain interactions and leveraging off-chain liquidity.

This indicates how any potential risk will never affect the entire system.

Excessive Trust Assumptions in Traditional Interop

Intent-solver models distribute verification and settlement processes across multiple competing solvers who stake collateral, reducing the reliance on centralized validators and enhancing security through trust-minimized systems.

This mitigates the traditional bridge risks of validator compromise or multi-sig issues.

It shouldn't be overlooked that even intent-based bridging systems can trust assumptions when they rely on general message passing infra or an oracle pipeline to verify the action of one chain on another. However, there are ways to mitigate this by using trustless proof systems like storage proofs or optimistic settlements.

Nevertheless, the intent-solver system minimizes trust assumptions compared to traditional interop protocols.

Finally, what about UX?

If we carefully observe the workflow of intent-based bridging, we see that it removes all the redundant on-chain complexities and risks for users.

Moving assets using an intent-solver system is quite seamless. The user expresses their intent and authorizes the protocol to use their funds for the bridging.

Once done, the specialized on-chain actors ( solvers ) find efficient ways to fulfill the intents, use their liquidity, take the finality risk and any cross-chain messaging risks, and eventually execute the user’s intent as quickly and efficiently as possible.

In other words, the overall UX significantly improves for the end users, who now have a faster, more efficient, and more secure approach to moving funds between chains.

Intent-solver-based interop is one noteworthy way of achieving a Chain Abstracted future, which is imperative for Web3 to expand its boundaries.

Irrespective of what you think, we can all agree that UX matters a lot for users.

An intent-based interoperability mechanism brings us closer to a better, faster, and more secure UX. A trifecta that is an absolute necessity for Web3 apps.

To Be Continued...

I have presented a compelling argument to you all.

I have explained why I think these systems have enormous potential.

However, I won't leave you with just that.

In the next part of this article, I will explain and dive deep into how the intent-solver systems work and some mental models around such systems.

See you there, Decipherers.

Cheers.