This guide walks through the complete withdrawal flow: discover the account, approve share spending, prepare the withdrawal order calldata, submit, and monitor status.Documentation Index
Fetch the complete documentation index at: https://developers.paxoslabs.com/llms.txt
Use this file to discover all available pages before exploring further.
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.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).
| Field | Usage |
|---|---|
boringVaultAddress | The ERC-20 share token contract; also the vaultAddress param |
withdrawQueueAddress | The spender address for the share approval |
Step 1: Approve Share Spending
Before submitting a withdrawal order, theWithdrawQueue contract must be approved to spend the user’s vault shares.
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
| Parameter | Type | Required | Description |
|---|---|---|---|
vaultAddress | string | Yes | BoringVault contract address (0x + 40 hex chars) |
wantAsset | string | Yes | ERC-20 token address to receive upon withdrawal |
shareAmount | string | Yes | Vault share amount to redeem, in share token base units (decimal string, 18 decimals) |
userAddress | string | Yes | Wallet submitting the withdrawal. Also the default for intendedDepositor, receiver, and refundReceiver when those are omitted. |
chainId | number | Yes | EVM chain ID |
intendedDepositor | string | No | On-chain SubmitOrderParams.intendedDepositor. Defaults to userAddress. |
receiver | string | No | On-chain SubmitOrderParams.receiver — address credited with the wantAsset on settlement. Defaults to userAddress. |
refundReceiver | string | No | On-chain SubmitOrderParams.refundReceiver — address credited with refunded shares if the order is cancelled. Defaults to userAddress. |
responseFormat | string | No | encoded (default), full, or structured |
The server decides whether to queue the order (
submitOrder) or settle it atomically (submitOrderAndProcessAll) based on the account’s on-chain RolesAuthority configuration. You do not need to pass an atomic flag — atomic-eligible accounts are routed automatically.Response
Step 3: Sign and Submit
Broadcast the transaction using theto, data, and value fields. The vault shares are locked in the WithdrawQueue upon confirmation.
Step 4: Monitor Status
PollGET /v2/amplify/withdrawalRequests to track order progress. Omit the status predicate so the order remains visible as it transitions through terminal states:
| Status | Meaning |
|---|---|
PENDING | Order is in the queue, waiting for processing |
COMPLETE | Assets have been transferred to the user |
PENDING_REFUND | Order is being refunded |
REFUNDED | Vault shares have been returned to the user |
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
- Node.js
- Python
- Go
- Java
Error Responses
| Status | Meaning |
|---|---|
| 400 | Invalid parameters |
| 404 | No account found for the given vaultAddress + chainId |