Every transaction in Utila has a status that reflects where it is in its lifecycle, from the moment it's created to its final outcome. This applies to all transaction types Utila supports: asset transfers, exchange withdrawals, DeFi interactions, message signing, token approvals, and more.
Transaction statuses are surfaced in four places:
Console and mobile app: visible on the transactions list and on the transaction details page, giving a real-time snapshot of the current state.
Transaction timeline: available inside the transaction details, the timeline shows the full history of status changes the transaction has passed through, in chronological order.
API: the transaction's current status is included in the API response payload, making it straightforward to track and automate workflows programmatically.
Webhooks: each status change triggers a webhook event, allowing external systems to react to transaction updates in real time.
Because most transactions complete within seconds, you'll often only see the final status. The timeline, API payload, and webhook events are especially useful when a transaction moves through multiple intermediate states, for example when it's pending approval, waiting for an AML screening, or taking longer to settle.
Transaction statuses
The statuses vary depending on the scenario, such as AML policy use, system webhook conditions, and intra-vault transfers.
Following are the transaction statuses, organized by their general applicability and specific operational scenarios.
Status | Description | Applicability |
Pending approval | The transaction requires approval by the admin quorum | General |
Awaiting AML policy check | The transaction is waiting for the AML policy screening. Relevant for outgoing transactions and only if if AML is configured. | AML-specific |
Declined by AML policy | Outgoing transaction blocked by AML policy. | AML-specific |
Approved | The transaction passed transaction policy screening and is ready to be signed. | General |
Awaiting signature | The transaction is approved and ready to be signed. | General |
Signed | The transaction is signed but not yet published. | General |
Pending publish | The transaction has been sent to the publishing queue. | General |
Published | The transaction has been published to the blockchain. | General |
Dropped | Another transaction using the same nonce has already been confirmed on-chain, so this transaction will never be confirmed. This applies to nonce-based blockchains such as EVM networks. | General |
Mined | The transaction has been included in a block. | General |
Mined (Failed) | Transaction has entered a block but in a failed state (e.g. a failed smart contract call). | General |
Failed | Transaction failed on-chain and confirmed as such by multiple blocks | General |
Confirmed | The transaction has been confirmed by multiple blocks in the blockchain. | General |
Expired | The transaction was not signed within 72 hours and has by default expired. Users that create transactions via API can override this and set an expiration time of their choice. | General |
For message-signing transactions, the terminal state is either Signed or Completed:
Completed: Used when Utila does not track on-chain usage of the signature (e.g. Sign Typed Data).
Signed: Used when Utila can track on-chain usage (e.g. an EIP-7702 delegation to Utila's smart contract). The transaction remains in this state until Utila detects the signature was used on-chain, at which point it transitions to Completed.
Further context-specific statuses, such as for webhook events in non-AML systems or intra-vault transfers, might differ depending on specific use cases.
Following is a representation of the flow of a transaction. It shows the various decision points and results.
Blockchain forks can move "Mined" or "Mined (Failed)" transactions back to "Published" state.