Team Intents and Team Messages: Let's end the Debate

Team Intents and Team Messages: Let's end the Debate

I wrote an X post that gained amazing traction and great insights.

So much so, that I felt compelled to write this article.

The post has a high signal-to-noise ratio; it was a discussion fueled by honest opinions & insights from some of the best minds in the web3 interoperability space.

That conversation inspired me to dive deeper and pen this detailed article, ensuring no valuable insights are left out.

TLDR: It's about the classic debate between

Team Intents and Team Messaging

I will primarily try to understand the following 4 points:

  1. What are Intent-based bridges?
  2. What are Message-based bridges?
  3. Do they ever intersect?
  4. Do they even need to intersect?
đź“ť
Note: It is imperative to understand that both these systems have the same goal, i.e., enabling seamless, better, faster, and reliable interoperability of assets/messages between chains.

The difference lies in their approach to achieving this goal.

Let’s dive right in.


Message-Based Interoperability

This traditional bridging uses lock-and-mint or liquidity pools to enable asset movement between chains.

With the lock-and-mint model:

  • User’s assets are first “locked” in a smart contract on the source blockchain and a corresponding “wrapped” token, representing the locked asset, is then “minted” on the destination chain.
  • If the user wishes to redeem their original asset, the wrapped token is “burned,” the initial token is released back to them on the original blockchain.

With Liquidity Pool Model:

  • Here, the bridge maintains pools of assets on both blockchains, provided by liquidity providers who earn fees from transfers.
  • 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. This model eliminates the need for wrapping and minting but relies heavily on liquidity.

A typical traditional interoperability system relies on the following main 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 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.

The Good and The Bad

The Good: The good part of these message-based interop systems is that they are reliable and preferred for larger transactions.
The Bad: However, they fail at providing better/seamless UX as they are bound by the finality of the chains they connect.

I wrote detailed post on what’s wrong with traditional interoperability systems here, check it out.

Intent-Based Interoperability

On the other hand, intent-based bridging is a new mechanism of moving assets/msgs between chains which is way faster and more convenient for users.

They leverage specialized on-chain actors( solvers ) who use their liquidity to compete and execute users’ ( bridging ) intents and are reimbursed by the system later.

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

Intent-based bridge models can overcome some trade-offs of traditional bridges like finality risks, avoiding/minimizing honeypots as they don’t rely on large liquidity pools for bridging, enhanced UX for users, etc.

The Good and The Bad

The Good: Intent-Solver systems provide significantly better bridging speed and delivery times, a.k.a, better UX.

The Bad: While they are fast, such systems currently lack healthy solver competition and face difficulty supporting larger transactions and expanding to many chains.

The Great Debate

At its core, the debate is around the following statement:

Intent-based systems are stand-alone and better bridging mechanism than message-based systems.

They can operate without ever relying on traditional message-based bridges.

The statement sounds true ( and convincing ) at first glance.

However, it misses a critical point, i.e., these two systems do intersect and complement each other.

đź’ˇ
For instance, those who agree with the above-mentioned statement, often overlook how many Intent-Solver systems today use messaging protocols within their systems.

For instance, Everclear, deBridgeFinance.

The important question, however, is:

  1. Where do these systems intersect?
  2. And how do they complement each other?

Intersection of Intent and Messages

There are two main points of intersection where Intent-Solver systems rely on message-based interop systems:

1. Proof of Fulfillment & Settlement

2. Rebalancing of Solvers

Note: Read about the 5 important components of Intent-Solver Systems to get a better understanding of what we discuss next.

Let’s understand each one of them:

1.Proof of Fulfillment & Settlement

In a typical intent-based bridging flow:

  • The user creates an intent
  • Solver competes to fulfill the intent
  • The winner-solver gets to fill the user’s intent using its liquidity.
  • The system then later reimburses the solver for all the liquidity they used to fill the user’s intent.

Now, after successfully execution of the intent on the destination chain, the solver needs to provide some proof to the source chain to indicate that the intent was accurately filled on the destination chain.

This step is critical because solvers take on finality risks and use their liquidity to fulfill user intents. Without validated proof of their work, the system cannot settle or reimburse the solver.

Therefore, only after a successful validation of this proof, the solver can receive their locked funds.

To provide this proof, the solver needs to transfer it from Chain B (the destination chain) to Chain A (the source chain).

This is exactly where message bridging comes into play.

Message-based systems can be utilized to securely and efficiently transmit these proofs between chains, enabling seamless settlement and maintaining the integrity of the intent-based system.

2. Solver Rebalancing

Another point of intersection, as mentioned in this article by Paul, rightly mentioned is for Solver Rebalancing.

What is Solver Rebalancing?

Solvers use their liquidity to fill user’s intents quickly.

This means they must have access to an adequate amount of liquidity ( their inventory ) on the chains they choose to support.

A major task for solvers is adequately rebalancing their inventories on multiple chains. This ensures that the solver can quickly fill the carefully evaluateuser’s intent on any supported chain.

the faster the rebalance, the easier the access to liquidity, the better efficiency in filling intents, and the better price(UX) for users.

Yet another point of intersection where message bridges can be used by the solvers to quickly fill large volumes without being constrained by liquidity limitations.

This approach is quite useful for serving newer long-tail chains where user and liquidity are scarce.

Are These Intersections Needed?

Intent-based systems and Message-based systems definitely complement each other and intersect with each other. But is this intersection really needed?

To understand this, we need to carefully evaluate the two intersection points mentioned above:

1.For Proof of Fulfilment and Settlement Phase:

It's important to note that at its core, this phase requires some sort of proof system to prove to Chain B that an action on Chain A occurred.

Now, cross-chain messaging is one of the many ways to move these proofs between chains and can be used in this phase. However, as I covered in my previous article, there are other systems like @UMAprotocol 's Optimistic Proof system, @HerodotusDev 's Storage proofs, Light clients, ZK proofs, etc, that can be used for proving actions between chains as well.

In @AcrossProtocol, for instance, this phase doesn’t rely on messaging protocol but uses optimistic proofs to verify the solver’s filled intents. And can reduce a lot of gas consumption due to this design choice.

Here is a part from Across’s docs on how using an optimistic proof mechanism helps them save gas:

Across Settlement system aggregates valid fills events off-chain to create a repayment bundle, which is then optimistically verified by UMA's Optimistic Oracle. This verification and repayment mechanism scales gas cost of repayment at O(1) instead of O(N) with the number of fills. This offers an order of magnitude in gas savings vs. other approaches and ultimately leads to better pricing for users and more profit for relayers.

Therefore, the intersection of message-based interop systems with intent-based systems for proof of fulfillment of intents is not a compulsion.

However, I must state that while messaging is not mandatory for this part, it is often the most cost-efficient and widely used method. Alternatives may require more sophisticated on-chain infrastructure and incur higher latency or gas costs.

2.For Solver Rebalancing

When it comes to rebalancing solvers, the intersection of these two systems can prove to be quite imperative.

Solver rebalancing is a critical component of intent-based systems, as solvers rely on liquidity distributed across multiple chains to fulfill user intents effectively. The efficiency of solvers in rebalancing their liquidity has a direct impact on the user experience, pricing, and overall reliability of the system.

There are a few good reasons why message-based systems are significant for this part:

  1. Efficient Liquidity Movement Across Chains:

Solvers must regularly rebalance their liquidity across multiple supported chains to maintain their ability to fill user intents quickly. Messaging systems provide a reliable and scalable way to transfer liquidity between chains, minimizing downtime and maintaining solver efficiency.

  1. Flexibility in Supported Chains:

Messaging bridges excel in this scenario by providing a consistent mechanism to move liquidity, regardless of the specific chain architecture.

  1. High Volume Throughput:

Solvers often handle large liquidity transfers during rebalancing. Messaging systems are designed for high throughput, making them ideal for such operations. For instance, native rollup bridges can handle rollup-to-Ethereum liquidity transfers, but they are inherently message-based systems, reinforcing the reliance on messaging for rebalancing.

Here is an insight from Mike on the same:

Unlike the proof of fulfillment phase, where the use of message-based systems could be optional, solver rebalancing currently cannot operate without messaging systems.

Whether these systems are general-purpose bridges or native rollup bridges, they are the backbone of efficient liquidity rebalancing in intent-based systems.


Best Insights on the Intent vs Messaging Debate:

I have attached some of the best insights I received on this tweet for better clarity on this debate:

  1. Symbiosis Between Intents and Messaging Systems - by Arjun

Intents and messaging systems are not adversaries but symbiotic, solving each other’s challenges. Messaging unlocks funds in intent systems while batching via intents reduces costs in messaging systems.

The key to minimizing rebalancing costs is clearing/netting, as advocated by Everclear.

  1. Bridges: Infrastructure vs Application Layers - By Kevin Wang

Bridges can be divided into infrastructure (e.g., IBC, LayerZero) and application layers (e.g., Stargate, Across). Intent systems rely on proof-pulling and off-chain economics, while message systems depend on proof-pushing and on-chain economics. The need for third-party messaging depends on the native infrastructure of the connected chains.

  1. Messages as APIs for Proof Systems - By Nam

Messages are not proofs but APIs for delivering proofs. Rollup bridges function as specialized message bridges, proving that intents inherently require messaging. Whether via ZK proofs or optimistic mechanisms, messages act as the interface to validate and unlock remote chain states.

  1. Team Message + Intents - By Mike

Messaging and intent-based systems complement each other by catering to different user needs. Messaging bridges help solvers rebalance and serve as transport providers for proof settlement, while intent systems focus on speed and user-centric solutions.

  1. Interesting Open Questions - By Manank

Intent systems may not need to build their own proof systems, as messaging systems offer reliable, secure alternatives. As intents grow in adoption, solvers will likely use any infrastructure available, prioritizing reliability over-optimization for niche chains or assets. Pluggable security models, like those in Socket, offer flexibility to adapt to specific use cases.

Wrapping it up

Through the discussions and insights shared above, it’s clear that while intent-based systems introduce imperative advancements in UX and speed, they cannot entirely operate in isolation from message-based systems.

Intent-based bridges excel in speed, simplicity, and user-centric design. Yet, they face challenges in areas such as solver rebalancing, proof-of-fulfillment, and scalability across multiple chains—challenges that messaging systems can address effectively.

On the other hand, message-based systems are reliable, especially for large transactions. While these systems excel at solving infrastructure-level problems, they lack the UX fluidity that intent-based systems bring to the table.

Through this lens, we see that these systems are not competitors but collaborators.

  1. The existing messaging interop systems can be seen as the infra layer - IBC, LayerZero, Hyperlane, etc.
  2. The intent-based systems can be seen as the application layer that utilizes the messaging infra for imperative operations - Across, Stargate, etc.

The future of cross-chain systems lies not in choosing between intents and messages but in harnessing the strengths of both Team Message and Team Intents.


That's it, for now, Decipherers.

Cheers 🍾

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

Join Decipher Club today

Simplifying Web3 and Technology for everyone

Subscribe Now