Memo Field

What Is a Memo Field?

A memo field is an optional piece of metadata attached to a cryptocurrency transaction. It serves a similar purpose to the reference line on a bank transfer or the memo on a check: it tells the recipient what the payment is for, who sent it, or how to process it. Unlike the core transaction data (sender, receiver, amount), memo field content is typically not enforced by consensus rules and exists as application-layer metadata.

The concept appears across virtually every blockchain, though implementations vary significantly. Bitcoin uses OP_RETURN outputs to embed arbitrary data. Stellar and XRP include dedicated memo or destination tag fields at the protocol level. The Lightning Network attaches descriptions to invoices. Ethereum transactions carry a general-purpose data field that can serve as a memo for simple transfers. Each approach reflects different design philosophies about what metadata belongs on a blockchain and how it should be structured.

How It Works

Memo field implementations fall into two broad categories: protocol-level fields that are part of the transaction structure, and application-layer conventions that repurpose existing transaction features for metadata.

Bitcoin: OP_RETURN

Bitcoin does not have a native memo field. Instead, transactions can include an OP_RETURN output: a special script opcode that marks an output as provably unspendable. This allows arbitrary data to be embedded in a transaction without bloating the UTXO set, since nodes can safely discard unspendable outputs.

# Bitcoin OP_RETURN output structure
OP_RETURN <data>

# Example: embedding a payment reference
OP_RETURN "INV-2026-00842"

Prior to Bitcoin Core v30, relay policy limited OP_RETURN data to 80 bytes and allowed only one OP_RETURN output per transaction. Bitcoin Core v30 removed these relay policy restrictions, though the data was never restricted at the consensus level: miners could always include larger OP_RETURN data directly in blocks.

Stellar: Protocol-Level Memos

Stellar includes a dedicated memo field in its transaction structure with four distinct types:

• Text memo: a UTF-8 string up to 28 bytes, commonly used for exchange deposit routing
• ID memo: an unsigned 64-bit integer, often used as a numeric account identifier
• Hash memo: a 32-byte hash for referencing external documents or data
• Return memo: a 32-byte hash interpreted as the hash of a transaction being refunded

These are protocol-level fields, meaning the network validates their format (correct type, within size limits) even though it does not interpret their semantic content.

XRP: Destination Tags

XRP uses destination tags: 32-bit unsigned integers (ranging from 0 to 4,294,967,295) defined as an optional field in the transaction protocol. Exchanges use a single XRP address for all customer deposits and rely on the destination tag to route incoming funds to specific user accounts. Unlike Stellar's multiple memo types, XRP destination tags are strictly numeric.

Lightning Network: Invoice Descriptions

On the Lightning Network, memo-like functionality lives in the invoice layer rather than in transactions themselves. A BOLT 11 invoice includes a description field (d tag) that carries a UTF-8 string describing the payment reason. For longer descriptions, the h tag carries a SHA-256 hash of the full description text, which must be communicated out-of-band.

# BOLT 11 invoice description field
lnbc1500n1p...  # encoded invoice

# Decoded fields include:
# d: "Coffee at Main Street Cafe"
# or
# h: <sha256 hash of longer description>

These descriptions are off-chain metadata shared only between sender and receiver (and any routing nodes that inspect the invoice). They are not broadcast to the broader network or stored on a blockchain. For more detail, see the research article on Lightning invoices and BOLT 12.

EVM Chains: Transaction Input Data

Every Ethereum transaction includes a data field (also called calldata). For smart contract interactions, this field encodes a 4-byte function selector followed by ABI-encoded arguments. For simple transfers between externally owned accounts (EOAs), the EVM ignores the data field entirely, but the data is still persisted on-chain.

This makes the data field usable as an arbitrary memo for EOA-to-EOA transfers. There is no protocol-enforced size limit beyond the block gas limit: calldata costs 16 gas per non-zero byte and 4 gas per zero byte (after EIP-2028), so longer memos simply cost more gas.

Use Cases

Exchange Deposit Routing

The most common real-world use of memo fields is identifying deposits on cryptocurrency exchanges. Many exchanges operate a shared deposit address for all customers on networks like Stellar, XRP, EOS, and TON. When a user deposits funds, the memo or destination tag tells the exchange which internal account to credit.

This is a critical operational detail: sending funds to an exchange without the required memo typically means the exchange receives the funds but cannot automatically attribute them to any user account. Recovery requires manual intervention by the exchange's support team and is not always possible.

Invoice and Payment References

Merchants and payment processors use memo fields to attach invoice numbers, order IDs, or customer references to transactions. This enables automated reconciliation between blockchain transactions and accounting systems. A payment processor receiving funds can programmatically match each transaction to the corresponding invoice by reading the memo field.

Data Anchoring

Data anchoring uses memo fields (primarily Bitcoin's OP_RETURN) to timestamp document hashes on a blockchain. By embedding a cryptographic hash of a document in a transaction, you create a tamper-evident proof that the document existed at the time the transaction was confirmed. This technique is used for notarization, supply chain provenance, and audit trails.

On-Chain Messaging

Memo fields have been used for on-chain communication, from simple messages between addresses to protocol-level signaling. Bitcoin's OP_RETURN has been used by protocols like Runes and Ordinals to embed protocol metadata. On Ethereum, the calldata field has been used for on-chain messaging services and even for broadcasting text messages between addresses.

Consensus-Relevant vs. Application-Layer Data

An important distinction exists between memo data that affects transaction validity and memo data that is purely informational.

Consensus-relevant memo data includes EVM calldata for contract calls (the data directly determines contract execution), XRP destination tags and Stellar memos (validated at the protocol level for correct format and size), and Bitcoin's OP_RETURN opcode itself (consensus rules ensure the output is unspendable).

Application-layer memo data includes the content of OP_RETURN data (consensus ignores what the bytes mean), Lightning invoice descriptions (off-chain, between sender and receiver), and EOA-to-EOA calldata on Ethereum (persisted but never executed). The blockchain stores this data faithfully, but its interpretation happens entirely in application software. Two different applications can read the same memo field and derive completely different meanings.

Risks and Considerations

Privacy Implications

Memo fields on public blockchains are visible to everyone, permanently. Attaching an invoice number, customer ID, or personal message to a transaction creates a durable link between a blockchain transaction and a real-world identity. Combined with chain analysis techniques, memo fields can significantly reduce the pseudonymity of cryptocurrency payments.

Exchange destination tags are especially revealing: they tie a blockchain address to a specific exchange account, which is itself tied to a verified identity through KYC requirements. Anyone who observes the transaction can see the destination tag and know which exchange account received the funds.

Lost Funds from Missing Memos

When exchanges require a memo or destination tag for deposits, forgetting to include it is one of the most common user errors in cryptocurrency. The funds arrive at the exchange's address but cannot be automatically routed. Some exchanges offer recovery processes; others do not. The risk is highest on networks like Stellar and XRP where shared deposit addresses are standard practice.

Data Permanence

Information embedded in memo fields is immutable once confirmed on a blockchain. Accidentally including sensitive data (personal information, API keys, private messages) in an on-chain memo creates a permanent, publicly accessible record. Unlike centralized databases, there is no way to delete or modify this data after the fact.

Size Constraints and Costs

Every blockchain imposes limits on memo field data, whether through explicit size caps (Stellar's 28-byte text memo, XRP's 32-bit integer tag) or through economic costs (Ethereum's per-byte gas charges, Bitcoin's fee rate applied to OP_RETURN data size). These constraints mean memo fields are best suited for short references, hashes, and identifiers rather than large documents or rich media.

Why It Matters

Memo fields bridge the gap between raw cryptocurrency transactions and the real-world context surrounding payments. Without them, every transaction would be an anonymous transfer of value with no built-in way to communicate purpose or routing information. For businesses integrating cryptocurrency payments, memo fields enable the kind of automated reconciliation and identification that traditional payment rails provide through structured messaging standards like ISO 20022.

On networks like Spark, where transactions settle off-chain with high throughput, the ability to attach payment metadata is essential for merchant adoption and payment processor integration. Whether through Lightning invoice descriptions or application-layer references linked to a payment hash, memo-like functionality ensures that fast, low-cost payments remain compatible with existing business workflows.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.