> For the complete documentation index, see [llms.txt](https://docs.baltex.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.baltex.io/whitepaper/7.-execution-and-lifecycle.md). # 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

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) ```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

#	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.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.baltex.io/whitepaper/7.-execution-and-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.