Skip to main content
This guide walks through the complete withdrawal flow: discover the account, approve share spending, prepare the withdrawal order calldata, submit, and monitor status.
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 the boringVaultAddress (the share token) and the withdrawQueueAddress (the approval spender).

Step 1: Approve Share Spending (queued withdrawals only)

Before submitting a withdrawal order, the WithdrawQueue 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)
Submit this approval transaction and wait for confirmation before proceeding.

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:
  1. Atomic withdrawal — for eligible callers, shares are redeemed and the wantAsset paid out in a single transaction. No share approval and no order to track.
  2. 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 the to, 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 in withdrawalRequests (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.

Error Responses