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.

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 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:

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.