Currencies & Networks
How currencies, tokens, and blockchain networks are identified across the API. Read this before constructing order or rate requests — most integration mistakes trace back to currency identification.
Currency codes
Every currency has an internal code. For native coins it is the plain ticker (BTC, ETH, SOL). For tokens that exist on multiple networks, the code is the ticker plus a network suffix:
| Token | Network | Currency code |
|---|---|---|
| USDT | Ethereum | USDTERC |
| USDT | Tron | USDTTRX |
| USDC | Arbitrum | USDCARB |
| USDC | Solana | USDCSOL |
| ETH | Arbitrum | ETHARB |
The suffix scheme is not a fixed algorithm you can derive client-side. Always enumerate the authoritative list from GET /currency/ — each entry carries code, network, and contract_address — instead of constructing codes like USDT + ERC by string concatenation.
common_symbol on the currency object gives the widely used external ticker (e.g. Binance mapping) and falls back to the internal code when no mapping exists. Use it for display; use code for API calls.
Three ways to identify a currency in requests
deposit_currency / withdraw_currency in POST /orders/ accept three formats:
{ "deposit_currency": "USDTERC" }
{ "deposit_currency": { "code": "USDT", "network": "ETH" } }
{ "deposit_currency": { "contract_address": "0xdAC17F958D2ee523a2206206994597C13D831ec7", "network": "ETH" } }
The contract-address form is the most precise for tokens — it resolves to the exact asset on the given chain. A null or empty contract_address resolves to the network's main (native) currency.
GET /rate/ supports the same identification via from/to + from_network/to_network, or from_contract_address/to_contract_address + the matching *_network parameter.
Whatever request format you use, responses always return flat string codes ("USDCARB", "ETHARB"). Map them back through GET /currency/ if you need network/contract details.
Networks
GET /network/ lists supported networks. Each entry has:
network— the network name,native_currency— the code of the network's main currency (nullif none is configured).
Network identifiers appear in two forms in the API: short codes in currency objects and order requests (ETH, ARB, TRX, BSC), and display names on the network endpoint. Treat the values returned by GET /network/ and the network field of GET /currency/ as authoritative — do not hardcode a network list.
Extra IDs (memo / destination tag)
Some chains require a secondary identifier alongside the address (Stellar/XLM memo, XRP destination tag, TON comment, …). The currency object's extra_id field names the type of identifier the currency needs (memo, destination_tag, …) or is null.
Where extra IDs appear in the order model:
| Field | Direction | Set by | Purpose |
|---|---|---|---|
deposit_address_extra_id | inbound | Nexchange (response) | Include it when sending your deposit — funds sent without it can be delayed or lost |
withdraw_address_extra_id | outbound | you (request, max 127 chars) | Attached to the withdrawal we send you |
refund_address_extra_id | refund | you (request, max 127 chars) | Attached to refund transactions if the order is refunded |
The fields are withdraw_address_extra_id and refund_address_extra_id. Older documentation revisions used withdraw_extra_id / refund_extra_id — those names are not part of the v2 contract.
Confirmations
min_confirmations on the currency object is the number of on-chain confirmations required before a deposit in that currency is credited (null for fiat). Order completion also depends on the withdrawal transaction confirming on the destination chain — see Order Lifecycle.