Outcome completion

What it refers to

Outcome completion refers to the point at which an intended outcome has actually been reached and is usable.

It is not the same as transaction confirmation. It is not the same as partial progress. It is not the submission of the final step in a sequence.

Outcome completion means the system has reached the state that was originally intended, and that state is stable enough to act upon.

Examples:

• The swapped asset is available and usable on the destination network
• A borrow position is open with the expected parameters
• A rebalanced portfolio reflects the intended allocation
• Value has been redistributed and can now be used without additional steps

Outcome completion is about the end state being real, not just recorded. For a cross-network swap (often searched as swap across chains), this means the destination asset is not just bridged but genuinely available and usable.

Why this concept exists

In single-system environments, confirmation often implied completion.

Once a transaction was confirmed, it was reasonable to assume the intended result had occurred. There was little separation between action and outcome.

In multi-network systems, that assumption no longer holds.

Today:

• A transaction can succeed locally while the broader goal remains unmet
• Intermediate steps may complete while others remain pending
• Liquidity conditions may change before the intended state is fully reached
• Value may exist in a technically valid state but not yet in a usable one

Because execution may span time and systems, confirmation and completion are no longer identical.

We need the concept of outcome completion to clearly distinguish between “something happened” and “the intended state was reached.”

What this changes for system design

If confirmation is not the same as completion, systems must define explicitly what completion means.

System design must:

• Establish clear criteria for when an intended outcome is considered reached
• Differentiate between intermediate states and final usable states
• Track whether coordinated steps collectively achieve the desired result
• Communicate state transitions in a way that reflects real progress

This shifts success metrics from technical validation to outcome validation.

Systems must be designed to observe and reason about state across environments, rather than relying on single confirmations as proof of success.

Outcome completion forces systems to treat usability and final state as first-class concerns.