[CassioMG]

TL;DR

A Soroban transfer (a custom token or a collectible) can't carry a transaction memo. The only id it can carry is the one inside a muxed M… destination. When the app couldn't build the destination the user entered, it built a different one without saying so: an M whose token or collection doesn't support muxed addresses went to its base G without the id, and a memo that couldn't become an M's id was dropped. The app now refuses those sends, so nothing is built or signed.

A memo the transfer can't carry is now caught before anything is built: both send screens show a "Memo not supported" banner and keep Continue (Review, for a collectible) off, the way #1036 blocks an M or W the token can't take. The banner opens a sheet that says why. Saving such a memo from the review sheet's Settings closes the review and throws away the transaction built before, so it can't be confirmed under the new memo. The build-time refusal stays as the backstop.

Sends that work today are unchanged: a G without a memo, a G with a numeric memo the contract can take (it still becomes an M), an M the contract supports, W and C recipients, and classic payments.

Merge order: stacked on #1036 (send to W); it merges right after it.

Changed lines

	Files	Added	Removed	Share of changed lines
Source code	8	515	147	37%
Tests	7	1,049	64	63%
Total	15	1,564	211

Source code is the app code under src/, translations included. Tests are the unit tests.

Screenshots and Videos

Both send screens now block a memo the transfer can't carry before anything is built, the way #1036's "Muxed address not supported" banner blocks an M or W: a "Memo not supported" banner, Continue off, and a sheet that says why. The "After" runs are on the iPhone SE simulator (iOS 27.2), with a wallet that holds no TZT, so the amount stays empty.

1. A memo the token can't carry. The memo "hello" is set while sending XLM, then the token is switched to TZT, whose contract the app treats as not supporting muxed addresses.

Before (time-lapse)	Before: Review fails with a generic 400	After (time-lapse)	After: the sheet the banner opens

2. A text memo on a token that supports muxed addresses. A numeric memo folds into an M; text can't. The memo "hello" is set in Settings on a send to a G. Both runs treat TZT as supporting muxed addresses through a local change; before is on Android, after on iOS.

Before (time-lapse)	Before: Review fails with a generic 400	After (time-lapse)	After: the sheet the banner opens

Collectible whose build fails

Before (time-lapse)	Before: Review does nothing	After (time-lapse)	After: the error shows

M of a funded account

Before (existing bug on main)	After

Implementation details (for agents)

Links for changes 1 and 2 are permalinks at 22d7846a4d9a56a53f7bd5de5ca9a757d379a957, for change 3 at 70a0d8550f62fb104edd7ceb978804eacc72c566, for change 4 at 86107dfd86ff7b774316f9599c7a69872691834d, and for change 5 at e644629c70f9a2435fb3b17bdcbdb9465fc936b7. The branch has 8 commits on cg-p30-send-w, and merges cg-p30-send-w in to pick up its later commits: 74da9295 for its .yarnrc.yml fix, most recently 64c6fed4.

What changed

1. determineMuxedDestination refuses instead of falling back (4e794d2f):
   

   freighter-mobile/src/helpers/muxedAddress.ts

   Lines 126 to 199 in 22d7846

   	/**
   	* Picks the address a Soroban transfer is sent to, or refuses the transfer.
   	*
   	* A Soroban transaction carries no memo, so the only id a transfer can carry
   	* is the one in a muxed destination. When the recipient or the memo can't
   	* arrive as entered, this throws instead of sending to a different address
   	* or without the memo.
   	*
   	* - A muxed contract (`W...`) is returned unchanged, before anything else: the
   	* mux id is already in the address, so it is never re-encoded, stripped to
   	* its `C...` or rebuilt as an `M...`, and the memo and
   	* `contractSupportsMuxed` are ignored for it.
   	* - An `M...` is returned unchanged when the contract supports muxed
   	* addresses, and refused when it doesn't. A memo for it is refused: the
   	* `M...`'s own id is the only one the transfer can carry.
   	* - Any other recipient without a memo is returned unchanged.
   	* - A `G...` with a memo becomes an `M...` carrying the memo as its id. The
   	* memo is refused when the contract doesn't support muxed addresses, when
   	* the recipient isn't a `G...`, or when the memo isn't a decimal uint64.
   	*
   	* @param params The recipient, the memo, and whether the contract supports muxed
   	* @returns The address to send to
   	* @throws Error with a translated message when the recipient or the memo
   	* can't be carried
   	*/
   	export function determineMuxedDestination(
   	params: DetermineMuxedDestinationParams,
   	): string {
   	const { recipientAddress, transactionMemo, contractSupportsMuxed } = params;
   	// A W already carries its own mux id: pass it through before any G/M logic
   	// can validate, rebuild or unwrap it.
   	if (isMuxedContract(recipientAddress)) {
   	return recipientAddress;
   	}
   	const hasMemo =
   	typeof transactionMemo === "string" && transactionMemo.length > 0;
   	if (isMuxedAccount(recipientAddress)) {
   	if (!contractSupportsMuxed) {
   	throw new Error(translate("transaction.errors.muxedAddressNotSupported"));
   	}
   	if (hasMemo) {
   	throw new Error(
   	translate("transactionSettings.memoInfo.memoDisabledForTransaction"),
   	);
   	}
   	return recipientAddress;
   	}
   	if (!hasMemo) {
   	return recipientAddress;
   	}
   	const isRecipientGAddress =
   	isValidStellarAddress(recipientAddress) && !isContractId(recipientAddress);
   	if (!contractSupportsMuxed || !isRecipientGAddress) {
   	throw new Error(
   	translate("transactionSettings.memoInfo.memoNotSupportedForOperation"),
   	);
   	}
   	const muxedWithMemo = createMuxedAccount(recipientAddress, transactionMemo);
   	if (!muxedWithMemo) {
   	throw new Error(translate("transaction.errors.nonNumericMemoNotSupported"));
   	}
   	return muxedWithMemo;
   	}

   • A W is returned unchanged, as before. buildPaymentTransaction refuses a W with a memo, and buildSendCollectibleTransaction refuses any W, before this runs.
   • An M is returned when the contract supports muxed addresses. Otherwise it throws transaction.errors.muxedAddressNotSupported; before, it returned the base G. A memo for an M throws transactionSettings.memoInfo.memoDisabledForTransaction. Before, the memo was ignored, and a branch that would have replaced the M's id with the memo (unreachable for a real M) is gone.
   • Any other recipient without a memo is returned unchanged.
   • A G with a memo still becomes an M carrying the memo as its id. It throws transactionSettings.memoInfo.memoNotSupportedForOperation when the contract doesn't support muxed addresses or the recipient isn't a G, and transaction.errors.nonNumericMemoNotSupported when the memo isn't a decimal uint64. Before, both returned the plain G and dropped the memo.
   • Both callers already turn a throw into a failed build: "Failed to build payment transaction: …" through buildSorobanTransferOperation, and "Failed to build send collectible transaction: …". Their doc comments now say so.
     

     freighter-mobile/src/services/transactionService.ts

     Lines 374 to 381 in 22d7846

     	* - SAC transfer (Soroban): a custom token, or any contract destination
     	* (`C...` or muxed contract `W...`), becomes a `transfer(from, to, amount)`
     	* call on the token's contract: a custom token's own contract, otherwise the
     	* asset's Stellar Asset Contract (see `getSacContractIdForBalance`). Only the
     	* sender's account is loaded. It carries no transaction memo: when the token
     	* contract supports muxed addresses, a memo for a `G...` becomes the id of
     	* an `M...` destination instead. A memo or an `M...` the transfer can't
     	* carry is refused (see `determineMuxedDestination`).

     
     

     freighter-mobile/src/services/transactionService.ts

     Lines 784 to 800 in 22d7846

     	/**
     	* Builds a collectible transfer transaction: a `transfer(from, to, token_id)`
     	* call on the collection contract. See `determineMuxedDestination` for how a
     	* memo folds into the destination, and when a memo or an `M...` recipient is
     	* refused.
     	*
     	* A muxed contract (`W...`) recipient is refused with
     	* `transaction.errors.muxedContractNotSupported`, before any network call: no
     	* account is loaded and no contract spec is looked up.
     	*
     	* @param params The collection, token id and recipient, the memo, fee and
     	* timeout, and the network and sender
     	* @returns The transaction, its XDR and the final destination
     	* @throws Error `Failed to build send collectible transaction: ...` when a
     	* parameter is missing or invalid, the recipient is a `W...`, the recipient or
     	* memo can't be carried, or building fails
     	*/

   • Two new strings, in en and pt: transaction.errors.muxedAddressNotSupported and transaction.errors.nonNumericMemoNotSupported.
     

     freighter-mobile/src/i18n/locales/en/translations.json

     Lines 1153 to 1154 in 22d7846

     	"muxedAddressNotSupported": "This token does not support muxed address (M-) as a target destination.",
     	"nonNumericMemoNotSupported": "This token only accepts a numeric memo, from 0 to 18446744073709551615."

   • The helper imports i18next's t as translate, because getMemoDisabledState in the same module takes its own t.
2. The collectible screen shows build errors as a toast (22d7846a), as the amount screen does. Every failed build shows it, since a new build clears the error first.
   

   freighter-mobile/src/components/screens/SendScreen/screens/SendCollectibleReview.tsx

   Lines 143 to 157 in 22d7846

   	const { showToast } = useToast();
   	// Show why a build failed, as the amount screen does: otherwise Review just
   	// does nothing. Every failed build shows it, since a new build clears the
   	// error first.
   	useEffect(() => {
   	if (transactionBuilderError) {
   	showToast({
   	variant: "error",
   	title: transactionBuilderError,
   	toastId: "transaction-builder-error",
   	duration: 5000,
   	});
   	}
   	}, [transactionBuilderError, showToast]);

3. An M recipient's funding is looked up through its base G (70a0d855). Horizon answers 400 for /accounts/M…, and getAccount turns any error into null, so the send-recipient store recorded every M as unfunded. That drove the recipient screen's "doesn't exist" notice and, through buildUnfundedContext, the review's expected-to-fail warning, which only appears when Blockaid returns a scan result. Both lookups, for a typed recipient and a picked one, now go through getFundingLookupAddress, which maps an M to its base G and leaves any other address unchanged. C and W destinations are still classified before any lookup, so they never reach it.
   

   freighter-mobile/src/ducks/sendRecipient.ts

   Lines 64 to 74 in 70a0d85

   	/**
   	* The account to look up to learn whether a destination is funded. A muxed
   	* account (`M...`) is its base `G...` plus an id, so it is funded exactly when
   	* its `G...` is; Horizon can't look up the `M...` itself. Any other address is
   	* looked up as is.
   	*
   	* @param address A destination that isn't a contract (`C...` or `W...`)
   	* @returns The address to pass to `getAccount`
   	*/
   	const getFundingLookupAddress = (address: string): string =>
   	getBaseAccount(address) ?? address;

   
   

   freighter-mobile/src/ducks/sendRecipient.ts

   Lines 297 to 302 in 70a0d85

   	} else {
   	const account = await getAccount(
   	getFundingLookupAddress(resolvedAddress),
   	network,
   	);
   	isFunded = !!account;

4. Both send screens block a memo the transfer can't carry, before building anything (86107dfd), from review. Before, such a memo (a federation memo, or one saved while XLM was selected, then a custom token) failed every build: the 300 ms fee estimate threw before the user did anything, and Continue looked dead, because the screen doesn't toast the same error twice.
   • getSorobanMemoRefusal (new) holds the rules: "unsupported" when the recipient isn't a G or the contract doesn't support muxed addresses, and "nonNumeric" when the memo isn't a decimal uint64 of at most 22 digits, the SDK's limit (440de7c1 added the length cap). These are the memos determineMuxedDestination refuses. Unlike createMuxedAccount, it logs nothing, since the screens check every memo the user saves.
   • Amount screen: a memo on a Soroban send to a G takes the same contract lookup as an M, and nothing is built until it answers. A memo for a C is refused without one. isMemoUnsupported joins isRecipientUnsupported in isSendBlocked, which drives the banner (testID memo-not-supported-banner), the disabled Continue, the hidden percentage buttons and prepareTransaction's early return.
   • prepareTransaction also checks the memo it reads from the store, because Settings asks for a rebuild before the screen re-renders with the memo it just saved.
   • Collectible screen: the same, with its own check in prepareTransaction, and the image hidden on small screens while the memo blocks the send.
   • MuxedAddressWarningBottomSheet gets three memo variants, titled "Memo not supported": memo ("This token can't be sent with a memo to this address."), collectibleMemo ("This collectible can't be sent with a memo to this address.") and numericMemo, which reuses transaction.errors.nonNumericMemoNotSupported. 0be6b47d adds a fourth, collectibleNumericMemo ("This collectible only accepts a numeric memo, from 0 to 18446744073709551615."), so the collectible screen doesn't say "token". New strings in en and pt.
5. A memo the transfer can't carry throws away what was built before (e644629c). The review sheet's gear opens Settings, so the memo can change while the review is open. When Settings saved a memo the transfer can't carry, change 4's early return built nothing but left the transaction built for the earlier memo in the store. The review came back showing the new memo, and Confirm signed the old transaction, without that memo or with the earlier mux id. A second save while the memo blocked the send did the same.
   • discardBuiltTransaction resets the built transaction and closes the review sheet, and the same on the collectible screen. Every early return in prepareTransaction calls it, so the screen's banner says why the send is blocked.
   • The review sheet is minimized while Settings is on top: gorhom 5.2.6's default stackBehavior is "switch", and nothing in src/ overrides it. dismiss() on a minimized sheet unmounts it at once, so it isn't restored when Settings closes. On the amount screen that close also sends the review's "rejected" analytics event.

Why each refusal doesn't break a working send

• A memo, up front (change 4): the screens refuse exactly the memos the build refuses (a test runs every case through both), and only on a Soroban send with a memo. XLM and classic assets to a G keep their memo, and a numeric memo still becomes an M when the contract supports muxed addresses.
• M without muxed support: feat(send): support muxed contract (W) destinations #1036 blocks it on both screens and builds nothing until the support check answers, so only a disagreement between the screen's check and the build's reaches the refusal. Neither check is cached, and a failed check counts as unsupported.
• A memo that can't be carried, custom token: this already failed. /simulate-token-transfer puts the memo on the Soroban transaction and the RPC rejects it ("Transaction contains a memo. Soroban transactions do not support memos."), which Review showed as "Request failed with status code 400". A direct call to the endpoint with the same transfer returns 400 with the memo and 200 without it.
• A memo that can't be carried, collectible: the one path that really sent without the memo, because the collectible transaction is built on the device and simulated without any memo. The memo field is disabled for a collection without muxed support, but a federation memo is kept when the recipient is picked, and for a collection with muxed support the field accepts any text.

Tests

• muxedAddress.test.ts: the three fallbacks now throw (an M without support, a memo without support, a memo that doesn't fold); a memo for an M throws; a G without a memo is still returned when the contract has no muxed support.
• memoFolding.test.ts (real SDK): "0x10", " 16 ", "AB12CD" and 2^64 now throw instead of returning the G; a memo without support and a memo for an M throw; decimal folding is unchanged.
• transactionService.test.ts: for a collectible, a decimal memo becomes the M (checked in the XDR's to), a memo is refused with and without muxed support, and an M without support is refused; for a custom token, an M without support and a memo without support are refused. The custom-token fixture moved to module scope so both suites share it.
• SendCollectibleReview.test.tsx: a builder error renders as a toast.
• sendRecipient.test.ts: a typed M and a picked M are both looked up through the base G, so an M of a funded account is funded; C and W are still never looked up.
• muxedAddress.test.ts (change 4): getSorobanMemoRefusal refuses exactly what determineMuxedDestination refuses, over 17 cases (G, C and M recipients, the uint64 edges, and both sides of the SDK's 22-digit limit), returns nothing without a memo, and logs nothing.
• MuxedAddressWarningBottomSheet.test.tsx: the four memo variants, with the real en strings.
• TransactionAmountScreen.test.tsx (+10) and SendCollectibleReview.test.tsx (+7): banner, Continue (Review) off and nothing built without muxed support and for a memo that isn't a number; a numeric memo still builds; nothing until the contract check answers; a C blocked without a lookup; nothing built when Settings saves a memo the token can't carry; the percentage buttons or the image hidden. The amount screen also checks that XLM and a classic asset to a G aren't blocked, and that switching to XLM unblocks.
• Change 5: TransactionAmountScreen.test.tsx (+3) and SendCollectibleReview.test.tsx (+1). On both screens, a memo the token can't carry saved from Settings throws away the earlier build and closes the review. On the amount screen, a second save while the memo blocks the send does the same, and XLM with a text memo still builds on Continue.

Verification

• Suites: yarn test at 0be6b47d: 336 suites passed (1 skipped), 5,003 tests passed (6 skipped). yarn lint:ts is clean. ESLint and Prettier are clean on the 15 changed files. yarn check still exits 1 on the same 111 lint errors in untouched files that main has. yarn lint:translations reports no missing translations.
• Device checks for change 4, iPhone SE (3rd generation) simulator, iOS 27.2, dev build on testnet at 61d0b2f6, through throwaway Maestro flows. The wallet holds no TZT, so the amount stays empty.
  • Memo "hello" saved while sending XLM to a G, then TZT chosen: once the contract check answers (about 3 s on testnet), the "Memo not supported" banner shows, Continue stays off and the percentage buttons hide. No toast, since nothing is built. The banner opens "This token can't be sent with a memo to this address." Switching back to XLM removes the banner.
  • The same with a local, uncommitted change that makes the app treat TZT as supporting muxed addresses (reverted after the run): the banner shows as soon as TZT is chosen, and its sheet reads "This token only accepts a numeric memo, from 0 to 18446744073709551615."
  • Not run on Android: change 4 is JavaScript only.
• Change 5 wasn't run on a device. Reaching the review sheet's gear with a custom token needs a funded custom token and a clean Blockaid scan, and this testnet wallet has neither. The tests above cover it.
• Device checks for changes 1–3, iPhone SE (3rd generation) simulator, iOS 26.5, dev build on testnet, through throwaway Maestro flows. Before is 70908faa, after is this branch at 70a0d855, before change 4.
  • Custom token: before, no message after switching to TZT, then "Request failed with status code 400" at Review. After, "Failed to build payment transaction: Error building Soroban transfer operation: Memo is not supported for this operation." as soon as TZT is chosen.
  • Collectible: a temporary local fake collectible (reverted, never committed) whose collection address is TZT's contract, so its transfer builds and then fails simulation. Before, Review does nothing. After, the simulation error shows as a toast.
  • M of a funded account (an M of Circle's testnet USDC issuer, sending XLM): before (this branch without 70a0d855), the recipient screen says "The destination account doesn't exist"; after, it doesn't. The caution sheet shows only Blockaid's testnet "Unable to scan transaction" in both runs, since the expected-to-fail warning needs a scan result. A W recipient still gets no notice and no lookup.
  • The custom-token and M checks weren't run on Android: the change is JavaScript only.
• Device checks on Android, Pixel 10 Pro emulator (API 37), dev build on testnet, through throwaway Maestro flows. Before is feat(send): support muxed contract (W) destinations #1036 (2aeacc1f), after is this branch at e30ec086, before change 4.
  • Text memo "hello" on a TZT send to a G, with a local, uncommitted change that makes the app treat TZT as supporting muxed addresses: before, "Request failed with status code 400" at Review. After, "Failed to build payment transaction: Error building Soroban transfer operation: This token only accepts a numeric memo, from 0 to 18446744073709551615." as soon as an amount is entered.
  • Collectible, with the same temporary fake collectible as on iOS: before, Review does nothing. After, the simulation error ("Request failed with status code 400") shows as a toast as soon as the screen's build fails, and it's still there when Review is tapped.

🤖 Generated with Claude Code

[github-actions]

iOS Simulator preview build is ready: https://github.com/stellar/freighter-mobile/releases/tag/untagged-9b8de630ad152fa9c38b
Backend: V1 prod + V2 staging (no sandbox configured for @CassioMG). SDF collaborators only — install instructions in the release description.

[github-actions]

Android Emulator preview APK is ready: https://github.com/stellar/freighter-mobile/releases/tag/untagged-6e2bfe92ae84d010ac03
Backend: V1 prod + V2 staging (no sandbox configured for @CassioMG). SDF collaborators only — install instructions in the release description.

[Copilot]

🟢 Approval recommended

No active review issues remain, with targeted handling for lossy muxed destinations, M-account funding checks, user-facing build errors, translations, and regression coverage included.

No open issues 🎉

What changed in this PR

This pull request makes Soroban send construction fail closed when muxed destinations or memos cannot be preserved, improves funding checks for M… recipients, and surfaces collectible build errors to users.

Changes:

• Reject unsupported muxed destinations and memos that cannot be encoded without data loss.
• Resolve M… funding checks through the underlying G… account.
• Display collectible transaction-build failures as error toasts.
• Add English and Portuguese translations and regression coverage.

File	Description
src/​services/​transactionService.ts	Documents the updated payment and collectible transaction build failure behavior.
src/​i18n/​locales/​pt/​translations.json	Adds Portuguese translations for the new refusal messages.
src/​i18n/​locales/​en/​translations.json	Adds English errors for unsupported muxed destinations and nonnumeric memos.
src/​helpers/​muxedAddress.ts	Refuses destinations and memos that cannot be represented without data loss.
src/​ducks/​sendRecipient.ts	Uses an M… address’s base G… account for funding checks.
src/​components/​screens/​SendScreen/​screens/​SendCollectibleReview.tsx	Shows collectible transaction-build errors as toasts.
__tests__/​services/​transactionService.test.ts	Tests payment and collectible build refusal behavior and destination encoding.
__tests__/​helpers/​muxedAddress.test.ts	Tests refusal of unsupported muxed destinations and memos.
__tests__/​helpers/​memoFolding.test.ts	Tests valid and invalid memo-to-muxed-ID conversion.
__tests__/​ducks/​sendRecipient.test.ts	Verifies funding checks for typed and selected M… addresses.
__tests__/​components/​screens/​SendScreen/​screens/​SendCollectibleReview.test.tsx	Verifies collectible build errors render as toasts.

_{Review effort: Lite}