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_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 — 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 |
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.
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_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
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. On-chain confirmation is then tracked by the
blockchain indexer.
Every status transition is recorded in the audit log. Track transitions via
TRANSFER_UPDATED / TRANSFER_DELIVERED / TRANSFER_FAILED
webhooks rather than polling.