Before sending a Stellar deposit to an M-address, confirm that the sending app preserves the muxed destination and the receiving service supports that format for your deposit. The M-address combines an underlying G-account with an identifier; discarding that identifier can lose the customer-routing information. Use a G-address and memo alternative only when the receiver explicitly supplies or documents it.
Recognize what an M-address represents
Stellar's muxed-account FAQ describes a virtual account identified beneath an underlying Stellar account. The address contains the base account and an identifier used for purposes such as mapping a pooled deposit to a customer. It is not automatically a separate funded onchain account with a separate set of keys. A service still needs to associate the identifier with its own customer or invoice record.
The SEP-23 specification defines the address representation. Standard G-addresses and muxed M-addresses have different encodings, not a prefix you can freely exchange. A normal G-address has 56 characters and an M-address 69 under that specification. Length and checksum validation help identify a format, but they do not establish that the receiver accepts your deposit or recognizes the embedded identifier.
Three compatibility checks before the payment
| Check | Question to answer | Evidence worth retaining | Failure to avoid |
|---|---|---|---|
| Sending application | Will it send to the full muxed destination? | Its documented support and final destination review | An app strips the identifier or rejects M-addresses |
| Protocol representation | Does the destination encode the intended account and ID? | Trusted SDK or wallet interpretation | Manual prefix edits or an invented identifier |
| Receiving service | Does this deposit workflow recognize that muxed destination? | Current instructions for your customer or order | The network receives funds but the internal mapping is missing |
| Fallback, if needed | Did the receiver provide a G-address and exact memo alternative? | That explicit instruction and memo type | Assuming any decoded ID is automatically the expected memo |
| Asset and network | Is the selected asset supported for this destination? | The current deposit screen | Treating address-format support as acceptance of every Stellar token |
Protocol capability and a product's support are separate. A service can use traditional G-address deposits with a memo even while another uses muxed destinations. The official FAQ explains that the older method can continue to function. Do not conclude that a G-address workflow is obsolete, or that a sender accepting the M string guarantees the receiving service will credit every possible muxed identifier.
Why converting to the base account can change the payment evidence
Imagine a fictional pooled account P serving customers identified as 41 and 42. Their muxed destinations share the underlying account but carry different IDs. Sending to P alone removes that distinction from the chosen destination. The base account may be correct while the receiving service no longer has the routing data expected for the particular customer. Reaching the pool is not the same evidence as crediting the intended internal balance.
Do not create your own ID because the encoding permits one. A valid encoded number does not register a customer in the service's database. Likewise, do not assume that copying a decoded identifier into a text memo reproduces every product's documented deposit flow. The receiver must define the accepted alternative and its type. Keep any support clarification with the order before sending rather than attempting a conversion based on a generic tutorial.
There are services that explicitly document both forms. For example, this receiving-service guide describes its own M-address and base-account-plus-memo-ID representations. That is evidence of its workflow, not a rule imposed on every exchange. The Stellar SDK reference provides structured parsing for developers; manually shortening an address is not equivalent to parsing it correctly.
If the sending form accepts only G-addresses
Stop before changing the destination. Check whether the sender has a supported update or whether the recipient supplies a verified alternative. If neither route is available, ask the relevant official support channels how to proceed. Do not send to a guessed base address and promise yourself that a ticket will fix the deposit later. A software limitation is a reason to resolve compatibility first, not proof that an improvised payment will be recoverable.
If the receiver gives a G-address plus memo, preserve the complete address, exact memo and required memo type as one instruction set. Do not silently drop a memo because another guide says muxed addresses eliminate them. That guide may describe an M-address flow rather than the fallback you are using. The LOBSTR receiving guide provides context for reading wallet receiving details, but the current receiver's instructions govern the deposit.
- Open the receiver's deposit instructions through an official channel and identify the asset and network.
- Copy the full supplied M-address and retain the customer or order reference.
- Verify the sender's muxed-destination support before approving any transaction.
- If an alternative is needed, obtain the receiver's explicit G-address and memo instructions.
- Review the actual destination and any memo at confirmation, preserving the routing information.
- After sending, verify the successful operation and distinguish network receipt from service crediting.
If the deposit has already been sent
Collect the transaction identifier, actual operation destination, original instructions and any memo used. If the transaction contains several operations, identify the one intended for this payment rather than relying only on the transaction's headline. Describe whether the M-address was preserved, converted through a documented fallback or replaced without the identifier. That distinction helps support investigate the correct routing issue.
Do not send another amount as an alleged unlocking fee or assume that a second transfer will label the first one. Recovery and crediting depend on the receiver's control and records, and no universal outcome is promised. If the base destination itself did not exist or another asset requirement failed, that is a different diagnosis; our destination-account guide covers that separate error.
Keep the current order's format intact
For a no-account swap, use the deposit asset, network and destination format shown by the current order. This article does not establish that every service or route accepts muxed accounts. The practical rule is to preserve the receiver's routing information and verify both ends' support before payment. A correctly encoded address is one requirement; a correctly attributed deposit needs the receiving workflow too.
FAQ
What is a Stellar muxed address?
It represents an underlying Stellar account together with an identifier for a virtual account or routing purpose. The receiving service must recognize how that identifier maps to its records.
Do Stellar muxed accounts remove every memo requirement?
They can embed routing information in the destination, but a receiver's actual workflow still matters. Do not discard a requested memo or improvise a fallback without checking its instructions.
Can I use a Stellar memo ID with the G-address instead?
Only use that alternative when the receiver explicitly supplies or documents it. Its exact address, memo value and memo type need to match the accepted flow.