Why a Stellar M… address maps to a G… account
Last updated:
At a glance
| Property | Value |
|---|---|
| Muxed address | Starts with M; a G… account plus a 64-bit ID |
| On the ledger | Only the underlying G account exists |
| Protocol | CAP-27 (Protocol 13); string form in SEP-23 |
What you see
A customer was given an M… deposit address, but looking up that address as an account finds nothing, and the payment shows up under a G… account shared by many customers.
Why this happens
Stellar's documentation says muxed accounts "combine the familiar GABC… address with a 64-bit integer ID" and that they "do not exist on the ledger, but their shared underlying GABC… account does". The same base account with different IDs gives different M addresses. Muxed accounts are defined by CAP-27, introduced in Protocol 13, and their string form by SEP-23. Balances, sequence numbers and account lookups all belong to the G account; the ID only travels with the operation.
What to do
- Look up balances and history on the underlying G account, never on the M address.
- Decode the M address (SEP-23) to get the G account and the 64-bit ID, and route the payment by that ID.
- Store the ID as a 64-bit integer; it is not a memo field.
When this is not our problem
Muxed accounts are a Stellar protocol feature (CAP-27, SEP-23) and behave the same on every Horizon server, whoever operates it, Triport included.
FAQ
- Is a Stellar M address a separate account?
- No. It is the underlying G account plus a 64-bit ID; only the G account exists on the ledger.
- How do I credit the right customer for a muxed payment?
- Decode the M address to get its 64-bit ID and use the ID to route the payment on your side.