Withdrawal statuses
| status | description | allowed transitions |
|---|---|---|
created | The withdrawal has been created and the required balance, including the network fee, has been debited. The network transfer has not been dispatched yet. | processing |
processing | The withdrawal is being sent to the blockchain network. The system is preparing or monitoring the underlying network transfer. | completed, failed |
completed | The withdrawal was confirmed on-chain. The response may include the final transaction hash. | Final status |
failed | The withdrawal could not be completed, for example because the network transfer failed, was dropped, or expired. The debited balance is returned when the failure is finalized. | Final status |
cancelled | Reserved status for a withdrawal cancelled before completion. Current withdrawal flows do not produce this status. | Final status |
Integration notes
Section titled “Integration notes”Treat completed as the successful final status.
Treat failed and cancelled as unsuccessful final statuses.
cancelled is part of the public status enum for compatibility, but it is not emitted by the current withdrawal lifecycle.
Withdrawal is created in created status after a quote is committed. It normally moves to processing automatically, then finishes as either completed or failed.
The commit API response returns the initial created status. The first withdrawal.statusChanged webhook typically arrives when the withdrawal moves to processing.
Cryptonly sends withdrawal.statusChanged on each post-commit status transition (created → processing, then processing → completed or failed). Treat completed and failed as the final outcomes for fulfilment.
Always use webhooks as the source of truth for status changes. Polling can be used as a fallback.