Routes & atomic execution

How Terminal 1 bundles dependent actions into a single execution path.

A route is an ordered bundle of dependent actions executed as a single transaction where possible (e.g., swap → repay → settle). Routes are atomic: either every step completes and the route succeeds, or the transaction reverts and no state changes are applied. Terminal 1 builds routes by selecting compatible venues and amounts, then constrains execution with explicit minimums/maximums so the route fails safely if prices, balances, allowances, or market liquidity change.

Execution environments

Terminal 1 can express a route in two ways:

• Atomic execution (single transaction): the full route executes in one transaction and either completes in full or reverts. This is the primary execution path for EOAs and for workflows that require flash loans.

• Safe mode (native Safe batch): for Safe wallets, many routes can be expressed as a native Safe batched transaction generated via the Safe API. This makes each step visible in the Safe interface prior to execution. Routes that require flash loans cannot be expressed as a native Safe batch.

When routes revert

• A required approval/permit is missing or too small.

• Output is below the minimum after fees/slippage (“output insufficient”).

• A venue quote is stale or liquidity moved before inclusion.

• A route constraint fails (price impact, buffer, deadline, etc.).

What to review before signing

• Input/output tokens and amounts.

• Venue sequence (which protocols/aggregators are used).

• Min/Max constraints (slippage + buffers).

• Approval scope (token + spending cap).

What atomic execution does not guarantee

• Guarantees: atomicity (all-or-nothing) and bounded authorization where supported.

• Doesn’t guarantee: a specific price or fill if market conditions change; the route will revert instead.