This section refers to an upcoming product. As such, although our concept and initial design are finalized, some changes might still occur and be reflected accordingly.
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 section 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.
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.
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.
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.
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.
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.
The next chapter will cover the inner workings of the Intent Fusion Protocol and its DSL.
We will continue to iterate upon the Intent Fusion Protocol, focusing on the following aspects:
Public Intent Mempool: In our current design, the Request For Solver phase adopts an off-chain system design. We can further decentralize it by integrating it with the Particle Chain to create a permissionless Solver competition framework.
MEV: We acknowledge that MEV issues will persist in public blockchains. For the public Intent Mempool and Solver Network, we need to explore further collaborations with builders to enhance the value users obtain from transaction conversions.
Privacy: By leveraging ZK technology and combining intents with Confidential Transactions, we can design Confidential Intents. This will provide privacy protection for users during the construction, transmission, and execution of intents.
Updated about 1 month ago