Stablecoin networks explained: choosing the right asset and destination

“Send USDC to this address” can be incomplete payment instructions.

Which network? Which version of the token? Does the receiving service support it? Is an additional memo required? Who pays the network fee, and what happens after the transaction is confirmed?

A stablecoin transfer is compatible only when the asset, network, destination, and service requirements line up. A familiar token name or correctly formatted address is not enough to establish that compatibility.

This guide explains the parts of the instruction and a practical checking process. It describes general network concepts, not a promise that every asset or network is available through Ostro or any other provider.

Before authorising a transfer, check wallet addresses, memos, and tags. If a payment has already used an unsupported route, follow the wrong-network investigation guide.

Separate the asset from the network

The asset is what you are transferring, such as a specific stablecoin. The network is the blockchain system on which that particular transfer occurs.

The same asset family can have implementations on multiple networks. Those balances and transactions exist in different environments; they are not automatically interchangeable because the ticker looks the same.

Examples of network names a user may encounter include Ethereum, Solana, Polygon, Arbitrum, Base, Tron, and Stellar. This list does not mean that every stablecoin is issued on every network or that your provider supports every combination.

Start with the options explicitly offered by the sending and receiving services for the relevant asset. Then verify the current issuer information when identifying the token implementation.

Understand the fields in a complete instruction

Field	What it identifies	Common mistake
Asset	The exact token being transferred	Treating USDC and USDT as interchangeable
Network	The environment carrying the transfer	Choosing a cheaper network the recipient does not support
Token contract or equivalent identifier	The particular asset implementation where applicable	Trusting a symbol used by a different token
Destination address	The receiving account or wallet on that network	Assuming address format proves compatibility
Memo, tag, or other routing field	Additional allocation information where required	Omitting it because the address looks complete
Amount and fee treatment	What is sent and what the recipient should receive	Assuming fees are always charged separately

A token contract address identifies a token implementation. It is generally not the customer’s deposit address. Do not send a payment to a contract address copied from an issuer registry as if it were the recipient’s wallet.

Keep these fields together when verifying a commercial payment. Changing one can change the entire route.

Check native and bridged token versions

A native token is issued under the issuer’s supported arrangement on the relevant network. A bridged or wrapped representation may depend on additional infrastructure that moves or represents value from another environment.

The names can be confusingly similar. A destination supporting one implementation may not credit another, even if both are displayed with a familiar ticker in a wallet.

Circle publishes network-specific USDC contract information, including separate production and testing references. Use the current official registry to identify the asset, then follow your provider’s supported deposit instructions. Circle: USDC contract addresses.

For USDT, check Tether’s current protocol information and distinguish supported arrangements from historical or deprecated entries. Tether: Supported protocols.

An address format does not prove network support

Some networks use similar address formats. The same visible address can therefore appear in more than one environment without the receiving service supporting deposits on all of them.

A form accepting the address’s syntax means only that it passed that form’s validation. It does not establish the recipient’s asset support, provider crediting policy, or control of the corresponding destination on another network.

Use the network name shown in the recipient’s current deposit instructions. If the sender does not offer that exact compatible route, obtain another supported destination or use a different permitted payment method.

Do not send first and assume support can move the funds to the intended network afterwards. Recovery may be unavailable or dependent on another party’s control and policies.

Respect memos and tags when required

Some receiving services use a shared destination plus additional information to allocate deposits to individual users. A memo or tag can therefore be essential even when the blockchain transfer itself reaches the intended account.

Stellar’s documentation and educational material describe this shared-account pattern and the role of memos in identifying a customer’s deposit. Not every Stellar destination needs a separate memo; follow the actual receiving instructions. Stellar: Fixing memo-less payments.

Preserve the required value and type exactly. Do not replace it with your invoice number unless the recipient’s service explicitly instructs you to do so.

Your commercial reference can be kept in your own payment record separately. Technical deposit allocation and invoice identification are related tasks, but they are not always handled by the same field.

Distinguish self-custody from a custodial deposit

With self-custody, the relevant keys or authorisation mechanism control the wallet. With a custodial service, the service manages the account relationship and applies its own deposit-crediting process.

A transaction visible on a network may not yet appear as an available balance at a custodial platform. The platform can have confirmation requirements, supported-asset rules, minimums, or reviews.

A self-custody wallet can also display a token without providing a convenient or permitted way to convert it into local fiat. Receiving is not the same as having a complete spending or payout route.

Choose the destination with the next step in mind. If the recipient needs a bank payout, verify that conversion and withdrawal path before initiating the stablecoin transfer.

Understand network fees and who pays them

Networks charge transaction fees according to their own mechanisms. On Ethereum, gas fees are denominated in ETH. On Solana, transaction fees are paid in SOL by the transaction’s fee payer. Ethereum: Gas and fees and Solana: Fees.

A wallet or service can manage, sponsor, or abstract some fee handling, so the end-user experience depends on the product. Do not assume every user must manually buy a native token for every transfer, or that every provider absorbs the cost.

For self-custody, receiving a stablecoin balance may not give you what is needed to send it onwards. Check the wallet’s requirements for the intended next action.

Also distinguish a service’s withdrawal fee from the underlying network fee. They may be priced differently and should not be represented as the same charge without evidence.

If the journey includes fiat funding or a later bank payout, read stablecoin on-ramps and off-ramps to account for the conversion stages around the network transfer.

Compare networks using the actual payment route

The cheapest quoted network transfer is not necessarily the cheapest usable outcome. The recipient may need to convert the asset, move it again, or pay a separate withdrawal fee.

A useful comparison includes compatibility first, then the total cost and practical destination outcome. If a route is unsupported, its low fee is irrelevant to this payment.

Consider a fictional business choosing between two compatible routes. Route A charges three token units for delivery and allows a direct permitted conversion at the destination. Route B charges one unit for delivery but requires another permitted transfer costing four units before conversion. With all other factors equal, Route B’s transfer stages cost five units rather than three.

Real quotes can differ in asset value, fee currency, conversion pricing, and review requirements. Use international payment fees to compare the complete journey consistently.

Read transaction status without overclaiming completion

A provider’s internal payment ID is different from a network transaction hash or signature. The network identifier lets you inspect the relevant transaction through a suitable explorer or other network tools.

Check the correct network, transaction status, asset, amount, and destination. A transaction identifier for another network or another payment does not prove this obligation was satisfied.

Even after network confirmation, the recipient’s service may need to credit the deposit. The commercial agreement and provider’s status definitions determine what evidence is relevant to completion.

Do not promise a fixed number of seconds based only on normal network behaviour. Provider processing, confirmations, reviews, and subsequent fiat payout can change the end-to-end timeline.

Use a careful pre-send checklist

Before sending, confirm the following through the approved receiving instructions:

1. The recipient is legitimate and the payment purpose is permitted.
2. The sending service supports the chosen asset and network.
3. The receiving service supports the same asset implementation and network.
4. The destination is current and has been verified through a trusted channel.
5. Any required memo or tag is included correctly.
6. The amount and fee treatment satisfy the agreement.
7. Minimums, limits, and review requirements are understood.
8. The recipient knows how to access or use the resulting funds.

If a destination has changed, verify the change independently. See payment-fraud prevention.

Where permitted and useful, a small test payment can help check operational compatibility. Respect minimums and fees, and understand that a successful test does not prove identity, guarantee recovery, or pre-approve a later larger payment.

Keep test networks separate from real payments

Developer documentation may list testnet tokens and addresses alongside production information. Test environments are for development and are not interchangeable with real-value payment networks.

Do not use a testnet faucet, token, or destination as receiving instructions for a commercial invoice. Equally, never assume that an address copied from a development example is a valid production destination.

A product being tested in a sandbox can show simulated statuses and balances that do not represent live funds. The sending and receiving services must explicitly support the real production route before money is sent.

This distinction is especially relevant when copying technical documentation into a business process. Documentation examples explain an integration; they are not personalised payment instructions.

What to do after a wrong-network or wrong-asset transfer

Stop further transfers and preserve the exact transaction evidence. Identify the network, asset implementation, amount, destination, hash or signature, sending service, and receiving service.

Contact the relevant provider through its official channel. Recovery depends on the actual route, who controls the destination, technical access, and provider policy. It may be impossible.

Circle’s support guidance warns that completed transfers to an incorrect address or network cannot simply be reversed by support; the available options depend on the circumstances. Circle: Sent USDC to the wrong address or network.

Do not disclose private keys or recovery phrases, and do not trust unsolicited “recovery agents” promising a guaranteed result. Avoid importing keys into an unfamiliar tool as an improvised fix.

Build records that connect the network event to the business payment

Keep the invoice or commercial reference, asset, network, amount, fees, destination verification, provider ID, and network transaction identifier. Record any later conversion and bank payout as separate linked events.

For businesses using a shared operational wallet, define who can authorise payments and how access is recovered. Do not assume a wallet display provides a complete accounting or approval system.

The USDC versus USDT guide covers issuer and conversion considerations. The reconciliation guide explains how the technical record fits into the commercial ledger.

Frequently asked questions

Can I use the same address on every network?

Do not assume so. Address appearance does not establish receiving support or access on another network. Follow the exact network-specific instructions.

Does a wallet showing a token mean the deposit is supported?

Not necessarily. A wallet interface displaying an asset differs from a custodial service accepting and crediting it under its deposit rules.

Should I choose the network with the smallest fee?

Only among routes that both sides support and permit. Compare the full path to the recipient’s intended outcome, including later transfers and conversion.

Can support reverse a completed blockchain transfer?

Generally, there is no ordinary bank-style reversal button for a completed on-chain transfer. Any recovery depends on the destination, network, service, and circumstances; it is not guaranteed.