Introducing the Intent Fusion Protocol: A Universal Intent Expression & Execution Protocol Based on Abstract Data Exchange

Introducing the Intent Fusion Protocol: A Universal Intent Expression & Execution Protocol Based on Abstract Data Exchange

Table of Contents:

These are exciting times for us at Particle Network.

Today, we are introducing a core pillar of our upcoming tech stack: The Intent Fusion Protocol.

The Intent Fusion Protocol is a permissionless universal framework for expressing, transforming, and executing intents. It can enable the creation of intent- and user-centric products, integrating a DSL (Domain Specific Language) to radically simplify the dApp development experience. Within this framework, developers can use the Intent Fusion Protocol’s DSL to express user intents through data constraints instead of transactions, submitting them to a network of Solvers for on-chain execution.

This article will develop the core concepts behind the Intent Fusion Protocol, explain its role within Particle Network, the user experience it enables, and how Web3, in general, can benefit from a generalized intent-centric approach to on-chain interactions.

Some protocols are already embracing intent-centric design, a paradigm meant to simplify the transaction-centric status quo.

But first, what is intent-centric design?

Intent-centric design is a relatively new term in the Web3 ecosystem and, as such, it has been met with healthy skepticism. There are a few reasons behind this: one of our past blog posts elaborated on the common belief that intent-centric design is merely a repackaging of account abstraction (AA). Other common arguments see intents as a buzz term with no clear meaning, a belief that stems from the term’s ambivalent usage to refer to either an underlying system meeting very specific goals (as happens in DeFi apps like UniswapX, CowSwap, and DEX aggregators) or a general Web3 framework (e.g., Anoma).

The goal of intent-centric design is for users to express their desired outcomes and outsource their execution –or “Solving”–to third parties. Currently, Web3 requires users to manually execute all the necessary (sometimes convoluted) steps to achieve their goals. Intent-centric design addresses this by allowing users not to dictate the "how" to execute an action, but instead simply point out their desired outcome. 

When we talk about intents, we talk about user goals, which necessarily vary across different applications, services, and contexts. For a DeFi app, e.g., Uniswap v2, the user’s goal might be very simple: to exchange a certain amount of TokenA for TokenB at a market rate or a more favorable one. Within this application, the intent and the transactions needed to arrive at it are quite similar. 

However, other apps might have a very simple intent with a complex path. For example, if the user is instead a liquidator within a lending dApp, their end goal is to profit as much as possible. To realize this, they need to identify the most favorable available positions to liquidate given the amount and type of their available tokens, understand the value of the bag they can obtain by liquidating, weigh whether this is favorable to them, and liquidate the position as fast as possible to avoid being front-run by other liquidators.

By removing the burden of self-defining and executing all the necessary steps for users to meet their goals, intent-centric frameworks, combined with Web3’s unique features, can improve Web3 dApps’ user experience and efficiency. Under this framework, third parties (Solvers) are tasked with achieving these outcomes, and individually rewarded each time a user selects their proposed path. 

User experience enhancements and benefits of mature intent-centric systems

It’s important to note that as Web3 grows in diversity and complexity, intent-centric design grows in relevance. Consider the following example:A user of Coinbase, upon learning about the launch of the Base Chain, wishes to experience a gaming application on Base. He knows that he needs to mint an NFT of this game to start the process.

Skipping the wallet registration process (which involves the sensitive step of storing private keys, a problem tackled by WaaS tools) and assuming he has played Web3 games in the Polygon ecosystem and already holds Polygon’s MATIC tokens, to participate in the game, he would have to:

  1. Find a third-party cross-chain bridge to transfer his MATIC tokens to the Ethereum Mainnet.
  2. Use a DEX to exchange his MATIC for native ETH.
  3. Use Base’s bridge to transfer ETH tokens onto the Base chain.
  4. Mint the NFT.
  5. Start playing the game.

The above is just an example of how Web3’s current state results in convoluted processes, imposing excessive friction even upon experienced users –which, of course, multiplies for newcomers. Within an intent-centric system, it’d be possible to introduce options that leverage recent advancements (such as AA) to streamline the swapping, bridging, and spending of the necessary assets to achieve the user’s goal. 

The image below represents the different layers that need to be introduced to establish an intent-centric framework, each serving a specific function –taking users from expressing their intents to their execution. Out of these layers, the most important one, we believe, is the Translation Layer. There is an urgent need for a unified Domain-Specific Language (DSL) framework to emerge, in turn creating a developer ecosystem that researches and develops different solutions in the intent-centric field. To address this need, we are introducing the Intent Fusion Protocol.

Different layers of an intent-centric ecosystem.

Particle Network’s Intent Fusion Protocol 

Thanks to the above examples, we can arrive at the definition of intent, in this context, as “a set of declarative constraints involving signatures that allow users to delegate transaction creation and execution to third parties without relinquishing full control over to them.” Intents do not explicitly specify the computational path to be taken, but allow for any path that satisfies their desired constraints. This allows users to effectively grant the recipient (a Solver) the authority to propose the computational path on their behalf. 

Particle Network’s Intent Fusion Protocol is a permissionless, universal framework for expressing, transforming, and executing intents. We introduce a general data authorization and transfer method capable of expressing data transfers for any smart contract, aggregating data liquidity across both on-chain and off-chain environments. Through a concise DSL, allowing users to specify Input and Output Data constraints, we can eliminate the (currently almost mandatory) trade-off between product complexity and usage simplicity, streamlining interactions with various Web3 protocols and improving overall UX and efficiency.

It’s key to highlight that, computationally, intents are expressed as Input and Output constraints. The logic of execution simply becomes transferring the Input constraints required by the user to the Solver's address and the Output constraints provided by the Solver to the user's address. and. This is ensured through a one-time atomic execution to unify all results.

In short, the Intent Fusion Protocol is composed of a universal intent execution engine using a DSL expressed through data constraints, an Intent Solver network, and an on-chain execution framework.

High-level diagram showcasing the workings of the Intent Fusion Protocol.

Protocol design

Data exchange

Within the Intent Fusion Protocol, data exchange works as follows:

  • At its core, transactions are data exchanges where users enter Input Constraints' data in exchange for Output Constraints' data.
  • The DSL is expressed as concise arrays of Input Constraints and Output Constraints. Developers assist users and Solvers in constructing these arrays, which users confirm and sign.
  • For all smart contracts that involve data transfer, we introduce a transferData interface to facilitate the transfer of data specified in Constraints ('from' to 'to.')
  • For data authorization, smart contracts need to implement an approveData interface. If a user's account is a smart account, they can grant authorization in batches or combine it with protocols like Uniswap's Permit2 for authorization management.
  • The Solver Network needs to respond to the user's Intent, complete a Request For Solver (RFS), and implement an on-chain Executor contract. They encode their strategy and only need to use the executeIntent method.
  • The Reactor contract is responsible for data transfer in Input Constraints and Output Constraints. It also coordinates with the Executor contract.
  • For cross-chain intents, it relies on cross-chain message delivery, and the transfer of the Input depends on the Output transfers already happening on the target chain. Of course, users must first transfer the Input Data to the Reactor contract on the source chain.

Core components

  1. Intent Object: Developers accurately express the user's Intent, including arrays of Input Data constraints and Output Data constraints.
  2. Request For Solver: The Intent Solver monitors the Intent mempool, responds to the user's RFS, and competes with other Solvers to build the Intent Object.
  3. Reactor and Executor: Once the Solver receives the Intent Object containing the user's signature, they call the on-chain Reactor contract, specifying their Executor contract to execute the Intent. The Reactor contract ensures the correct execution of Input and Output Data constraints.
Solving process within the Intent Fusion Protocol.

Execution process

To execute intents, developers can assist users in constructing intents for different specific scenarios. Some examples of this may be:

  • Exchanging USDT in an account for DAI.
  • Exchanging all stablecoins (e.g., USDT, USDC, and TUSD) in an account for DAI.
  • Purchasing a certain NFT using the users’ stablecoins (in this case, this could be expressed as “Status: user balance 20 USDT, 5 USDC; NFT priced at 10 DAI”).
  • Using the assets on Polygon under the user’s account to purchase an NFT on the Base chain.
  • Using the assets under an account to complete an in-game check-in function that requires spending 100 DAI.

Through the Request For Solver (RFS) system, different Solvers compete to provide their solutions, which are essentially Input constraints. Users select the Input constraints they accept, sign the complete Intent Object, and submit it to Solvers for on-chain execution. For instance, in the third scenario mentioned above, a Solver might propose the following solution: “Input: 5 USDT, 5 DAI”. Should the user accept this solution for on-chain execution, the Solver may use their DAI to purchase the NFT and then transfer it to the user. All of this is coordinated using the transferData method to handle Input and Output constraints.

In our protocol design, users and Solvers work together to construct the Intent Object. Users can provide both Input and Output constraints. For example, when trading DAI for USDT, users might choose to specify that they want to spend no more than 100 DAI in exchange for their tokens and receive no less than 99.5 USDT in return.

User's requests are initially processed by the Solver network, so the user does not need to have extensive knowledge of the underlying chains, infrastructure, or be cognitively aware of any of this. The Solver handles this part to construct the specific solution. In the future, a competitive Solver market will undoubtedly emerge. Within this market, users can initiate bids to have multiple Solvers propose different solutions. The optimal solution can be selected through local simulated trading, with incentives provided to the Solver. Particle Network plans to use its native token to incentivize activity in its own Solver auction market.

The following is the execution process of the Intent Fusion Protocol on a single chain:

Single-chain intent solving (click to expand).

Single-chain executions are inherently atomic. However, in the context of multi-chain scenarios, we've expanded the Intent Fusion Protocol to support cross-chain operations. This involves Solvers proving that the necessary Output Data constraints are met on the target chain before they can access the Input Data sent by the user on the source chain. 

Here's the detailed cross-chain execution process:

Cross-chain intent solving (click to expand).

Particle Network proposes a concise and abstracted intent-centric implementation. Within it, different AA solutions are merely a category of instances included within the Solver's scope.

Parting thoughts

Particle Network aims to become the Intent-Centric, Modular Access Layer of Web3. 

We envision an ecosystem in which developers have a straightforward path to leveraging the unique features of Web3 while providing their users with the best possible user experience, focusing 100% of their efforts on creating solutions to problems.

By combining our Modular Smart WaaS and cross-chain solutions with the Intent Fusion Protocol, Particle addresses fundamental issues across every layer of Web3. Through this, we hope to foster the innovation needed to onboard the next billion users to our ecosystem.

If you’re interested in following Particle’s Intent Fusion Protocol development, hit “Subscribe” to receive new articles in your email, or follow us on the social media links below.

Particle Network's Modular Smart Wallet-as-a-Service solutions are 100% free for developers and teams. If you have any inquiries about integrating with us, feel free to book a meeting with one of our agents!

About Particle Network

Particle Network Logo

Particle Network is a Layer-1 blockchain built with the Cosmos SDK, equipped with a high-performance EVM execution environment. It serves as chain abstraction infrastructure for the multi-chain ecosystem, featuring Universal Accounts, Universal Gas, and Universal Liquidity. Through these core functionalities, Particle Network addresses the fragmentation of users and liquidity caused by a growing number of blockchains, coordinating operations across networks and empowering all other chains with enhanced interoperability.

Website | Docs | Discord | Twitter

Share this article

About the author(s)

Peter Pan

Peter Pan

CTO at Particle Network.
Vijay Singh

Vijay Singh

ZK Lead at Particle Network.
Carlos Maximiliano Cano

Carlos Maximiliano Cano

Particle's Content Manager. He's been in Web3 since 2017, collaborating with technical and marketing teams in crowdfunding, research, DeFi, privacy, and zero-knowledge proofs.