Zcash Encrypted Memos: What They Protect and What They Do Not

Key Facts

• Current Sapling and Orchard shielded outputs carry a 512-byte memo field.
• Transparent Zcash outputs do not support the shielded memo field.
• Memo ciphertext is stored on-chain and does not expire when a wallet deletes its local copy.
• A memo is data from a transaction participant, not automatic proof of identity or truth.

A memo travels inside a shielded output

Zcash memos are part of shielded note ciphertext, not a public comment beside a transaction. Current Sapling and Orchard outputs reserve 512 bytes for memo data. The recipient's wallet can decrypt that field together with the note when it detects the incoming payment. This gives a payment room for an invoice reference, short message, refund identifier, or application payload without publishing that context to the chain.

The feature belongs to shielded outputs. ZIP 321 requires a payment request containing a memo to point to an address that permits memos; a transparent address does not. If a product claims to attach a private Zcash memo while sending only to a transparent receiver, inspect what it is actually storing and where.

Encrypted does not mean temporary

The chain stores memo ciphertext as part of the transaction. Deleting a message from one wallet interface does not remove those bytes from every node, indexer, backup, or block archive. The content is protected by encryption, but the ciphertext is durable. If the necessary viewing capability is shared or compromised later, historical memos within its scope can become readable.

That makes a Zcash memo closer to a sealed note in a permanent public archive than an ephemeral chat message. Encryption controls who can open it; it does not provide deletion. Do not place passwords, seed phrases, private keys, government identifiers, or information that would be catastrophic if revealed years later into a transaction memo.

Who can read a shielded memo

The intended recipient can decrypt the memo for an incoming note. Depending on the protocol, key components, and wallet behavior, the sender may recover outgoing note information through outgoing viewing capability. A full viewing key or Unified Full Viewing Key can give compatible scanning software broader access to transaction data, including memos it can decrypt within the key's scope.

The exact result is not just a property of the text field. It depends on which shielded pool carried the output, which viewing components are available, whether the wallet retained the outgoing recovery data, and whether the scanner implements the relevant protocol correctly. Test a disclosure workflow with known transactions before promising that an auditor will see every memo.

Text is conventional; the field can carry application data

Human-readable UTF-8 text is the familiar use, but the memo field is a fixed byte payload with conventions for distinguishing text from arbitrary or reserved formats. ZIP 302 proposes a standardized memo format, but it remains Draft. Applications using a private binary convention should not assume unrelated wallets will decode or display it.

ZIP 321 separately defines how memo bytes can be included in a Zcash payment URI using base64url encoding. The URI's message parameter is not the same thing: a wallet can display that message while preparing the request, whereas the memo is attached to the shielded output and encrypted on-chain. Products should label those fields clearly so a user knows what will become durable transaction data.

A memo is not a signature or verified identity

Receiving a note with the words 'paid by Alice' does not prove which human controlled the sending wallet. The memo is authenticated as part of the encrypted note data, but its prose is still a claim supplied by a transaction participant. It may be mistaken, malicious, copied, or generated by software under a misleading account label.

For payment support, pair the memo with facts the wallet can verify: transaction identifier, amount received, receiver account, block time, and the business record that assigned the invoice reference. For higher-assurance identity claims, use a separate authenticated channel or signature scheme designed for that purpose.

A safer memo checklist

Use the minimum context needed to reconcile the payment. Prefer a random invoice or order identifier over a full name, email address, street address, or medical description. Assume the ciphertext will be retained indefinitely. Decide whether future sharing of a viewing key should reveal the memo, and avoid placing data there if that later disclosure would violate the user's expectations.

Before sending, confirm that the receiver is shielded, the wallet shows the memo as encrypted transaction data, and the recipient's wallet supports reading it. After receiving, treat displayed memo text as untrusted input: wallets and downstream systems should escape it, constrain its length, and never execute it as markup or a command.

FAQ