> For the complete documentation index, see [llms.txt](https://docs.intents.aurora.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.intents.aurora.dev/intents-connect/developer-guides/evm/asynchronous-operations.md). # Asynchronous operations Some on-chain operations don't settle in the transaction that triggers them. You submit a request now, and the funds it produces arrive at the intermediary account *later* — minutes, hours, or even days afterwards. There is no way to say "do the request, wait for settlement, then bridge the result out" inside a single execution, so model it as **two separate executions**: 1. Trigger the async operation with `POST /api/v1/executions/{wallet}/steps`. 2. Once the settled funds (a 1Click-supported token) land at the intermediary, move them to another network with `POST /api/v1/executions/{wallet}`. ### TL;DR 1. **Trigger** — call `POST /api/v1/executions/{wallet}/steps` with the steps that submit the request (e.g. an `approve` + a request-redeem). No `x-api-key` is needed for this endpoint. 2. **Wait** — the operation settles off the critical path. When it does, the payout token (e.g. USDC — anything 1Click supports) arrives at the **intermediary account** on the destination chain. 3. **Move** — call `POST /api/v1/executions/{wallet}` with a quote and `outOperation: true` to bridge the settled funds to another network. This endpoint **requires** an `x-api-key` header. ### Why two executions Request-style flows (request-then-redeem, queued withdrawals, epoch-based unstaking, …) only *enqueue* the operation in the triggering transaction. The payout is produced asynchronously, so it cannot be bridged in the same transaction — at trigger time the funds don't exist yet. The intermediary account is the constant across both executions: the trigger runs there, the settled funds arrive there, and the second execution spends from there. So you split the work along the settlement boundary — one execution to start the operation, a second one to move the result once it's real. ### The intermediary account The intermediary is a deterministic EVM address derived from the wallet. It is where steps execute and where bridged or settled funds land on the destination chain. Fetch it before building steps: ```http GET /api/v1/executions/{wallet}/intermediary ``` ```json { "result": { "evm": "0x3eb032bca9a6ceeb8ce69fdf4ec79187fdddd25e" } } ``` Two things to keep in mind: 1. **It must already hold the destination token to pay gas on step 1.** The `/steps` execution collects its network fee in the destination token, so the intermediary needs a balance there *before* you trigger 2. **The settled funds arrive here, not at the user's wallet.** That is exactly why step 2 exists: to forward them on. ### Step 1 — trigger the async operation (`/steps`) `POST /api/v1/executions/{wallet}/steps` runs your steps against the funds the intermediary already holds — no bridge, no quote. Submit the steps that enqueue the operation: ```json { "version": "1.0", "type": "evm", "destinationAsset": "nep141:base-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.omft.near", "steps": [ { "to": "0x1111111111111111111111111111111111111111", "value": "0", "functionSignature": "approve(address,uint256)", "parameters": ["0x2222222222222222222222222222222222222222", "1000000000000000000"] }, { "to": "0x2222222222222222222222222222222222222222", "value": "0", "functionSignature": "requestRedeem(address,uint256)", "parameters": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "1000000000000000000"] } ], "metadata": { "title": "Request redeem", "intent": "async_redeem" }, "dry": false } ``` Notes: * `destinationAsset` is the token the operation eventually pays out (here, USDC on Base). It is **required**. * Neither step above calls the USDC contract — they only touch the vault. The `/steps` endpoint rejects step sets that never call the destination token, so you'll need to append a zero-value transfer to satisfy that guard * This endpoint does **not** require `x-api-key`. The execution returns a payload to sign and submit (see Signing & status). Once submitted, the request is enqueued on-chain and you wait for settlement. ### Step 2 — move settled funds to another network When the operation settles and the payout token is at the intermediary, bridge it out with the quote-backed endpoint: ```http POST /api/v1/executions/{wallet} x-api-key: Content-Type: application/json ``` ```json { "version": "1.0", "type": "evm", "quote": { "originAsset": "nep141:base-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.omft.near", "destinationAsset": "", "amount": "1000000", "swapType": "EXACT_INPUT" }, "outOperation": true, "metadata": { "title": "Withdraw to target network", "intent": "async_withdraw" }, "dry": false } ``` * `originAsset` is the settled token now held by the intermediary; `destinationAsset` is where the user wants it. * `outOperation: true` executes on the origin chain and bridges the output to the destination via 1Click. * This endpoint **requires** `x-api-key` — it fetches a 1Click quote and prices per-key fees server-side. --- # 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.intents.aurora.dev/intents-connect/developer-guides/evm/asynchronous-operations.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.