Bridge — virtual accounts, liquidation addresses & wallets

What this covers / who it's for. A durable, dated digest of Bridge's fiat-in (virtual accounts, static memos, prefunded accounts/wallets) and crypto-in (liquidation addresses, drains) orchestration surfaces, plus Bridge custodial wallets — the vendor facts an engineer needs before wiring BridgeRailsProvider's ManagesVirtualAccounts/ManagesWallets and related capabilities (ADR D118) to real traffic, and the facts behind the neutral account-model design in the alignment spec. Facts reflect apidocs.bridge.xyz as fetched on 2026-09-03 — Bridge's docs and terms change; re-verify anything load-bearing via the bridge-development skill's fetch-and-cite protocol (llms.txt → matching .md page → cite URL + date) and changelog/changelog.md before relying on a fact here past its fetch date. This page holds no SDK code and makes no adapter-implementation claims — those live in app-modules/rails/README.md and D118. Companion pages: transfers, fees & external accounts and the alignment design (§2 settlement mode/nominated destination, §3 webhook domain handlers).

Page index

The 23 Bridge docs pages this digest is built from (full list + fetch note at the bottom):

Page	URL
VA object / events / additional functionality	platform/orchestration/virtual_accounts/{virtual-account,virtual-account-events,additional-functionality}.md
API ref: VA create/update/deactivate/reactivate/get/activity	api-reference/virtual-accounts/*.md
Guide: onramp with VAs	get-started/guides/move-money/virtualaccounts.md
Static memos (deprecated)	platform/orchestration/more/staticmemos.md
Prefunded accounts (deprecated)	platform/orchestration/prefunded-accounts-deprecated.md
Liquidation address / drains	platform/orchestration/liquidation_address/{liquidation_address,drains}.md
API ref: LA create/update, batch settlement (deprecated)	api-reference/{liquidation-addresses/*,batch-settlements/create-a-batch-settlement-schedule}.md
Wallets overview / prefunded wallets / move-money / sandbox	platform/wallets/{overview,prefunded_wallets,move-money,sandbox}.md
API ref: Bridge Wallet create/get/history	api-reference/bridge-wallets/*.md
Webhook event structure	platform/additional-information/webhooks/structure.md
Returns (crypto/fiat return policy)	platform/orchestration/more/returns.md

All URLs are prefixed https://apidocs.bridge.xyz/.

1. Virtual accounts — creation per currency/rail

POST /v0/customers/{customerID}/virtual_accounts (Idempotency-Key required). Request CreateVirtualAccount: source.currency (required enum usd|eur|mxn|brl|cop|gbp), destination (required), developer_fee_percent (string, base-100, 0 ≤ x < 100), fee_config (beta, by-request-only, mutually exclusive with developer_fee_percent), travel_rule_data (optional). Precondition: the customer must be onboarded and KYC/KYB-approved.

Per-currency rails, from source_deposit_instructions.payment_rails: USD → ach_push, fednow, wire; EUR → sepa (iban, bic, account_holder_name); MXN → spei (clabe); BRL → pix (br_code); GBP (beta) → faster_payments; COP (beta) → bre_b. BRL/GBP/COP: "only 1st party and 3rd party business payments supported" per the onramp guide. Singular payment_rail on deposit instructions is deprecated: true in favor of payment_rails[]. Fetched 2026-09-03: api-reference/virtual-accounts/create-a-virtual-account.md, get-started/guides/move-money/virtualaccounts.md.

2. TRANSFER-ONLY behavior — no fiat balance

VAs are strictly one-directional on-ramp objects: "convert incoming fiat into crypto and deliver it to your specified destination." No page states a VA holds a balance — funds flow through per deposit, matched and converted automatically. destination.currency (crypto side) enum usdb|usdc|usdt|pyusd|eurc; destination.payment_rail enum (chain) arbitrum|avalanche_c_chain| base|celo|ethereum|optimism|polygon|solana|stellar|tempo|tron|xdc. Deposits under $1 (ACH) are microdeposit verification only and never on-ramped. Fetched 2026-09-03: platform/orchestration/virtual_accounts/virtual-account.md.

Implications for Stables: the core semantic mismatch design §2 resolves — a Bridge VA must be a transfer-only settlement mode with a nominated destination, not the Conduit-shaped balance projection ManagesVirtualAccounts was modeled on.

3. Destination options + mutability

VirtualAccountDestination: currency (req), payment_rail (req, destination chain), and one of address (external crypto wallet) or bridge_wallet_id — "the chain associated with the Bridge Wallet must match the payment rail" — plus deprecated prefunded_account_id; optional blockchain_memo (Stellar-type chains).

Update is PUT /v0/customers/{customerID}/virtual_accounts/{virtualAccountID} (no Idempotency-Key). Body UpdateVirtualAccount — ALL fields optional: destination (currency, payment_rail, address, blockchain_memo, bridge_wallet_id — every one mutable, including switching address ↔ bridge_wallet_id and changing chain/currency), developer_fee_percent (omit = unchanged), fee_config (full replacement; setting one clears the other). source is not in the update schema — source currency/rail is immutable; create a new VA to change it.

"Future transactions will use the updated destination details... Updating a Virtual Account will also create an account_update event" — diff shape account_updates: {field: [old, new]} (e.g. "destination_currency": ["usdc","usdt"]). The effect on deposits already in flight at update time is not documented beyond "future transactions" — treat as unspecified (open question). Fetched 2026-09-03: api-reference/virtual-accounts/update-a-virtual-account.md.

Implications for Stables: destination rotation is an in-place PUT, not a new VA — the mirror must persist account_update events as an audit trail keyed by VA id; this is the "nominated destination" design §2 formalizes.

4. Multiple VAs per currency, deactivate/reactivate

No documented limit on VAs per currency — the docs' list example shows two usd VAs for one customer with different destinations, and create documents only a 200 response (no 409/422 on a duplicate currency).

POST …/virtual_accounts/{id}/deactivate (Idempotency-Key, no body) → status: deactivated; "cannot receive new transactions and all incoming funds will be returned to the sender. In progress transactions received before the Virtual Account was deactivated will process as normal." Emits event deactivation. POST …/virtual_accounts/{id}/reactivate → status: activated; "any transactions returned while... deactivated will need to be reinitiated" — by the sender, not automatically. Emits event activation (the onramp guide instead calls it reactivation — an inconsistency). Status enum is activated|deactivated only — no delete, no replay of bounced deposits. Fetched 2026-09-03: api-reference/virtual-accounts/{deactivate,reactivate}-a-virtual-account.md.

Implications for Stables: deactivation is the freeze primitive for a VA; reactivation does not recover funds, so ops must tell the sender to resend.

5. Fees on VAs and what deposit events report

developer_fee_percent (string, base-100, 0 ≤ x < 100, ≤5 digits precision, always source currency, "only valid on transactions where funds are transferred by Bridge (not to Bridge)"), or the beta fee_config (by request only): source keyed by rail (ach_push, fednow, wire, spei, or default) with {fee_percent, fee_amount, minimum_fee, maximum_fee} — flat deducted first, percent on the remainder, then min/max, capped at the full deposit. Mutually exclusive with developer_fee_percent; setting one clears the other. Fees settle monthly (5th) in USD to the configured fee external account.

Deposit events report inconsistently — trust receipt. funds_received.amount = gross in source currency; payment_submitted/payment_processed.amount = net in destination currency, plus developer_fee_amount/exchange_fee_amount (source currency), subtotal_amount (source minus fees), gas_fee (destination currency, usually 0). A verbatim example shows the event-level subtotal_amount (120.0) disagreeing with receipt.subtotal_amount (116.55) on the same event — the docs are internally inconsistent; trust receipt for the net amount delivered. Fetched 2026-09-03: platform/orchestration/fees-and-mins/devfees.md, platform/orchestration/virtual_accounts/virtual-account-events.md.

Implications for Stables: reconciliation must read receipt.final_amount/ receipt.destination_tx_hash, never the top-level amount/subtotal_amount — enforce at the DTO boundary.

6. VA events, deposit_id grouping, per-rail reconciliation keys

VirtualAccountEvent: id, customer_id, virtual_account_id, type, amount, currency, developer_fee_amount, exchange_fee_amount, subtotal_amount, gas_fee, created_at, deposit_id, source{…}, destination_tx_hash (submitted/processed only), receipt{…}, refund{code, reason, refunded_at}, account_updates{}.

Lifecycle: funds_scheduled (ACH only) → funds_received → [in_review] → payment_submitted (tx hash preliminary) → payment_processed (terminal, destination_tx_hash always set). Refund branch: refund_in_flight → refunded | refund_failed (bank account closed/suspended — Bridge only refunds to the original sender). Independent: account_update, deactivation, activation, microdeposit.

deposit_id is present on every transaction-triggered event, unique per received transaction — the grouping key for a deposit's full event history; may be absent on refunds that occur before a deposit ever completed.

Per-rail reconciliation keys (branch on source.payment_rail first): ACH description, sender_name, sender_bank_routing_number, trace_number; Wire wire_message, bank_routing_number, originator_name, bank_beneficiary_name, imad; SEPA reference, iban, iban_last_4, bic, uetr, payment_scheme; FPS reference, account_number, sort_code, uetr; SPEI description, reference, clabe, tracking_number; PIX description, reference, tracking_number. Bridge's generic mapping: description = ACH description / SEPA+FPS reference / SPEI description+reference / Wire wire_message; trace = trace_number / uetr / tracking_number / imad; sender = sender_name except Wire's originator_name.

Webhooks: category virtual_account.activity, mutation types created, updated only (no status_transitioned — lifecycle state lives in event_object.type, not event_object_status, always null here). event_id is the idempotency key. Fetched 2026-09-03: platform/orchestration/virtual_accounts/virtual-account-events.md.

Implications for Stables: the funding/accounts mirror handlers (design §3) should key every projection row on deposit_id, dedupe webhooks on event_id, and branch reconciliation-key extraction on source.payment_rail — one flat column set will not fit all six rails.

Sample: virtual_account.activity.created

{
  "api_version": "v0",
  "event_id": "wh_t8TAhPPYrRV2v8Asi9ed3sw",
  "event_category": "virtual_account.activity",
  "event_type": "virtual_account.activity.created",
  "event_object_id": "fecffc8b-ed5e-48ae-bd24-b36268330b32",
  "event_object_status": null,
  "event_object": {
    "id": "fecffc8b-ed5e-48ae-bd24-b36268330b32",
    "type": "payment_submitted",
    "amount": "1970.0",
    "source": {
      "description": "EXAMPLE TRANSACTION Brown-Beer Arnoldo Schimmel MD 01202024",
      "sender_name": "Brown-Beer",
      "payment_rail": "ach_push",
      "sender_bank_routing_number": "023883013"
    },
    "gas_fee": "0.0",
    "currency": "usdc",
    "created_at": "2024-02-01T04:31:43.342Z",
    "deposit_id": "c7fab38f-7b65-42d3-bc8d-a694cd1901c1",
    "customer_id": "6ed47d9c-03be-420c-8699-369707ca02e9",
    "subtotal_amount": "1970.0",
    "virtual_account_id": "22033ca5-a991-476c-ade9-911d10f0ece6",
    "exchange_fee_amount": "10.0",
    "developer_fee_amount": "20.0"
  },
  "event_object_changes": {},
  "event_created_at": "2024-02-01T04:32:28.978Z"
}

(the .updated variant is the same object plus destination_tx_hash, with event_object_changes: {"destination_tx_hash": [null, "0xa7de…"]}.) Source: platform/additional-information/webhooks/structure.md.

7. Deprecated fiat-in surfaces — static memos, prefunded accounts, batch settlement

Static memos (→ static template transfers): POST /v0/customers/{id}/static_memos with source {currency: usd, payment_rail: wire} (wire/ACH-push interchangeable), destination, developer_fee_percent. Response is a shared Bridge bank account plus a unique deposit_message — omitting it risks "significant delay in processing or a return of the funds." Event history mirrors VA shape; webhook category static_memo.activity. Not a candidate for new build (USD/wire+ACH only, shared-address risk). Fetched 2026-09-03: platform/orchestration/more/staticmemos.md.

Prefunded accounts (deprecated 2026-03-24): read/list APIs kept "indefinitely," no new creation. Migration: read the deprecated resource's bridge_wallet_id, then use Bridge Wallet APIs — a prefunded account is a Bridge Wallet under a different name. Fetched 2026-09-03: platform/orchestration/prefunded-accounts-deprecated.md.

Batch settlement schedules (deprecated): POST /v0/customers/{id}/batch_settlement_schedules with destination: TransferDestination → {id}, described in prose as usable "as the destination of a liquidation address," but flagged deprecated: true and absent from the LA create schema — the linkage is undocumented. Fetched 2026-09-03: api-reference/batch-settlements/create-a-batch-settlement-schedule.md.

Implications for Stables: do not build against prefunded_account_id or batch settlement in the D118 adapter; use bridge_wallet_id with a designated prefunded wallet instead (§13).

8. Liquidation addresses — purpose, create, and currency-only updates

A liquidation address is a permanent crypto deposit address per (customer, chain, currency) that auto-forwards every incoming crypto deposit to a fixed fiat or crypto destination — the inverse of a VA (crypto-in → fiat/crypto-out).

POST /v0/customers/{customerID}/liquidation_addresses (Idempotency-Key) → 201. Required: currency (usdb|usdc|usdt|pyusd|eurc), chain (arbitrum|avalanche_c_chain|base|celo|ethereum| optimism|polygon|solana|stellar|tempo|tron|xdc|evm). Destination = exactly one of external_account_id (fiat; currency must match destination_currency), destination_address (+ optional memo), bridge_wallet_id ("the chain associated with the Bridge Wallet must match the payment rail"), or deprecated prefunded_account_id. destination_payment_rail (default ach), destination_currency (default usd), six per-rail reference fields (destination_{wire_message,sepa_reference,ach_reference,spei_reference,swift_reference, reference}), custom_developer_fee_percent, travel_rule_data, return_instructions {address, memo} (replaces deprecated return_address; memo required on Stellar). Response adds address, memoless_address (Stellar), state (active|deactivated), return_memo. Duplicate (customer, chain, currency, destination) is rejected. Fetched 2026-09-03: api-reference/liquidation-addresses/create-a-liquidation-address.md.

Update (PUT …/liquidation_addresses/{id}) accepts external_account_id, custom_developer_fee_percent, destination (currency ONLY — "changing the payment rail or address is not currently supported"), the six reference fields, and return_instructions. No deactivate endpoint is listed in llms.txt — the pages are silent on how state becomes deactivated. Fetched 2026-09-03: api-reference/liquidation-addresses/update-a-liquidation-address.md.

Implications for Stables: re-pointing an LA's destination requires a new LA, not an update (unlike a VA) — provider-landscape §3 footnote 17 already flags LAs as a semantic stretch onto ManagesRegisteredAddresses; model LA mutation as currency-only.

9. Drains — the 12-state lifecycle

Each sweep from an LA is a Drain: id, customer_id, liquidation_address_id, amount (dollar-denominated string), currency, state, deposit_tx_hash, from_address, source_payment_rail, destination {payment_rail, currency, to_address | external_account_id, imad | trace_number}, destination_tx_hash, refund_tx_hash, return_details {reason, risk_rejection_reason}, receipt {initial_amount, developer_fee, subtotal_amount, gas_fee, converted_amount, exchange_rate, outgoing_amount, destination_currency, url}.

TransactionStatus enum, verbatim (12 states): awaiting_funds, in_review, funds_received, payment_submitted, payment_processed, canceled, error, undeliverable, returned, refund_in_flight, refund_failed, refunded, plus missing_return_policy (added specifically by the drains page). Forward-only happy path: funds_received → payment_submitted → payment_processed. in_review "rarely triggered... resolves within seconds; if unconfirmed after 24h Bridge contacts the developer." canceled = below-minimum route or AML/EFE rejection, queued for return. undeliverable = bad routing/account or unsupported destination asset. returned = sent but bounced back to Bridge. error = manual intervention required. Fetched 2026-09-03: platform/orchestration/liquidation_address/drains.md.

History: GET …/liquidation_addresses/{id}/drains; pending USDT trades expose GET /liquidation_addresses/drains/pending + a force-execute endpoint. The LA balance endpoint is deprecated: "most Liquidation Addresses no longer hold a balance."

Implications for Stables: a drain is the unit of reconciliation for crypto-in — model the state machine on this exact 12+1-state set (the transfer 13-state set differs — don't reuse one enum for both), and alert ops on error, refund_failed, missing_return_policy.

10. return_instructions and the crypto return policy requirement

Bridge resolves a crypto return address in priority order: (1) Bridge-originated funds → the same Bridge wallet/prefunded account; (2) the LA's own return_address; (3) the originating transfer's return_instructions.return_address; (4) the developer's account-level crypto_return_policy; (5) otherwise the transaction lands in missing_return_policy — a stuck-funds state, not a retryable error.

Policy strategies: static_address (recommended) or refund_to_sender (must be explicitly opted into; Bridge calls it "unsafe" for exchange omnibus wallets, unsupported for stablecoin-sandwich flows). One static address per (currency, chain); a missing chain falls back best-effort to the same currency on another chain. Tron caveat: Tron accepts deposits but does not support refunds — use Ethereum for USDT refunds; Stellar and Tron refunds both require a memo. Fetched 2026-09-03: platform/orchestration/more/returns.md.

Implications for Stables: a static return policy per (currency, chain) we accept must be configured with Bridge before any go-live grant to Bridge for FiatRails/Custody (D118 §Go-live) — route missing_return_policy straight to an ops alert, never a retry loop.

11. Bridge custodial wallets — chains, precision, approval, geo

Create: POST /v0/customers/{customerId}/wallets {chain}. BridgeWalletChain enum, verbatim: base|ethereum|solana|tempo|tron|xdc. Per-chain tokens: Base USDB/USDC/EURC; Ethereum USDB/USDC/USDT; Solana USDB/USDC/USDT/PYUSD/EURC; Tempo USDC/USDT/EURC/PATHUSD; Tron USDT (XDC absent from the token table despite being a valid chain value). Response: id, chain, address, initiation_required?. One wallet per chain-creation call; multi-asset balances per wallet. Amounts are expressed in whole U.S. cents (2 decimal places) — distinct from the SDK-wide decimal-string money convention elsewhere. Fetched 2026-09-03: api-reference/bridge-wallets/create-a-bridge-wallet.md, platform/wallets/overview.md.

Preconditions: customer onboarded, KYC/KYB-approved, endorsements held; every wallet user needs a country on file (US: also a state); a company treasury wallet = create a customer representing the company. "All wallet flows must be approved by Bridge Legal & Compliance" before production. Geo exclusions (verbatim): US New York + Texas; Kenya, Australia, Japan, Singapore, Malaysia, Vietnam, Indonesia.

Balances/history: GET …/wallets/{walletId} → balances[] {balance, currency, chain, contract_address}; aggregate GET /v0/wallets/total_balances. Money in: any orchestration product with destination.bridge_wallet_id, or direct on-chain send for supported tokens only ("others may result in loss of funds"). Money out: Transfers with source {payment_rail: bridge_wallet, bridge_wallet_id}; wallet-to-wallet transfers are "instant." Sandbox: POST …/wallets/{id}/simulate_deposit. Fetched 2026-09-03: platform/wallets/move-money.md.

Implications for Stables: whole-cent precision must not be silently normalized away by the D118 ManagesWallets/ManagesCustodyTransactions DTOs; the geo-exclusion list belongs in the D117 provider-support-matrix pattern.

12. Ordinary vs. prefunded wallets — who can source a transfer

Ordinary Bridge Wallets can only source a transfer where on_behalf_of == owner (the wallet's own customer_id). A prefunded wallet — a Bridge Wallet holding developer liquidity — can source a transfer for any customer by setting on_behalf_of per transfer; there is no API flag that designates a wallet "prefunded" in the fetched create/get schemas — presumably a Bridge-side account configuration. Fund via any orchestration product with a Bridge-wallet destination; pay out via Transfers with source.payment_rail: bridge_wallet. Fetched 2026-09-03: platform/wallets/prefunded_wallets.md.

Implications for Stables: a treasury/float wallet maps to a prefunded Bridge Wallet; per-tenant custodial wallets map to ordinary wallets constrained by on_behalf_of == owner — enforced server-side by Bridge, not overridable by the adapter.

13. initiation_required and the SCA initiation{} shape

If GET wallet returns initiation_required: true, Create Transfer for that wallet must include an initiation object (write-only, create-only, never echoed back):

initiation: {
  channel: p2p_mobile_payment | other_mobile_payment | other,
  subchannel: remote | non_remote,
  attestations: { sca: {
    outcome: sca_used | payment_to_self | trusted_beneficiaries | recurring_transaction |
             contactless_low_value | unattended_terminal_for_transport | low_value |
             secure_corporate_payment | transaction_risk_analysis |
             merchant_initiated_transaction | not_applicable | other,
    auth_factors?: [{ category: knowledge | possession | inherence, authenticated_at, reference }]
  } }
}

auth_factors is accepted only when outcome: sca_used, is optional, and if present requires ≥2 entries from different categories. initiation must be resent identically on an idempotent retry. Fetched 2026-09-03: platform/wallets/move-money.md.

Implications for Stables: SCA metadata must be captured at the app layer before initiating a withdrawal from an initiation_required wallet — Bridge never echoes it back.

14. bridge_wallet.activity events and the payment_route join key

Wallet history: GET …/wallets/{id}/history → BridgeWalletEventResponse: id, bridge_wallet_id, amount, available_balance (post-event), currency, type (deposit|direct_deposit|withdrawal|return|undeliverable|card_spend|card_refund), source{…}, destination{…}, payment_route{…}. Webhook category bridge_wallet.activity (created, updated) carries the identical object — "webhooks and API responses use identical rendering logic."

payment_route is the cross-object join key — its type names which other Bridge object produced the movement: transfer → transfer_id; liquidation_address/drain → drain_id + liquidation_address_id; virtual_account/virtual_account_event → deposit_id + virtual_account_event_id + virtual_account_id; card_spend → card context. The schema's documented enum (transfer, liquidation_address, virtual_account, card_spend) does not exactly match real-example values (drain, virtual_account_event) — match loosely. Fetched 2026-09-03: api-reference/bridge-wallets/get-transaction-history-for-a-bridge-wallet.md.

Implications for Stables: wallet events give a balance-after-event ledger keyed to the originating route id — the join between the custody/wallet mirror and the VA/LA mirrors design §3 must populate; correlate a VA deposit_id to payment_route.deposit_id directly.

Sample: bridge_wallet.activity.created

{
  "api_version": "v0",
  "event_id": "wh_wallet_123",
  "event_developer_id": "dev_111aaa222bbb333ccc",
  "event_category": "bridge_wallet.activity",
  "event_type": "bridge_wallet.activity.created",
  "event_object_id": "bwe_123",
  "event_object_status": null,
  "event_object": {
    "id": "bwe_123",
    "bridge_wallet_id": "bw_123",
    "amount": "50.000000",
    "available_balance": "1050.000000",
    "currency": "usdc",
    "type": "deposit",
    "source": { "currency": "usd", "payment_rail": "ach" },
    "destination": { "currency": "usdc", "payment_rail": "ethereum", "tx_hash": "0xdeadbeef" },
    "payment_route": {
      "type": "drain",
      "customer_id": "cust_123",
      "drain_id": "drain_123",
      "liquidation_address_id": "la_123",
      "liquidation_address_address": "0x1111111111111111111111111111111111111111"
    },
    "created_at": "2025-01-01T00:00:00.000Z"
  },
  "event_object_changes": {},
  "event_created_at": "2025-01-01T00:00:00.000Z"
}

(the .updated example shows event_object_changes: {} — an update webhook can arrive with an empty diff.) Source: platform/additional-information/webhooks/structure.md.

Bridge doc inconsistencies / gaps

• subtotal_amount (event) disagrees with receipt.subtotal_amount on the same VA payment_processed example (120.0 vs 116.55) — §5; trust receipt.
• activation vs reactivation — VA events page names the event activation; the onramp guide calls the same transition reactivation — §4.
• sender_routing_number vs sender_bank_routing_number — an older VA event example uses the former, current docs the latter for the same field — handle both — §6.
• payment_route.type schema vs. real examples — documented enum omits values seen in actual examples (drain, virtual_account_event) — §14.
• No API flag marks a wallet "prefunded" despite documented distinct behavior — presumably server-side configuration, unconfirmed — §12.
• No documented deactivate endpoint for a liquidation address, despite state including deactivated — §8.
• Batch settlement's LA linkage is asserted in prose, absent from the LA create schema, on a deprecated endpoint — §7.
• "Tag wallets & set policies" (wallets overview feature) has no corresponding API field in any fetched schema.

Open questions for Bridge

Consolidated + tracked in flow-alignment.md §Open questions; this section keeps this page's own detail.

1. What happens to a VA deposit already in flight when the VA's destination is updated mid-flight — old or new destination? (§3)
2. Is there any API-visible flag marking a Bridge Wallet "prefunded," or is it purely out-of-band account configuration? (§12)
3. How does a liquidation address transition active → deactivated — undocumented endpoint, or support-request-only? (§8)
4. Does payment_route.type on bridge_wallet.activity events have a stable, complete list, or should integrators expect further undocumented values? (§14)
5. Is there a hard cap on virtual accounts per customer per currency, or is "no documented limit" (§4) actually unbounded?
6. What is the actual linkage between batch settlement schedules and liquidation addresses, given the prose claim with no supporting schema field on a deprecated endpoint? (§7)
7. Can a bounced/refunded VA deposit ever be replayed by Bridge itself, or is "reinitiated by the sender" (§4) the only recovery path?

Fetched 2026-09-03

All pages retrieved as raw .md over HTTPS from https://apidocs.bridge.xyz/, discovered via llms.txt, on 2026-09-03. Re-verify via the bridge-development skill's protocol and changelog/changelog.md before relying on any fact above past this date.

• platform/orchestration/virtual_accounts/virtual-account.md
• platform/orchestration/virtual_accounts/virtual-account-events.md
• platform/orchestration/virtual_accounts/additional-functionality.md
• api-reference/virtual-accounts/create-a-virtual-account.md
• api-reference/virtual-accounts/update-a-virtual-account.md
• api-reference/virtual-accounts/deactivate-a-virtual-account.md
• api-reference/virtual-accounts/reactivate-a-virtual-account.md
• api-reference/virtual-accounts/get-a-virtual-account.md
• api-reference/virtual-accounts/virtual-account-activity.md
• get-started/guides/move-money/virtualaccounts.md
• platform/orchestration/more/staticmemos.md
• platform/orchestration/prefunded-accounts-deprecated.md
• platform/orchestration/liquidation_address/liquidation_address.md
• platform/orchestration/liquidation_address/drains.md
• api-reference/liquidation-addresses/create-a-liquidation-address.md
• api-reference/liquidation-addresses/update-a-liquidation-address.md
• api-reference/batch-settlements/create-a-batch-settlement-schedule.md
• platform/wallets/overview.md
• platform/wallets/prefunded_wallets.md
• platform/wallets/move-money.md
• platform/wallets/sandbox.md
• api-reference/bridge-wallets/create-a-bridge-wallet.md
• api-reference/bridge-wallets/get-a-bridge-wallet-1.md
• api-reference/bridge-wallets/get-transaction-history-for-a-bridge-wallet.md
• platform/additional-information/webhooks/structure.md
• platform/orchestration/more/returns.md

---

Back to the Bridge cluster index · ← Engineering wiki.