# Execution Lifecycle
An **Execution** represents a state machine that coordinates two independent phases:
1. **Deposit phase** (funds arrival and confirmation)
2. **Operation phase** (transaction execution on the destination chain)
Depending on the usage scenario, these phases may occur in reverse order.
### Core Concepts
* **Execution**: A single user intent being processed.
* **Deposit**: Movement of funds into the system (source → destination).
* **Operation**: Action performed using those funds (e.g., deposit, withdraw).
* **Intermediary account**: Account on the destination chain derived from the source account, controlled by the source private key.
Each execution progresses through a deterministic set of states. Execution state can be [requested](/intents-connect/intents-connect-api-reference/request-an-execution.md) and [monitored](/intents-connect/intents-connect-api-reference/fetch-executions.md) through an API:
* status is polled
* state is authoritative
* transitions are eventual
## States
### Active States
After creating the execution via the API, to continue the flow, instruct the user to make a deposit, authorise the operation, or both, as explained in the [Execution Scenarios](#execution-scenarios).
| Status | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| `CREATED` | Execution requested by integrator. Awaiting next step (deposit or operation, depending on flow). |
| `DEPOSIT_PENDING` | Deposit transaction detected or expected but not yet confirmed. |
| `DEPOSIT_PROCESSING` | Deposit is being verified and finalised (e.g., confirmations, indexing). |
| `OPERATION_PENDING` | Deposit completed. Operation is queued but not yet submitted. |
| `OPERATION_PROCESSING` | Operation submitted and awaiting confirmation on the destination chain. |
| `SUCCESS` | Execution completed successfully. |
* `DEPOSIT_PENDING → DEPOSIT_PROCESSING` occurs when the deposit transaction is detected on-chain.
* `DEPOSIT_PROCESSING → OPERATION_PENDING` occurs after the deposit is completed.
* `OPERATION_PENDING → OPERATION_PROCESSING` occurs when the deposit transaction is detected on-chain.
* `OPERATION_PROCESSING → SUCCESS` occurs after the on-chain transaction is successful.
### Failure States
All failure states are terminal. Recovery actions (e.g., withdrawal or retry via a new execution) must be handled explicitly by the client, because assets end up in intermediary accounts, requiring a retry or withdrawal.
It is recommended to let the user decide on the exact outcome, which may require creating a new execution.
| | |
| ------------------ | --------------------------------------------------------------------------------------------------------------------- |
| `EXPIRED` | The deposit was not completed within the allowed time window specified by the execution metadata returned by the API. |
| `DEPOSIT_FAILED` | Deposit failed or was reverted/refunded. |
| `OPERATION_FAILED` | Operation failed after deposit completion. Recovery actions may be required (e.g. rety or withdrawal). |
* `DEPOSIT_PENDING → EXPIRED` occurs once the deposit wasn't made in the time frame returned by the API. Transferred funds will be refunded.
* `DEPOSIT_PROCESSING → DEPOSIT_FAILED` occurs on deposit failure, such as an invalid deposit amount. Transferred funds will be refunded.
* `OPERATION_PROCESSING → OPERATION_FAILED` occurs when the destination chain transaction failed and wasn't included on the chain.
### State Machine Invariant
* Execution is **strictly linear within each phase** (deposit → operation or operation → deposit).
* Failure states are **terminal**.
* Only one phase is active at a time.
* Transitions are **event-driven** (deposit detected, on-chain confirmations, backend validations).
## Execution Scenarios
There are different scenarios in which you can use the [API](/intents-connect/intents-connect-api-reference.md), each covering a different user flow. Below is a list of the most common scenarios.
State transitions are strictly sequential within each phase; no states are skipped.
### 1. Inbound Execution (Deposit → Operation)
User funds originate from a source chain and are used on the destination chain.
This scenario involves two user actions:
1. Transfer funds into the deposit account created by execution.
2. Sign the operation authorisation message and submit it.
### 2. Outbound Execution (Operation → Withdraw)
The user authorises the operation first, then receives the funds back to the source.
In outbound flows, the “deposit” phase represents settlement (funds returning to the user), not inbound funding.
This scenario involves a single user's actions:
1. Sign the operation authorisation message and submit it.
Note: The transfer into the deposit account used for withdrawal must be handled in the signed operation.
### 3. Destination-Only Execution (Operation Only)
No cross-chain movement. Execution happens entirely on the destination chain.
This scenario involves a single user's actions:
1. Sign the operation authorisation message and submit it.
---
# Agent Instructions: 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:
```
GET https://docs.intents.aurora.dev/intents-connect/deep-dive/execution-lifecycle.md?ask=
```
The question should be specific, self-contained, and written in natural language.
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.