Supported Network

Overview

What it means in plain English

A supported network is a blockchain network that a wallet, exchange, payment provider, or application has explicitly enabled for a particular asset and operation. Support can differ for deposits, payments, withdrawals, refunds, tokens, or APIs and can change over time. A technically valid blockchain address does not prove provider support, so integrations should retrieve current network and currency configuration before creating or crediting transfers.

How it works and why it matters

A Supported Network is a provider-specific operational designation, not a statement that the blockchain merely exists. The provider must have address handling, transaction monitoring, fee management, confirmation logic, liquidity, and operational procedures for the network and the requested asset.

Support can be asymmetric. A platform may accept deposits on a network but pause withdrawals, support a native asset but not every token, or expose payments without enabling static addresses. Integrations should check the exact product capability rather than infer support from a general marketing list.

OxaPay exposes supported networks and currencies through API endpoints. Applications should retrieve these values dynamically and store the returned network identifier with each payment. Hard-coded lists can become stale when a network is added, temporarily disabled, renamed, or assigned new withdrawal conditions.

Network selection must occur before validating the Address Format. Similar-looking addresses can exist on several EVM-compatible chains, while a token ticker can represent different contracts. The payment request should bind asset, contract when applicable, network, destination, and any memo or tag.

Support also requires a defined Finality Policy and business handling for congestion, delayed indexing, refunds, and wrong-network payments. A network that is generally available can still enter maintenance or degraded status. The current provider API and system-status controls remain the authoritative operational source.

User interfaces should present only combinations that the provider can actually process. Allowing a customer to select an unsupported network and then rejecting the transfer after broadcast creates irreversible loss risk. Validation should happen before showing the destination or generating the payment request.

Worked example

An invoice accepts USDT on TRON but not the ERC-20 version on Ethereum. Even though both assets use the USDT label, the receiver's configured network determines which deposit is recognized. The customer must match the chain as well as the currency.

Practical checks and common confusion

A supported coin is not equivalent to support for every chain that carries a token with that ticker. Check chain ID, token contract, address format and required memo or tag. Never assume an unsupported-network transfer can be recovered.

Learn the related concepts

Peer-to-Peer Network Segregated Witness (SegWit)