Memo Attribution

Overview

Memo Attribution interprets a transaction memo as evidence about the payment’s intended purpose. On Stellar, memos can be text, numeric IDs, hashes, or return hashes, and historically helped pooled accounts route deposits to individual users.

The memo must be read from the finalized transaction on the expected network. User-entered screenshots or wallet notes are not sufficient because they can differ from the field actually submitted on-chain.

Attribution differs from Memo-Based Matching. Memo attribution evaluates what the memo means and which entity it identifies, while memo-based matching uses that validated meaning to select a payment record.

A correct memo with the wrong destination should not be credited. The receiving address, asset, amount, and transaction status remain part of the evidence. Memo values should also be namespaced to avoid collisions between invoices, customers, and refunds.

Systems should retain the raw memo type and bytes as well as any decoded business reference. This preserves auditability when text encoding, normalization, or application rules change later.

This evidence can support later Transaction Attribution when the same memo is combined with amount and address data.

Text memos require normalization rules. Case conversion, Unicode normalization, whitespace trimming, or character encoding can change whether two values match. The safest approach preserves the raw bytes, validates the declared memo type, and performs business lookup against a canonical representation defined when the reference was issued.

Support tools should display the memo in a network-aware format and warn when characters are nonprinting or visually confusable. Staff should not copy a normalized display value into a manual credit without checking the raw transaction field.