Intent-Execution Separation

What is intent-execution separation, and how does it differ from the simulation-execution gap discussed earlier in this series?

The simulation-execution gap discussed earlier in this series addresses a deviation that can arise between simulation and actual execution for an already-decided-on specific operation — this problem's premise is that the specific operational steps to execute have already been determined. Intent-execution separation addresses a more upstream architectural question: what a user originally expresses — is it an abstract goal ("I want to swap asset A for asset B at the lowest cost," say), or a series of specific operational steps ("execute the swap on this specific exchange via this specific route," say)?

This means the simulation-execution gap happens after specific operational steps have already been determined, while intent-execution separation is an architectural question about who determines the specific operational steps themselves, and when they get determined — if an intent-layer architecture is adopted, the specific steps often only get determined in real time by the system after the user declares their goal, which also means the simulation-execution gap risk shows up at a different point in time and in a different form.

Why does a direction like intent-execution separation exist, and what problem does it solve?

A traditional architecture requiring a user to specify the specific operational steps themselves puts the responsibility of finding the best execution path onto the user (or the user's agent) — if the market has multiple possible execution paths, the user has to compare them themselves or through a tool to find the one with the lowest cost and lowest risk, a process that's itself both time-consuming and requires the user to have a certain judgment capability.

An intent-execution separation architecture shifts this burden away — the user just needs to declare the result they want, leaving which path to take to achieve it to the system itself (or the multiple execution parties the system connects to behind the scenes, decided through some bidding or optimization mechanism). This design's motivation is letting a user obtain a near-optimal execution result without needing professional path-selection capability — fundamentally shifting the work of finding the optimal solution from the user onto the system design.

How does an intent-execution separation architecture actually work, and what new risk does this architecture bring?

A typical operating method: a user submits an intent declaration ("swap asset A for asset B under a condition not exceeding a certain slippage," say), and this intent gets broadcast out, letting multiple independent execution parties (sometimes called solvers) compete against each other over who can provide the best execution result. The user's intent eventually gets matched by the system to one winning execution party, who's responsible for completing the specific transaction steps.

The new risk this architecture brings is that the specific execution detail a user could originally directly control now becomes the responsibility of a third-party execution party matched by the system — if this matching mechanism is poorly designed, or if the execution parties competing are actually secretly colluding with each other (rather than genuinely competing independently), a user's declared intent could get executed in a way unfavorable to themselves, and since they can't see the specific execution process, they'd have a hard time noticing in time. This is also exactly why the solver collusion risk discussed earlier in this series is especially prone to manifesting under this kind of architecture.

What's the practical impact of intent-execution separation for everyday users, and how should it apply to evaluating DeFAI products?

If you're using a DeFAI product adopting an intent-layer architecture, it means you're enjoying the convenience of not needing to judge the best execution path yourself, but you're also simultaneously handing off the responsibility of judging whether the execution process is genuinely fair and optimal to the system's matching mechanism behind the scenes — meaning when evaluating this kind of product, the focus is no longer whether you yourself have the capability to judge which path is better, but verifying whether this system's matching mechanism itself has sufficient transparency and competitive mechanism to ensure the matching result genuinely benefits you, rather than being monopolized and manipulated by a small number of execution parties.

In practice, it's worth directly asking this kind of product's team: roughly how many execution parties participate in the competition, whether these execution parties are genuinely independent of each other, and whether the system provides a post-execution, verifiable result letting you confirm you genuinely got the optimal (or near-optimal) result at that moment, rather than having your interest secretly sacrificed by the system.