Queue-routed withdrawals on Amplify are asynchronous. Submitting a
withdrawal order places it in a queue. Once processed by the protocol, the
requested asset is transferred to the user. Monitor order status via
GET /v2/amplify/withdrawalRequests. Callers eligible for an atomic
withdrawal (see Step 2) settle synchronously instead — for them the
approval and monitoring steps below do not apply.Prerequisites
- A Paxos Labs API key
- An EVM-compatible signer (private key, HSM, or wallet service)
- The user must hold vault shares (the BoringVault ERC-20 token) from a prior deposit
Step 0: Fetch Account Details
Retrieve the account’s contract addresses. You need theboringVaultAddress (the share token) and the withdrawQueueAddress (the approval spender).
Step 1: Approve Share Spending (queued withdrawals only)
Before submitting a withdrawal order, theWithdrawQueue contract must be approved to spend the user’s vault shares. This step does not apply to atomic withdrawals — they involve no share allowance. To learn the mode before approving, run Step 2 first with responseFormat=full: atomic withdrawals return functionName: 'bulkWithdraw' (the approval only needs to confirm before the withdrawal is submitted).
Construct a standard ERC-20 approve(spender, amount) call:
- Token contract: the
boringVaultAddress - Spender: the
withdrawQueueAddress - Amount: the share amount to withdraw (in share token base units, 18 decimals)
Step 2: Prepare Withdrawal Calldata
GET /v2/amplify/withdraw returns the transaction to submit a withdrawal order.
Parameters
The server selects the withdrawal mode automatically for each caller and account — you do not pass an
atomic flag:- Atomic withdrawal — for eligible callers, shares are redeemed and the
wantAssetpaid out in a single transaction. No share approval and no order to track. - Queued withdrawal order — all other callers submit an order to the WithdrawQueue. Depending on the account’s configuration, the order settles in the same transaction or asynchronously once the queue is processed.
Atomic withdrawals are identified by
functionName: 'bulkWithdraw' in responseFormat=full or structured responses (their transaction’s to is not the WithdrawQueue). The Step 1 share approval is not required, and no order appears in GET /v2/amplify/withdrawalRequests — settlement is complete when the transaction confirms. The calldata includes a server-computed minimum-output floor at the current exchange rate.Response
Step 3: Sign and Submit
Broadcast the transaction using theto, data, and value fields. For queued withdrawal orders, the vault shares are locked in the WithdrawQueue upon confirmation. For atomic withdrawals, confirmation is settlement — the wantAsset is paid out in this transaction.
Step 4: Monitor Status (queued withdrawals only)
An atomic withdrawal creates no order, so it never appears inwithdrawalRequests (and there is nothing to cancel) — treat transaction confirmation as completion. For queued orders, poll GET /v2/amplify/withdrawalRequests to track order progress. Omit the status predicate so the order remains visible as it transitions through terminal states:
Filtering on
status=PENDING will cause the order to disappear from the response as soon as it reaches a terminal state, which hides the final outcome from readers polling for completion.
Complete Examples
These examples show the queued path end-to-end. Callers routed to an atomic withdrawal skip the approval and polling sections — see the note in Step 2.- Node.js
- Python
- Go
- Java