# 7. Execution & Lifecycle

### 7.1 Cross‑Chain exchange statuses

```mermaid
stateDiagram-v2
    [*] --> pending

    pending --> confirming
    confirming --> exchanging
    exchanging --> sending
    sending --> finished

    confirming --> failed
    exchanging --> failed
    sending --> failed

    
    confirming --> refunded
    exchanging --> refunded
    sending --> refunded

  
```

Figure 4. Cross‑Chain exchange status state machine.

#### States

<table><thead><tr><th width="138">State</th><th width="144">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>pending</code></td><td>Transient</td><td>Swap awaiting of the inbound deposit.</td></tr><tr><td><code>confirming</code></td><td>Transient</td><td>Inbound transaction detected; waiting for sufficient block confirmations.</td></tr><tr><td><code>exchanging</code></td><td>Transient</td><td>Funds confirmed; executing the swap across venues (DEX/CEX/relay).</td></tr><tr><td><code>sending</code></td><td>Transient</td><td>Swap complete; outbound transaction is being broadcast to the destination chain.</td></tr><tr><td><code>finished</code></td><td><strong>Terminal</strong></td><td>Outbound transaction confirmed. Swap successfully completed.</td></tr><tr><td><code>failed</code></td><td><strong>Terminal</strong></td><td>An unrecoverable error occurred. No refund issued.</td></tr><tr><td><code>refunded</code></td><td><strong>Terminal</strong></td><td>Swap could not be completed; input funds returned to the sender.</td></tr></tbody></table>

***

#### Transitions

<table><thead><tr><th width="206">From</th><th width="146">To</th><th>Trigger</th></tr></thead><tbody><tr><td><code>pending</code></td><td><code>confirming</code></td><td>Inbound deposit detected on-chain.</td></tr><tr><td><code>confirming</code></td><td><code>exchanging</code></td><td>Required block confirmations reached.</td></tr><tr><td><code>exchanging</code></td><td><code>sending</code></td><td>Swap execution succeeded across all legs.</td></tr><tr><td><code>sending</code></td><td><code>finished</code></td><td>Outbound transaction confirmed on destination chain.</td></tr><tr><td><code>confirming</code> → <code>sending</code></td><td><code>failed</code></td><td>Unrecoverable error at any stage (e.g. liquidity failure, timeout).</td></tr><tr><td> <code>confirming</code>→ <code>sending</code></td><td><code>refunded</code></td><td>Swap aborted; input funds returned to sender.</td></tr></tbody></table>

***

#### Notes

* `failed` and `refunded` are **reachable from any transient state** — any stage of the pipeline can trigger them.
* `finished`, `failed`, and `refunded` are all **terminal** — no further transitions occur once reached.
* Consumers should poll or subscribe to status updates and treat any terminal state as a final signal.

### 7.2 Execution orchestration (multi-leg)

```mermaid
flowchart TD
    START["Leg_i ready"]
    PC["Pre-checks
(confirmations, limits)"]
    EX["Execute via adapter
(DEX/CEX/provider)"]
    CR["Confirm / reconcile
(tx, order, provider status)"]
    RT["Retry (backoff)
(retryable errors)"]
    FS["Fail swap
(terminal error)"]
    NX["Persist + enqueue
Leg_{i+1}"]

    START --> PC --> EX --> CR

    CR -- "retryable" --> RT
    CR -- "terminal" --> FS
    CR -- "success" --> NX

    RT -. "retry" .-> EX
```

#### Stages

<table><thead><tr><th width="85">#</th><th width="265">Stage</th><th>Description</th></tr></thead><tbody><tr><td>1</td><td><strong>Leg_i ready</strong></td><td>The orchestrator dequeues <code>Leg_i</code> and begins execution.</td></tr><tr><td>2</td><td><strong>Pre-checks</strong></td><td>Validates confirmations, balance availability, and venue limits before touching any adapter.</td></tr><tr><td>3</td><td><strong>Execute via adapter</strong></td><td>Dispatches the leg to the appropriate adapter: DEX, CEX, or provider.</td></tr><tr><td>4</td><td><strong>Confirm / reconcile</strong></td><td>Polls or receives a callback to verify the tx, order fill, or provider status.</td></tr><tr><td>5a</td><td><strong>Retry (backoff)</strong></td><td>On retryable errors, waits with exponential backoff and re-enters the adapter execution.</td></tr><tr><td>5b</td><td><strong>Fail swap</strong></td><td>On terminal errors, marks the swap as <code>failed</code> and halts the pipeline.</td></tr><tr><td>5c</td><td><strong>Persist + enqueue Leg_{i+1}</strong></td><td>On success, persists the leg result to the State Store and enqueues the next leg.</td></tr></tbody></table>

***

#### Outcome Branches

<table><thead><tr><th width="147">Outcome</th><th>Condition</th><th>Next Action</th></tr></thead><tbody><tr><td><code>retryable</code></td><td>Transient error (e.g. timeout, rate limit, partial fill).</td><td>Back off and re-execute via adapter.</td></tr><tr><td><code>terminal</code></td><td>Unrecoverable error (e.g. insufficient funds, invalid address).</td><td>Fail the swap immediately.</td></tr><tr><td><code>success</code></td><td>Leg fully confirmed and reconciled.</td><td>Persist result and enqueue <code>Leg_{i+1}</code>.</td></tr></tbody></table>

***

#### Notes

* The retry loop re-enters at the **adapter execution** step, not at pre-checks — pre-checks are only run once per leg.
* Retry uses **exponential backoff** to avoid thundering-herd pressure on venues.
* If `Leg_i` is the final leg, `success` triggers swap completion (`finished`) rather than enqueuing a next leg.
* All outcomes are written idempotently to the **State Store** to support crash recovery.

### 7.3 Progress metadata

Status responses include an exchanges\[] array of sub-operations with amounts received, hashes, timestamps, and per-operation status. This enables partners to build debuggable progress UIs and support tooling.

<br>