Recently, there has been a lot of discussion around @dappOS_com's intent execution network. Many people said that after Paradigm launched 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 are the current problems facing the intention track? How should the decentralized solver execution network be implemented? Next, let’s talk about our views:

1) Paradigm has been throwing out intent-centric for a long time, and the intent track has indeed been lively for a while, with a number of projects including Anoma, Essential, dappOS, Brink.trade, etc. 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 concept of intent itself makes it difficult to focus on one direction and implement it in the short term. In addition to AI Agent as an optional implementation path for the intent execution network, execution methods including account abstraction, chain abstraction, trading bots, and even CEX can be included in the scope of the intent track.

Although AI is disruptive, it is too early and develops slowly, and other abstract intentions are independent and cannot form a synergy. This is the ultimate reason why Paradigm threw out the intent-centric concept and then fell silent.

2) In my opinion, the slow development of the intention track mainly faces two core problems:

1. Intent abstraction is challenging: It seems like a simple sentence. Intent can simplify the user's on-chain operations, but 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 is intended to be solved includes: payment of Gas, social recovery, MEV resistance, one-click Approve-Cancel, minimized slippage, automated execution, etc. When it comes to multi-chain environments, there will also be smart contract compatibility between chains, codec compatibility, liquidity interoperability, standard unification, and other complex security consensus issues.

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 coin is listed on CEX, the cheapest liquidity is usually market makers or VIP customers of the exchange, 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 problem of intent experience by integrating and optimizing the original complex chain infrastructure.


2. Wide range of intent: I have previously written an analysis 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 time for the AI ​​Agent market to mature before it can be included. The development of the intent track we are currently discussing is more centered around the decentralized solver market.

3) The development and implementation of the intention 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 brand new user experience, convenient and efficient compatible interoperability, a decentralized security consensus mechanism, unified liquidity in line with the application market, etc.

Next, let’s take @dappOS_com as an example to analyze the challenges of building a decentralized solver market and what product and mechanism innovations dappOS has 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. For example, a user who only has assets on chain A inputs a demand: I want to complete interactive mining on chains B and C. When this demand reaches the solver open market, providers will normally first break down the user's demand:

1) 0 wear and tear across chains; 2) Swap chooses ultra-low transaction slippage; 3) Avoids the high-gas stage of chain transactions; and finally, after the Solver’s complex path planning, bidding, platform matching, etc., the task is completed with extremely low gas wear and tear on a network that is compatible with unified liquidity of chains B and C.

In this process, what if the user puts forward a demand but no solver accepts it? What if the solver runs away or is rugged? What if the solver price is too high? What if multiple solver suppliers are competing for this task? How to incentivize the successful task and how to punish the failed task? A free and open solver market must solve these problems.

The idea of ​​dappOS is to give up asking the Solver to break down the clear and definite execution steps, and only focus on the execution results that the user wants (for example, chains B and C have completed the interactive payment), let the Solver provide a total quote and tell the user what authorizations need to be made (for example, authorizing the Solver to use the 10USDT of chain A, and finally the interactive payment dApp contract). The entire execution process is fully handed over to the Solver to complete, and the user does not need to pay attention to the details of the execution process.

The result-oriented execution logic is as follows: Solver can integrate the "on-chain + off-chain" paths to achieve optimal cost and efficiency.

In many cases, sending transactions one by one on the chain will inevitably result in cost losses. If off-chain solutions are 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 solver execute, and the solver can also obtain the user's fund authorization and flexibly decide to execute the transaction on-chain or off-chain (and can also aggregate user needs and execute in parallel). In the end, only the result is the basis, giving the user the cheapest and fastest execution result.

For example, in scenarios involving cross-chain funds, you can choose to use the on-chain cross-chain bridge or go directly to CEX for deposits and withdrawals. 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 be to first use low-interest loans on the chain for advance payment and then flexibly redeem.

Anyway, the goal is to make Solvers fully compete with each other and mobilize various resources and authority advantages to optimize users' costs and speed. The question is, if the execution process is "opaque", how can we ensure security? As follows:

2. OMS minimizes the pledge operation mechanism


The idea of ​​OMS (Optimistic Minimum Stake) is to let each task predetermine an amount of compensation to the user in case of failure. Then there is no need to worry about how the Solver completes the task. If it fails, you only need to liquidate the compensation assets pledged by the Solver.

At the same time, the amount of pledge can be minimized for the Solver, and 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, which not only made it impossible to aggregate liquidity, but also impossible to innovate subsequent financial derivatives such as Yield. dappOS defines an intentAsset, which is an asset that is used through the dappOS intent execution network and has the Yield function.

Simply put, intent assets are like a unified liquidity layer that connects various heterogeneous chains. USDT on chain A and USDC on chain B can both circulate on the dappOS chain in the form of intentUSD. Users mint intentUSD just like gathering assets on other chains into a "Yu'ebao" pool, and can use intentUSD as USDT on chain A or USDC on 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 intent 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 on-chain operations, and the saved capital loss will also become Yield.

The end.

Previously, I have looked at many decentralized solver platform construction plans, all of which ignored the error problems existing in fuzzy matching and aimed to achieve 100% accuracy. However, it was not known that the intended transaction execution itself could not be 100% correct. On the contrary, this framework with a fault tolerance rate and corresponding governance mechanism constraints is more conducive to the normal operation of the solver market.

In summary, despite the difficulties of the intention track, 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 onboard.