Native bridge
The native bridge uses the same durable-order model as swaps. A deposit creates a native-to-wrapped order; a withdrawal creates a wrapped-to-native order. The returned order is the source of truth for its funding instruction and settlement state.
Check current bridge terms
| Endpoint | Use it for |
|---|---|
GET /v2/bridges/terms | Current bridge fee schedule, minimums, and per-asset availability. |
Do this at order creation time. Fees, minimums, and availability are runtime configuration, not constants in an integration.
A minimums value is the floor on the gross sent amount, in both directions; fees are deducted from it. Sending exactly the minimum settles.
Choose the route
These are the possible directions, not a list of what is switched on today. Each asset is independently enabled, and an asset can be off in both directions.
| Asset pair | Native → wrapped | Wrapped → native |
|---|---|---|
| XMR / XMR1 | POST /v2/bridges with { asset: "xmr", direction: "deposit" } | POST /v2/bridges with { asset: "xmr", direction: "withdraw" } |
| TRX / TRX1 | POST /v2/bridges with { asset: "trx", direction: "deposit" } | POST /v2/bridges with { asset: "trx", direction: "withdraw" } |
Read GET /v2/bridges/terms at order time for what is actually available. Its assets array lists every bridge asset this API knows with live deposit and withdraw booleans, read from the same gates POST /v2/bridges enforces. An asset stays listed—with its fees and minimum—while it is switched off, so a picker can grey a row instead of losing it.
Creating against an unavailable asset or direction answers 503 with code: "unavailable", not 400. That is a temporary refusal about our configuration, not a complaint about your request: do not retry it as a validation failure, and do not hard-code an asset as available because it worked earlier.
Create a deposit
For a native-to-wrapped deposit, provide the destination address. Store the generated sessionId returned for this individual order as its owner credential.
{ "toAddress": "<wrapped-asset-recipient>" }
The response is a bridge deposit order. Use its returned deposit address and status to guide the user, then track it at GET /v2/bridges/{id}.
Create a withdrawal
For a wrapped-to-native withdrawal, supply the native destination. The engine derives settlement facts from the observed transfer; never treat client-supplied sender information as proof of payment.
{ "toAddress": "<native-asset-recipient>" }
Use the returned bridge order's funding instruction rather than assuming a custody address or amount. The order reports confirmations, settlement information, and terminal outcomes. A withdrawal payout is derived from the wrapped amount actually observed, not from a client-supplied amount.
Track and recover
Bridge orders use GET /v2/bridges/{id}. For a failed or expired eligible order, the owner can submit a refund address through PUT /v2/orders/{id}/refund-address. See live updates for the optional WebSocket accelerator.
Read money and settlement and order lifecycle before implementing funding, status, or refund screens.