---
title: "Continue a prepared execution with its owner's transaction signature"
method: POST
path: "/executions/{id}:submit"
tags: ["Executions"]
---

# Continue a prepared execution with its owner's transaction signature

`POST /executions/{id}:submit`

## Request

- Base URL: `https://api.avaprotocol.org/api/v1`
- URL: `https://api.avaprotocol.org/api/v1/executions/{id}:submit`
- Auth: HTTP bearer

Submit the exact priced operation from prepareWorkflow. Accepts only
the signature, not caller-supplied UserOperation fields. Rechecks the
current owner/account identity, nonce and funding before first relay.
Uses SendUserOpV07 without a server signing key or gas/nonce retry.
Material changes or bundler rejection require fresh prepare/review/signing.
Repeat calls still require a valid signature and reconcile the existing
hash without rebroadcasting. Status polling requires the JWT only.
A durable submitting marker precedes the send. The relay after that
marker keeps running when the client disconnects. A crash before the
RPC leaves the id submitting. A retry looks the hash up at the bundler:
a hit is stored as submitted; an unknown hash stays submitting until
the ten-minute signing window ends, then becomes unsent and requires a
new prepare. That prepare uses the same sender and owner nonce key
(entity 0, global), read from EntryPoint.getNonce with no session
nonce cache, so an unmined operation and its replacement cannot both
be included. A lookup error leaves the marker submitting. A post-send
storage failure also preserves the marker. Poll the prepared hash. An
empty bundler result during the window is unresolved. Uncertain and
submitted records are retained for 24 hours and do not count toward
the 64 prepared-record cap. A response is not a receipt; reuse
GET /userops/{userOpHash} for confirmation.

## Path parameters

- `id` string, required: ULID identifier (26-char Crockford base32).

## Request body

- SubmitExecutionRequest
  - `signature` string, required: 65-byte EOA personal signature of the prepared hash. Recovery byte 0/1 or 27/28; gateway verifies and frames it for MA v2.

## Response `202`

Relay accepted or uncertain; use the existing UserOp status route.

- SubmitExecutionResponse
  - `executionId` string, required: ULID identifier (26-char Crockford base32).
  - `userOpHash` string, required: 32-byte hex hash (UserOp hash, transaction hash).
  - `chainId` integer, required: Numeric chain ID (e.g. 11155111 for Sepolia, 8453 for Base). On chain-aware trigger/node configs this is required and must be a configured chain; on query/filter params it is optional.
  - `submissionState` 'submitting' | 'submitted' | 'unknown', required: Relay progress, not transaction success. Poll GET /userops/{userOpHash} with chainId for the existing receipt status. Unknown/submitting can survive a transport failure or restart; repeating submit never changes the operation or starts another broadcast.

## Other responses

- `400`: Request validation failed.
- `401`: Missing or invalid bearer token.
- `404`: Resource not found.
- `412`: Preparation is stale or rejected; prepare, review and sign again.

## Changes

- **2026-11-04** `6b505ebcf3f7`: 16 info
  - added the optional property `availableWei` to the response with the `400` status
  - added the optional property `availableWei` to the response with the `401` status
  - added the optional property `availableWei` to the response with the `404` status
  - added the optional property `availableWei` to the response with the `412` status
  - …12 more
- **2026-10-28** `4ebf07931311`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/avaprotocol/apis/ava-protocol-avs-api/changes/executions/:id:submit/post.md)

---

[API](https://skmtc.dev/avaprotocol/apis/ava-protocol-avs-api.md) - [All operations](https://skmtc.dev/avaprotocol/apis/ava-protocol-avs-api/llms.txt) - [OpenAPI document](https://skmtc.dev/avaprotocol/apis/ava-protocol-avs-api/revisions/6b505ebcf3f7?raw)