Request a withdrawal
withdrawal_id and initial status. Before anything is signed, the API:
- checks the key’s scope (
withdrawals:create) and wallet binding; - validates the recipient (EIP-55 checksum) and confirms the network’s chain ID matches the asset;
- reserves the amount plus fee against the available balance, so concurrent requests cannot overspend;
- applies workspace controls: the kill switch, destination whitelist and new-address hold, per-transaction and daily limits;
- evaluates policies and, if one matches or approval is required, holds the withdrawal for the approval group.
X-Idempotency-Key returns the original withdrawal.
In the console: open the wallet → Withdrawal → asset, amount (or MAX), recipient. The console shows the planned amount and an estimated network fee before you submit.
Lifecycle
What happens after approval:
- Planning: the API builds the transaction from trusted state: current nonce, EIP-1559 fee parameters, chain ID and the validated recipient. Clients never supply a transaction or a signing hash on this path.
- Signing: a signing request goes to the cluster; a threshold of nodes produces the signature. The private key is never assembled.
- Broadcast: the API assembles the signed transaction, verifies its hash matches the persisted withdrawal, and submits it.
- Confirmation: the receipt is polled until it reaches the confirmation depth. A submitted transaction with no receipt is rebroadcast unchanged; it is never re-signed with different parameters.
Read withdrawals and transactions
Sign a digest directly
For transactions your own systems build (contract calls, or networks and formats the withdrawal path does not construct) the API can sign a digest with the wallet’s key while keeping the same controls.
Signing requests carry their own status and events (
signing.created, signing.pending_approval, signing.resumed, signing.rejected, signing.failed). The API signs what it is given; it does not build or broadcast transactions on these routes.
