Intended outcome
The specific end state a user or system aims to reach, independent of the individual transactions required to achieve it.
What it refers to
An intended outcome is the state a user or system actually wants to reach when initiating an action.
It is not a transaction. It is not a quote. It is not the submission of a message to a network.
An intended outcome describes the final usable result.
Examples:
- Having a specific asset available on a specific network
- Opening a borrow position with defined parameters
- Rebalancing a portfolio to a target allocation
- Converting one asset into another and being able to use it immediately
The intended outcome focuses on the end state, not the steps taken to get there.
Why this concept exists
In simpler financial systems, submitting a transaction usually meant the job was done.
The act of sending money, placing an order, or executing a trade was often indistinguishable from reaching the desired result. The transaction and the outcome were effectively the same thing.
That is no longer true in multi-network environments.
Today:
- Assets may arrive on a network without sufficient liquidity to act
- Actions may require multiple coordinated steps
- Execution may partially succeed
- Timing and network conditions may alter what is achievable
As a result, a transaction succeeding does not guarantee that the intended result has been achieved.
We need the concept of intended outcome because the gap between “action submitted” and “goal reached” has widened.
What this changes for system design
If intended outcomes are distinct from transactions, systems cannot measure success purely by technical confirmation.
System design must:
- Define clearly what state qualifies as completion
- Distinguish between local success and overall goal fulfillment
- Track whether intermediate steps actually lead to the desired result
- Make it visible when the intended state has or has not been reached
This shifts focus from activity to results.
Instead of asking “did the transaction execute?”, systems must ask “did the user reach what they were trying to reach?”
Designing around intended outcomes requires systems to treat actions as goal-driven processes rather than isolated events. This goal-driven model is sometimes described as intent based execution (or intent based swap when applied to token exchanges): the system's role is to fulfill the user's declared objective, not merely process discrete instructions.
