Transaction Lifecycle

Every withdrawal (a transfer) in The Vault passes through a well-defined set of statuses. These are the same statuses the dashboard shows, the Client API returns, and webhooks report — one vocabulary throughout.

Statuses

Status	Meaning
`PENDING`	Submitted; policy evaluation in progress
`PENDING_AML_VERIFICATION`	Held while AML screening runs — only a verdict releases it (optional module)
`PENDING_APPROVAL`	Awaiting the required mobile approvals
`PENDING_SIGNATURE`	Approvals collected; MPC signing in progress
`READY_TO_SEND`	Signature accepted; ready to broadcast
`SENT`	Broadcast to the network; awaiting on-chain confirmation
`CONFIRMED`	Confirmed on chain — terminal success
`REJECTED`	Rejected by an approver or signer, or cancelled by a user (sub-status carries the reason)
`REJECTED_BY_POLICY`	Blocked by a policy rule
`AML_VERIFICATION_FAILED`	Blocked by AML screening, or no verdict within the screening window
`NO_POLICY_FOUND`	No policy matched — default-deny
`EXPIRED`	Approval window expired before enough approvals
`FAILED`	Signing or broadcast failed

A sub-status carries the detailed reason on terminal states — e.g. REJECTED_BY_APPROVER, REJECTED_BY_SIGNER, CANCELLED_BY_USER, SIGNING_FAILED, BROADCAST_FAILED, ADDRESS_BLACKLISTED. ADDRESS_BLACKLISTED means the destination is blocked by the token’s issuer: the Vault checks issuer blocklists for ERC-20 and TRC-20 tokens.

End-to-End Flow

Stage Details

PENDING — policy evaluation

A newly submitted transfer is PENDING while the policy engine finds the first matching policy (see Policy Engine). If no policy matches, it becomes NO_POLICY_FOUND; if a matching policy rejects it, it becomes REJECTED_BY_POLICY. If a policy allows it, it advances to PENDING_APPROVAL.

PENDING_AML_VERIFICATION — screening

When AML screening is enabled for the profile, a policy-approved transfer is held in PENDING_AML_VERIFICATION while the destination address is screened against the configured providers (see AML Screening). Only a verdict releases it: a pass sends it on to PENDING_APPROVAL (or straight to PENDING_SIGNATURE when the matching policy requires no approvals), a block makes it AML_VERIFICATION_FAILED. If no verdict is reached within the screening window, the transfer is rejected rather than released — screening is fail-closed.

PENDING_APPROVAL — approvals

The transfer waits for the number of approvals the matching policy requires (see Approval Flows). An approval is a user accepting on their paired device — separate from signing. If an approver rejects it becomes REJECTED; if a user cancels it becomes REJECTED (sub-status CANCELLED_BY_USER); if the window expires it becomes EXPIRED.

PENDING_SIGNATURE — MPC signing

Once approvals are collected, the MPC coordinator opens a signing session: the key-share-holding signers each contribute a partial signature, combined into a single valid on-chain signature. On success the transfer moves to READY_TO_SEND; a signing failure moves it to FAILED.

READY_TO_SEND → SENT → CONFIRMED

The signed transaction is broadcast to the network node; the Vault records the transaction hash and the transfer becomes SENT. A broadcast the network rejects moves it to FAILED.

SENT is not the end of the flow. The platform watches the chain for the transaction and, once it is confirmed, moves the transfer to CONFIRMED — the terminal success state. A transaction that the chain reports as failed becomes FAILED; on networks where a signed transaction can lapse before it is included, it becomes EXPIRED.

How much confirmation CONFIRMED stands for is a per-network decision — see the network pages for each network’s confirmation policy.

Every status transition is recorded in the audit log. Track transitions via TRANSFER_UPDATED / TRANSFER_DELIVERED / TRANSFER_FAILED webhooks rather than polling. TRANSFER_DELIVERED is sent twice for a successful transfer — once on SENT (broadcast) and once on CONFIRMED (confirmed on chain); read the status in the payload rather than treating the event itself as final.