7. Execution & Lifecycle

7.1 Cross‑Chain exchange statuses

Figure 4. Cross‑Chain exchange status state machine.

States

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

---

Transitions

From	To	Trigger
pending	confirming	Inbound deposit detected on-chain.
confirming	exchanging	Required block confirmations reached.
exchanging	sending	Swap execution succeeded across all legs.
sending	finished	Outbound transaction confirmed on destination chain.
confirming → sending	failed	Unrecoverable error at any stage (e.g. liquidity failure, timeout).
confirming→ sending	refunded	Swap aborted; input funds returned to sender.

---

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)

Stages

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

---

Outcome Branches

Outcome	Condition	Next Action
retryable	Transient error (e.g. timeout, rate limit, partial fill).	Back off and re-execute via adapter.
terminal	Unrecoverable error (e.g. insufficient funds, invalid address).	Fail the swap immediately.
success	Leg fully confirmed and reconciled.	Persist result and enqueue Leg_{i+1}.

---

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.