Stablecoin wallet addresses, memos, and tags: what to check before sending

A stablecoin payment instruction can require more than a token symbol and a wallet address. The asset version, network, destination account, and any required memo or tag must fit together.

A mistake in one field can leave a transfer visible on a blockchain but absent from the recipient’s account. A familiar-looking address can also belong to the wrong person or exist on a network the receiving service does not support.

This guide explains the checks. It does not establish that any particular asset or network is available to an Ostro customer; use the options and exact instructions shown in your workspace.

Treat the instruction as a complete set

Record the intended recipient, token, network, address, and any additional routing identifier. Include the amount, who bears fees, and the purpose or invoice reference in your business records.

The same token symbol can appear on several networks. A service that accepts an asset on one network may not accept it on another. Support can also depend on the precise asset version, account, region, and transaction type.

Do not combine an address from one set of instructions with a network selected from a different conversation. Ask the recipient to supply a complete, current instruction from the receiving service.

Understand the different identifiers

Identifier	What it identifies	What it does not prove
Token name or symbol	A shorthand label for an asset	Authenticity or support on every network
Network	The blockchain used for the transfer	That the recipient accepts the asset there
Destination address	An on-chain destination	The recipient’s identity or deposit eligibility
Token contract or asset identifier	The particular asset implementation	Your customer’s receiving address
Memo or tag	Extra allocation information where required	A substitute for the correct address and network

For network selection, see stablecoin networks explained. For the difference between common token issuers, see USDC versus USDT.

Do not send to the token contract address

A token contract address identifies an asset’s implementation on a relevant network. It is not normally the address a customer gives you to receive their payment. Confusing the two can cause a loss.

Use issuer documentation to verify the asset, and the recipient’s verified instructions to identify the destination. Those are separate checks. Circle’s USDC contract-address documentation is an example of an issuer source for asset identification, not a list of personal receiving accounts.

Never assume a search-engine result for “USDC address” is the place to send funds. The question needs both an asset and a verified recipient.

Know why some deposits require a memo

A custodial service may use a shared blockchain address while assigning an additional identifier to each customer. The memo or tag tells its internal system which customer should receive the credit.

Stellar’s explanation of memo-less payments describes this allocation model for exchange deposits. Omitting the required memo can leave a payment at the shared address without automatically identifying the intended customer.

Not every network, wallet, or deposit uses a memo. Do not invent one. Copy the exact required value and type from the current receiving instructions, and confirm whether the sending service can transmit it correctly.

Separate a routing memo from an invoice reference

A required deposit memo may be an exact technical value. Replacing it with “Invoice 204” can break allocation. Adding extra words can also change the expected value.

Keep the commercial invoice reference in your business records or in an additional supported field when the service permits it. If there is only one required memo field, use it as instructed by the receiving service rather than assuming it is free-form bookkeeping text.

For bank transfers, similar care applies to required payment references. The general principle is explained in payment references and reconciliation.

Verify the full address through a trusted channel

Do not rely only on the first and last few characters. Address-poisoning attacks use lookalike addresses in transaction history to encourage a mistaken copy and paste. MetaMask’s explanation describes this risk and the importance of checking the destination carefully.

Obtain the address through the recipient’s established channel or authenticated receiving instructions. Compare the entire value, including after pasting it into the sending interface. A saved address should record the network and intended recipient as well as a friendly nickname.

If the details changed unexpectedly, verify the change independently before sending. A conversation that previously contained legitimate instructions can still be compromised later.

Treat QR codes as data, not proof of identity

A QR code reduces manual typing, but it does not prove that the destination is genuine. It may also encode information beyond the address, depending on the format and wallet.

After scanning, inspect the decoded destination and any amount or network information shown by the sending service. Compare it with the verified instruction. Do not approve a transaction merely because scanning produced a valid-looking screen.

Keep the same checks for copied text, QR codes, and saved contacts. Convenience changes how data is entered, not the responsibility to verify what is being authorised.

Check deposit conditions before a test

Some services apply minimum amounts, confirmation requirements, or asset-specific restrictions. A test below a required minimum may not be credited even if the route is otherwise supported.

Where appropriate, permitted, and supported, a small test can help confirm that the intended recipient receives an eligible transfer. It does not guarantee a larger transaction will pass every review, limit, or availability condition.

Never split transfers to evade review or limits. A test should be an operational check, followed by confirmation that the recipient can see and use the funds under the receiving service’s rules.

Plan for fees and the recipient’s next action

A transfer can involve a sending fee, network cost, receiving-provider cost, or later conversion and payout cost. Confirm whether the amount entered is the amount sent or the amount expected to arrive.

For self-custodial wallets, moving an asset later can require network-specific fee resources. A balance in a stablecoin does not always mean the wallet can immediately make another transfer without satisfying those requirements.

If the recipient ultimately needs a bank payout, verify that separate route before sending. Stablecoin on-ramps and off-ramps explains why blockchain receipt and fiat availability are different endpoints.

Preserve the transaction evidence

After sending, save the asset, network, amount, destination, required memo, transaction hash, timestamp, and provider reference. Keep the invoice or payment purpose linked to these records.

A transaction hash identifies an on-chain transaction on its network. It does not, by itself, establish that a custodial service credited the correct customer. Confirm the recipient’s account credit separately where that is the intended outcome.

If a memo was omitted or a network is wrong, stop further transfers and follow the wrong-network and unsupported-transfer guide. Recovery is not guaranteed.

Use support without exposing secrets

Support may need transaction identifiers and destination information. It should not need your wallet recovery phrase, private key, password, or one-time login code to locate a payment.

Open support from the provider’s known website or authenticated app. Do not follow unsolicited recovery messages, install remote-access software for an unknown helper, or sign a transaction you do not understand to “verify” a missing deposit.

Keep any recovery discussion linked to an official case reference. A legitimate-looking logo in a message is not evidence that the sender represents the provider.

Frequently asked questions

Does the same address mean the same network?

No. Some networks use compatible address formats, and an address can look identical across them. The receiving service must explicitly support the selected asset and network.

Is a memo always required for stablecoins?

No. It depends on the destination and its instructions. Include it exactly when required; do not infer the requirement from the token symbol alone.

Can I put the invoice number in the memo?

Only if the instructions allow it. A required deposit-allocation memo must not be replaced with your own reference. Store the invoice link separately if necessary.

Can support always fix a missing memo?

No. The receiving provider may have an investigation process, but eligibility, evidence, fees, and technical limitations vary. Confirm the outcome through its official support channel.