If you are sending an asset to a deposit address that requires a memo, destination tag, or payment ID, you need to provide both the address and the exact identifier the receiving service assigned you. The address routes the transaction on-chain; the memo usually tells the recipient’s internal accounting system which customer or deposit to credit.
That distinction matters when a transfer also crosses chains or swaps assets. A service such as acrossbridge can move or swap assets across networks in one flow, but the destination network’s memo requirement still has to be handled on the final payment. Confirm that the route supports passing the required destination identifier before relying on it for a deposit.
The memo identifies your deposit inside a shared account
A memo is transaction metadata used by the recipient to associate a payment with an account or purpose. It does not necessarily change which on-chain address receives the funds. Services that pool customer deposits can reuse one address and distinguish customers by memo, which saves them from maintaining a separate on-chain account for every user.
Think of the address as the building and the memo as the apartment number: the building can receive the delivery without the apartment number, but the recipient may not know where to put it. The analogy has a limit: some chains or recipient settings reject a payment with a missing required field, while others accept the transfer and leave the recipient to resolve it manually.
The field’s name and encoding depend on the destination network and service. Common examples include:
- XRP Ledger destination tag: a 32-bit unsigned integer, often used to credit a customer at a shared exchange address.
- Stellar memo: can be a 64-bit integer ID, text of up to 28 bytes, or other defined memo type.
- Other network or service identifiers: may be labeled memo, payment ID, or reference; use the exact type and value shown by the recipient.
- Encoded address: some address formats, such as an XRP Ledger X-address, package the destination tag with the address.
The destination transaction must carry the right field
A cross-chain transfer does not automatically preserve a memo just because you entered text somewhere in the flow. The bridge or swap route must take the destination identifier as an input and include it in the transaction it submits on the destination network. The source-chain transaction, bridge message, and destination payout are separate parts of the process; metadata attached to one does not imply that the final payout contains it.
For a typical routed transfer, the service first receives or locks the source asset, then settles the route and submits a destination-chain transaction. That final transaction must encode the recipient address and the memo in the destination chain’s expected fields. In a contract-based cross-chain messaging design, data can travel with a token transfer, but the destination receiver still has to interpret and use that data; Chainlink CCIP’s receiver specification, for example, describes a message payload separately from its destination token amounts.
So before sending, check whether the destination account explicitly requires an identifier, whether the displayed address already encodes it, and whether the route can carry it through to the final transaction. Do not assume that a source-chain memo, a swap quote reference, or a transaction note will be forwarded as the recipient’s deposit memo.
Match the identifier exactly before submitting
Copy the memo from the receiving service’s deposit instructions for the same asset and network you intend to use. Preserve its type and value: a numeric tag must remain the stated integer, while text should retain the exact characters and avoid added spaces, labels, or punctuation.
For example, if an XRP Ledger deposit page gives you a shared address and destination tag 4815162342, the destination payment needs that tag as a UInt32 field. The XRP Ledger documentation explains that tags identify the beneficiary in the recipient’s off-ledger system; the ledger does not know whether your chosen tag maps to your customer account. A valid address with a missing or incorrect tag can therefore reach the shared address without being credited correctly.
On Stellar, check whether the recipient expects a memo ID or memo text. The Stellar Development Foundation documents the memo types and their limits, and also describes muxed accounts, which can encode an account ID in the destination address instead. Use the format the receiving service provided: an encoded address and a separate memo are not interchangeable unless the recipient says they are.
Know what can go wrong after the transfer
A missing or incorrect memo has different outcomes depending on the destination. On the XRP Ledger, an account can require a destination tag so that payments without one are rejected; without that setting, a payment may still settle to the shared address and need manual review. A mismatch may also be accepted on-chain but credited to another internal record, so confirmation on an explorer does not prove the deposit was assigned to you.
If the route cannot carry the required field, do not substitute a random value or send to the pooled address without it. Choose a route that can deliver the field, or use a destination address that the recipient confirms does not need it. If a transfer has already settled with a missing or wrong memo, keep the source transaction hash, destination transaction hash, asset, amount, network, and intended memo; the recipient’s accounting system, rather than the bridge, controls how an unassigned deposit is reconciled.
In your place, I would verify the destination network and memo type first, then make a small test transfer when the amount justifies the extra transaction cost. I would only send the full amount after the recipient credits that test correctly.
Top comments (0)