Supported addresses and memos

Resolve a Soran name to get its destination address and memo together. The address can be a classic Stellar G... account, a muxed M... destination or a Soroban C... contract. G accounts can optionally include an ID, text or hash memo. M and C destinations use memo: { type: "none" }. Keep the complete instruction when building a payment. Your wallet or transfer flow must support both the address type and its routing requirements.

These examples use Lookup SDK 0.11.0 and Holder SDK 0.10.0 on the current testnet deployment. The same payment instructions are available through the contract methods, HTTP API and app. See release status for addresses and versions.

Support at a glance

Destination	Current Soran support	Payment handling
Classic `G...`, without a memo	Yes	Return `memo: { type: "none" }`; a classic payment can use the G address
Classic `G...` with an ID memo	Yes	For a classic payment, include the exact unsigned 64-bit ID as a transaction memo
Classic `G...` with a text memo	Yes	For a classic payment, include the exact 1–28 UTF-8 bytes as a transaction memo
Classic `G...` with a hash memo	Yes	For a classic payment, include the exact 32 bytes as a transaction hash memo
Soroban contract `C...`	Yes, with `none` only	Use the supported Soroban asset/token transfer flow, not a classic Payment operation
Muxed `M...`	Yes, with `none` only	Use the full M address as a supported payment destination; preserve its embedded ID

none means the record publishes no separate memo. Check any memo requirement imposed by the recipient account too. Soran does not support return-hash memos or arbitrary contract routing arguments. Soroban transfers cannot use the classic transaction memo field. A contract-account sender may be able to carry a numeric ID through muxed transfer support if the receiver supports that route. It cannot silently drop or convert text and hash memos. Stop when the selected flow cannot carry the instruction. See Stellar’s contract-account payment guide.

Example destinations

For names you can resolve now, use the live testnet examples. They include all six destination forms and a hello-world contract you can call through its name. The values below are illustrative, validly encoded examples. The names are not promised to exist, and the contract address is synthetic. Do not send funds to them.

Classic account without a memo

An ordinary alice.nova payment could resolve to:

{
  "address": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
  "memo": { "type": "none" }
}

The holder can publish an ordinary G account without adding a memo.

Classic account with an ID memo

An exchange deposit name such as customer420.nova could resolve to:

{
  "address": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
  "memo": { "type": "id", "value": "420" }
}

The wallet sends to that G account with Memo ID 420. The memo type matters: text "420" is a different instruction. IDs range from 0 to 18446744073709551615; preserve them as decimal strings, with no leading zeroes except "0". Use the account and customer memo supplied by the exchange. Soran keeps them together so your wallet can include both in the payment.

Classic account with a text memo

{
  "address": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
  "memo": { "type": "text", "value": "customer-420" }
}

Preserve case, spaces and exact UTF-8 bytes. The limit is 28 bytes, not 28 characters. An empty text memo is invalid; use none to remove a memo explicitly.

Classic account with a hash memo

{
  "address": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
  "memo": {
    "type": "hash",
    "value": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
  }
}

This is a 32-byte memo encoded as 64 lowercase hexadecimal characters in the SDK and JSON. Convert those hex bytes to the transaction’s hash-memo representation; do not send the 64-character string as a text memo or hash it again.

Contract address

{
  "address": "CADQOBYHA4DQOBYHA4DQOBYHA4DQOBYHA4DQOBYHA4DQOBYHA4DQP5KR",
  "memo": { "type": "none" }
}

Use a supported Soroban transfer flow for a contract recipient. The result does not specify an asset, amount, method or extra routing arguments. Check that the contract supports the intended receiving flow.

Muxed accounts: what is and is not supported

A muxed M... address packages a base G account with a 64-bit identifier. For example:

M address: MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAABUTGI4
G account: GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ
Muxed ID:  420

Stellar supports muxed destinations on selected operations, including classic payments. The muxed ID belongs to the operation’s destination; a classic memo belongs to the transaction. They are different representations, even when their numbers match. See Stellar’s muxed-account guide. Soran accepts the full M address. Its Resolver stores the base G account and ID together, and the SDK returns the complete M address:

{
  "address": "MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAABUTGI4",
  "memo": { "type": "none" }
}

Here none means no separate transaction memo. The embedded muxed ID 420 is still required and remains part of the M address. Send to that complete address using a compatible payment flow. Do not substitute the base G address or Memo ID 420. Soran rejects an M address with a separate memo, an invalid encoding or an out-of-range ID. Muxed IDs range from 0 to 18446744073709551615; preserve them as exact decimal strings or bigint values. You can inspect an M address with Stellar SDK 17 without submitting a transaction:

import { MuxedAccount } from "@stellar/stellar-sdk";

const muxed = MuxedAccount.fromAddress(
  "MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAABUTGI4",
  "0",
);
const baseAddress = muxed.baseAccount().accountId();
const muxedId = muxed.id(); // "420", kept as a decimal string
// Keep the full M address for payment; the base address is for account inspection.

Each complete M address can have its own reverse and Primary name. Lookup never falls back to the base G account or another ID. G/C elections instead identify the account without distinguishing customer memos. M elections require Lookup SDK 0.11.0, Holder SDK 0.10.0 and muxed_identity_version() == 1. The base G account authorizes an M election. For an exchange-controlled account, the exchange signs. A customer M address does not give its user signing authority or separate name ownership. Changing a name’s destination can invalidate an earlier election.

Publish and read the whole instruction

With a configured Holder SDK, the name’s holder can publish the recipient-approved destination:

await me.setPayment("customer420.nova", {
  address: "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
  memo: { type: "id", value: "420" },
});

For a muxed destination, use the same Holder method with the full M address:

await me.setPayment("customer420.nova", {
  address: "MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAABUTGI4",
  memo: { type: "none" },
});

The Holder SDK validates the M address and submits its base G account and ID to set_muxed. The native Resolver stores the address and routing information atomically. Universal Lookup reads that on-chain instruction. For payments, use resolve_destination on chain, resolvePayment in the SDK, or HTTP /v1/payment/{namespace}/{label}. These return the complete instruction. Older contract resolve_payment and address-only methods, plus HTTP /v1/resolve, reject muxed records. Updated SDK resolve/record/verify helpers preserve full M addresses, but address-only lookup fails when a separate memo is required. An unavailable read or unknown legacy memo capability must never become a memo-free result. A classic transaction has one memo, so payments with different required memos need separate transactions. Recheck the complete instruction before confirmation. See payment integration for the next step.

​Support at a glance

​Example destinations

​Classic account without a memo

​Classic account with an ID memo

​Classic account with a text memo

​Classic account with a hash memo

​Contract address

​Muxed accounts: what is and is not supported

​Publish and read the whole instruction

Support at a glance

Example destinations

Classic account without a memo

Classic account with an ID memo

Classic account with a text memo

Classic account with a hash memo

Contract address

Muxed accounts: what is and is not supported

Publish and read the whole instruction