Stellar Addresses - Muxed accounts and memos

Last updated: July 31, 2026

Stellar's address model is fundamentally different from EVM or UTXO chains. Understanding it is a prerequisite for integrating Stellar on rhino.fi.

To start integrating Stellar, see our docs on Interacting with Stellar

Background: why Stellar uses memos

Stellar accounts are expensive to create — each requires a minimum XLM reserve to activate. It is therefore common practice (and a protocol-level feature) to route multiple users through a single shared account, differentiating them with a memo. This approach has been used by CEXes for years is a robust, protocol native way of differentiating deposits.

A memo is a field attached to a Stellar transaction. rhino.fi uses the MEMO_ID type: a 64-bit unsigned integer. When you send funds via rhino.fi on Stellar, you must include the correct memo ID or the funds cannot be attributed to your user.

Two ways to express the same deposit address

Every rhino.fi Stellar deposit address can be expressed in two equivalent forms:

1. Muxed address (M…)

A single string that encodes both the pool address and the memo ID. This is the primary format used throughout the rhino.fi API.

MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAABUTGI4

2. Base account + memo ID

The underlying pool address (G…) paired with a numeric memo ID. Some wallets and exchanges only support this form.

Base address:  GAGPNUMMR6FQILPKTCP4TETJWC7DAYAGOIZAPHA63IOBTUHT2MMLYQD6
Memo ID:       2127127031

Both forms refer to the same destination. The muxed address is derived deterministically from the base address and memo ID — they are interchangeable.

Note: The G… base address is rhino.fi's hotwallet address — it is identical across every SDA and carries no per-user information. The memo ID is what uniquely identifies a user or SDA within that pool. Clients should never use the baseAddress to identify an SDA — it is exposed in chainMetadata purely for display purposes (e.g. for wallets that require base account + memo rather than a muxed address).

How rhino.fi exposes both forms

Wherever a Stellar address appears in the API, rhino.fi provides it as a muxed address (M…) in the primary response field. The depositAddress is always an M address — without exception. The underlying base address and memo ID are available in the SDA generation response in a chainMetadata object:

"chainMetadata": {
  "_tag": "STELLAR",
  "baseAddress": "GAGPNUMMR6FQILPKTCP4TETJWC7DAYAGOIZAPHA63IOBTUHT2MMLYQD6",
  "memoId": "2127127031"
}

Field

Description

_tag

Always STELLAR — use this to identify Stellar-specific metadata

baseAddress

rhino.fi's hotwallet address in base account (G…) format. This is the same value for every SDA — it is not a per-user identifier

memoId

The user's numeric memo ID (string-encoded integer)

Use chainMetadata when displaying addresses to end users who need the base + memo format, or when constructing transactions in wallets that don't support muxed addresses natively.

SDK vs API

If you are working directly with the API, you must always supply and accept muxed addresses. The SDK simplifies the conversion and returns the base address + memo ID combination.

We strongly recommend using the SDK for Stellar integrations to avoid memo-handling errors. A missing or incorrect memo means funds cannot be credited to the correct user automatically.