Author: Haotian
Recently, there has been a lot of discussion around @dappOS_com intent execution network. Many people say that after Paradigm threw out intent-centric, only the AI Agent intelligent matching engine was hot for a while, and the overall progress of the intent track was not ideal.
So, what is the crux of the intent track? How should the decentralized solver execution network be implemented? Next, let's talk about the system's views:
1) For a long time after Paradigm threw out intent-centric, the intent track was indeed lively for a while, including Anoma, Essential, dappOS, Brink and other projects. The intent track simplifies the threshold for users to participate in DeFi, can effectively connect with AI, and fits the characteristics of Mass Adoption, and is regarded as a major narrative in the bull market expectations.
However, the "abstract" nature of the intent concept itself makes it difficult to focus on one direction and implement it in the short term. In addition to AI Agent, which can be used as an optional implementation path for the intent execution network, execution methods such as account abstraction, chain abstraction, trading bots, and even CEX can all be included in the scope of the intent track.
Although AI intent is disruptive, it is too early and develops slowly. Other abstract intents are operating independently and cannot form a synergy. This is the ultimate reason why Paradigm threw out the intent-centric concept for a while and then fell silent.
2) In my opinion, the slow development of the intent track is mainly faced with two core problems:
1. The challenge of intent abstraction is huge: It seems to be a simple sentence. Intent can simplify the user's on-chain operations, but now the on-chain environment is becoming increasingly complex. For example, new problems such as (LRT redemption, MEME's preemptive MEV) are constantly introducing new complexities, making the development speed of standard simplified operation infrastructure such as cross-chain bridges, chain abstraction, and account abstraction much lower than the complexity of on-chain operations.
The single-chain environment that intent needs to solve includes: payment of Gas, social recovery, anti-MEV, one-click Approve-Cancel, minimization of slippage, automated execution, etc., involving a multi-chain environment, and there will also be smart contract compatibility between chains, codec compatibility, liquidity interoperability, standard uniformity, and other complex issues such as security consensus.
In addition, there are many users whose intentions cannot rely solely on pure on-chain solutions. Currently, only asset management institutions with large capital scale and diversified trading strategies have relatively ideal solutions in terms of cost and speed: for example, when MEME coins are listed on CEX, the cheapest liquidity is usually market makers or VIP big customers of exchanges, and redeeming income assets such as LRT through DEX or official channels is far inferior to institutions that issue LRT or run nodes.
In short, it is extremely challenging to try to solve the intention experience by integration and optimization on the original complex chain infrastructure.
2. Wide range of intent: I have also written an article to analyze that common intents include centralized intent (CEX), structured intent (Pre-Confirmation), distributed intent (decentralized solver market), and intelligent intent (AI Agent).
In my opinion, centralized intent and structured intent including account abstraction and chain abstraction are not in the key development scope of the intent track. They are all basic conditions of the track, and the user experience needs to be further optimized on their basis before they can be included. As for intelligent intent, it will take the AI Agent market to mature before it can be included in the scope. At present, the development of the intent track we are discussing is more centered around the decentralized solver market.
3) The development and implementation of the intent track is essentially about how to build a decentralized solver execution network. How to do it? An objective and reasonable solution is:
Build a unified middleware network layer and ensure a new user experience, convenient and efficient compatible interoperability, decentralized security consensus mechanism, unified liquidity in line with the application market, etc.
Next, take @dappOS_com as an example to disassemble what difficulties are faced in building a decentralized solver market? What product and mechanism innovations has dappOS explored?
1. Build a decentralized Solver execution network
There is a natural contradiction between the "fuzzification" of user intentions and the programmability of the solutions provided by the Solver solver. For example, a user who only has assets in chain A inputs a demand: I want to complete interactive haircuts on chains B and C. When this demand reaches the Solver open market, normally Providers will first disassemble the user's needs:
1) 0 wear and tear cross-chain; 2) Swap chooses ultra-low transaction slippage; 3) Avoid the high gas stage of chain transactions; Finally, after the complex path planning, bidding, platform matching, etc. of the Solver, the task is finally completed in a network with unified liquidity compatible with chains B and C with extremely low gas wear and tear.
In this process, what if the user raises a demand but the Solver does not accept it? What if the Solver runs away? What if the price of Solver is too high? What if multiple Solver suppliers are competing for this task? How to motivate if the task is successful, how to punish if it fails, etc. A free and open Solver market must solve these problems.
The idea of dappOS is to give up asking Solver to break down clear and definite execution steps, and only focus on the execution results that users want (for example, B and C chains have completed interactive staking), let Solver provide a total quotation and tell users what authorizations need to be made (for example, authorizing Solver to use 10USDT of A chain, and finally interactive staking dApp contracts), and the entire execution process is fully handed over to Solver to complete, and users do not need to pay attention to the details of the execution process.
The execution logic of choosing result-oriented is as follows: Solver can achieve optimal cost and efficiency by combining the "on-chain + off-chain" path.
Many times, sending transactions one by one on the chain will inevitably incur cost losses. If the off-chain solution is interspersed, a comprehensive consideration of cost and efficiency can be achieved, giving users an optimal solution:
For example, if the Solver is a VIP or market maker of the exchange, the cost advantage gained by using the identity resource advantage is far greater than directly calling the AMM contract. When signing, the user can choose to have a certain Solver execute, and the Solver can also obtain the user's fund authorization, and can flexibly decide to execute the transaction on or off the chain (and can also summarize user needs and execute in parallel). In the end, only the result shall prevail, giving the user the cheapest and fastest execution result.
For example: In the scenario involving cross-chain funds, you can choose the on-chain cross-chain bridge or go directly to CEX for deposit and withdrawal. Solver can decide which solution to use; for example: in the scenario of redeeming LRT, the normal logic is to aggregate user redemption requests and execute them centrally. Transactions have to queue and may encounter gas congestion. Advanced logic can first advance low-interest loans on the chain and then redeem flexibly.
Anyway, with "results" as the guide, the goal is to allow Solvers to fully compete with each other, mobilize various resources and authority advantages to give users space for cost and speed optimization. The question is, if there is "opacity" in the execution process, how to ensure security? As follows:
2. OMS Minimized Stake Operation Mechanism
The idea of OMS (Optimistic Minimum Stake) is to predetermine the amount of compensation to be paid to the user when each task fails, and then there is no need to care about how the Solver completes the task. If it fails, just liquidate the compensation assets pledged by the Solver.
At the same time, for the Solver, the pledge amount can be minimized, and it only needs to exceed the compensation amount involved in the task being executed. This will also reduce the pressure on the Solver's capital occupation. The Solver only needs to ensure that the current task is completed, and his own funds can be used for various other businesses at the same time to ensure the maximum efficiency of capital use.
3. Unified liquidity intention assets
Originally, many assets were idle on different chains, not only the liquidity could not be aggregated, but also the subsequent financial derivatives innovation such as Yield could not be carried out. DappOS defines an intentAsset, which is an asset that is used through the dappOS intent execution network and has the Yield function.
To put it simply, intentAsset is like a unified liquidity layer that connects various heterogeneous chains. The USDT of chain A and the USDC of chain B can both circulate in the form of intentUSD on the dappOS chain. Users mint intentUSD just like gathering assets on other chains into a "Yu'ebao" pool, and can use intentUSD as USDT of chain A or USDC of chain B.
This unified liquidity solution not only solves the problem of asset splitting caused by cross-chain environmental differences, but also solves a series of cross-chain wear and tear and idle asset income problems, killing two birds with one stone. In addition, IntentAsset itself also adopts a decentralized, non-custodial operating mechanism setting.
Why can intent assets have both convenience and Yield attributes? On the one hand, the Solver market can solve most of the user's intention needs, and there is no obvious difference from holding ordinary USDT; on the other hand, after calling the Solver's comprehensive permissions and capabilities, there will be a "profit" space for intersecting pure chain operations, and the saved capital loss will also become Yield.
The above.
Before, I looked at many construction plans of decentralized Solver platforms, all of which ignored the error problems existing in fuzzy matching, and all aimed to pursue 100% correctness. As a result, it is not possible for the execution of intention transactions itself to be 100% correct. On the contrary, this framework with a tolerance rate and corresponding governance mechanism constraints is more conducive to the normal operation of the Solver market.
In short, although the intention track is full of difficulties, it is undeniable that it is the only way for the Crypto market to enter Mass Adoption. Because it solves the B-side of Crypto composability, in the context of the current market over-stacked with Lego abstractions, this paradigm of hiding transaction execution and focusing only on results can bring in a larger number of users.
JinseFinance
Coinlive 
Bitcoinist
Cointelegraph