Every shielded Zcash payment carries a small field where the sender can write anything at all, up to 512 bytes of it. The field is encrypted and genuinely useful. It is also the only part of a shielded transaction whose contents are entirely your own responsibility rather than the protocol's.
That last part is not a warning label somebody added. It is what the protocol specification says, in a clause most readers never reach.
what follows covers what the field commits you to, which is a different question from how to use it. Our guide to Send and receive Zcash covers attaching one when sending, and our guide to Zcash viewing keys covers viewing keys and who ends up holding them.
What the memo is, and the clause that makes it yours to get wrong
The protocol specification describes the field in a sentence that sounds administrative and is anything but, once you notice what it declines to say: "The usage of the memo field is by agreement between the sender and recipient of the note" (source: Zcash protocol specification).
Read that against how the rest of the specification talks. Consensus rules are stated as things nodes MUST enforce. This is stated as an arrangement between two people, which is exactly what it is.
The same paragraph adds that constraints on the contents are RECOMMENDED and non-consensus, pointing at a separate document for them. So the network transmits and encrypts whatever you put there and takes no view on it whatsoever.
Compare that to an address, which the protocol constrains tightly because getting it wrong loses money. Our explainer on what a blockchain address is covers that side. The memo is the opposite case: nothing about it can be wrong in a way the software will catch.
Our guide to Send and receive Zcash covers the mechanics of attaching one, including why memos only exist on the shielded side.
The practical effect is that a memo is the only user-authored content on a shielded chain that no rule inspects. Everything else in a transaction is checked by every node, while this one field is transmitted, encrypted and delivered without anything forming an opinion about it.
That design is deliberate and it is the right call. A network that policed the contents of private messages would be a strange thing to build, and the alternative would require the network to read them.
The format meant to standardize it has been a Draft since 2017
If the specification defers the content rules to another document, the obvious next question is what that document actually says and whether anyone finished it. It is ZIP 302, titled "Standardized Memo Field Format". Its front matter reads Status: Draft, Created: 2017-02-08 (source: ZIP 302).
That is a draft the network's own specification has been pointing at for over nine years.
The content is sensible and worth knowing, because wallets follow it whether or not it is finished. It sets out how to read a memo. A leading byte below a certain value means human-readable text. A specific byte means the sender wrote nothing, and certain reserved ranges mean, in the document's own phrasing, that "this memo is from the future, because these ranges are reserved for future updates to this specification".
The document is careful about its own authority in a way worth quoting. "The following specification constrains a party, called the 'reader', that interprets the contents of a memo. It does not define consensus requirements."
So the rules for reading a memo are advice to software, published in a draft, plus the rules for writing one do not exist at all. Its tracking thread on the repository was closed long ago (source: zcash/zips), and a finished conversation is not a finished document. The gap between a status label and the state of the world is our guide to Zcash roadmap nu7 and ironwood's subject in this series.
The draft is nonetheless load-bearing. The reference library everyone builds on models a memo as exactly four cases, and one of them is named Future (source: docs.rs). ZIP 302's phrasing about memos from the future is not a turn of phrase somebody liked; it is compiled into the software.
What people actually write in them
The field was introduced with an unusually wide invitation. A company post published five weeks after launch described it as a place for an invoice number, a refund address or a note to the recipient, then wondered aloud whether it might serve private messaging, timestamping, land title registries or health records (source: Electric Coin Company).
Ten years on, the community's own how-to page is more modest and more revealing. Its first listed use is signing a payment: "Users can use the memo field to sign their name or pseudonym to let their counterpart know who the transaction was from" (source: ZecHub).
Sit with that for a moment. On a chain where the sender's address is hidden by design, the most common suggested use of the one free-text field is to tell the recipient who you are.
That is not bad advice. A recipient who cannot tell which of forty invoices a payment settles is not served by privacy, and the same page lists sending messages and even files as further uses. It is simply worth noticing that the standard usage pattern involves voluntarily undoing part of what the shielded protocol just did for you, and our guide to crypto privacy basics covers why voluntary disclosure is usually the weak link rather than the cryptography.
The same pattern shows up on transparent chains, where people attach references to payments for exactly the same operational reason. What differs here is that the shielded side gave you the option not to, and the memo is where you decide whether to take it.
What a memo leaks even when nobody reads it
Here is the part that appears in no explainer of this subject, and the reason it deserves attention is its source: it comes from a Zcash proposal, written by people improving the protocol, rather than from anyone with a case to make against it.
Today, every shielded output carries its own memo whether the sender wrote one or not. ZIP 231 spells out the consequence: "A chain observer can therefore infer a likely 1:1 correlation between transaction recipients and memo payloads" (source: ZIP 231).
The contents stay encrypted. The count does not. An observer cannot read your note and can see how many notes there are, which is a different kind of fact and occasionally a more useful one. The same document adds that sending extra data to one recipient means adding outputs, which on chain looks the same as paying more recipients.
Two other properties, both stated by the project itself at launch, decide how much that matters.
The field is permanent: the 2016 post said plainly that data written there becomes part of the immutable chain. And it is readable by anyone holding the right key, since the same post states that the memo "is visible only the to recipient, unless the transaction view key for the transaction gets shared" with a third party. That typo is the source's, and the point survives it.
Put those together and the shape is clear. You write something once. It is there forever, and any future disclosure of a viewing key hands it over along with everything else that key opens. A key shared years later for an entirely unrelated reason still opens the memo you wrote today, which is why address reuse and disclosure habits matter more on this chain than on a transparent one.
Memo bundles, and what a proposal would change
There is a proposal to restructure all of this, and its own status is the first thing to state. ZIP 231, created in April 2024, appears on the specification index's candidate list for the next network upgrade and carries the status Draft there (source: Zcash Improvement Proposals).
Its design decouples the memo from the output. "Each shielded output carries a 32-byte memo key rather than an inline 512-byte memo field", with the memo itself stored in a per-transaction bundle of encrypted chunks. That would allow larger memos, let one memo be shared between recipients, and permit memo data to be pruned from stored transactions without breaking validation.
It would also break the correlation described above, though not for free. The same document notes that after such a change, recipient count and memo count become independent, and that without mitigation "a v6-onward transaction with no memo would be distinguishable from one with a memo". Its answer is a minimum bundle size and padding, which is the same trick the current design already uses at a different level.
None of that is deployed and none of it is scheduled. The index lists it among proposals under consideration and states that no decision has been made about any of them, which our guide to Zcash roadmap nu7 and ironwood covers in full. What it tells you today is only that the people maintaining the protocol consider the current arrangement improvable, which is worth knowing and is not a reason to change anything you do.
It is also a useful check on how the earlier sections should be read. The correlation is real enough that a proposal exists to remove it, and modest enough that removing it has waited years behind other work.
Limits of an encrypted memo
Encryption is not the question here, and nothing above disputes it. The contents are sealed to everyone except the recipient and anyone holding a viewing key, exactly as the project has always described it. What encryption cannot do is decide what you typed into the box, or control how long that remains true about you (source: Electric Coin Company).
Permanence is not reversible. There is no edit and no expiry, so a memo written for a counterparty you trusted in 2026 stays readable by whoever holds the relevant key in 2036. Ordinary security hygiene does not help with data you published on purpose.
Counts are not contents, and the network hides only the second. A watcher learns how many memo-carrying outputs a transaction has even while learning nothing about what any of them says.
Your wallet is not making this decision for you either. Software decides how to display and encode a memo, following a draft document, and our explainer on how crypto wallets work covers where that boundary sits. What goes in the box is yours.
And nothing here is about depositing to a business. A memo attached to an exchange deposit reaches whoever operates that account and lands in their records, which is a custody question covered in our guide to how exchange wallets work rather than a protocol one.
Finally, none of this says the field should be avoided. It is the closest thing a private chain has to a reference line, several of its uses have no substitute, and the argument above is about writing into it deliberately rather than about leaving it empty.
What to put in a memo, and what to keep out
The field is encrypted to the recipient and permanent in their wallet, and both halves of that sentence matter when deciding what to write.
Reference information is the intended use. An invoice number, an order reference or a short note identifying what a payment is for turns an otherwise anonymous transfer into a reconcilable one, and it is the reason the field exists.
Anything you would mind existing indefinitely is the category to avoid. The memo persists in the recipient's wallet for as long as that wallet does, it travels with any backup they make, and it is readable by anyone who later obtains their viewing key. Encryption protects it in transit and on the chain; it does not control what happens to it afterwards.
Identifying information deserves particular care. A memo naming a person, an account or a location converts a shielded payment into one that carries exactly the data the shielding was meant to withhold, and it does so inside the encrypted envelope where nobody will think to look for it.
And instructions that depend on being read are unreliable by construction. There is no requirement that any wallet display a memo, no acknowledgement that one was read, and no way to tell from your side whether the recipient's software surfaced it at all.
The rule that follows is short. Write what a reconciliation needs and nothing that a subpoena would want.
That framing also settles the question people ask most often, which is whether a memo is safe to use at all. It is, for its intended purpose, and the encryption is genuine. What it is not is a private channel in the sense of a conversation that disappears, and treating it as one is the mistake that produces regret later rather than immediately.
There is a final property worth stating because it surprises people who have thought about the rest. A memo travels with the payment, which means it exists in the recipient's wallet whether or not they wanted it, and it persists there without any action on their part. From the recipient's side, an incoming memo is a record somebody else created inside their own filing system, and the only control they have is deleting the wallet entry, which most software does not offer.
That asymmetry is worth carrying in both directions. As a sender, you are writing into somebody else's records permanently. As a recipient, you are accumulating records other people wrote, with no say in their contents. Neither position is dangerous by itself, and both are worth being aware of before the field is used casually for anything that matters.
Why the field is easy to misjudge
Three properties combine to make the memo the most commonly misunderstood part of a shielded payment.
It is encrypted, which reads as private. What it actually means is that it is readable by the recipient and by anyone with the appropriate viewing capability rather than by the general public.
It is optional and free, which encourages casual use. A field that costs nothing to fill in gets filled in without much thought, and the thought is the whole of the protection here.
And it is invisible to the sender afterwards. Once sent, the memo lives in the recipient's records, and you have no ability to retract, amend or confirm anything about it.
Put together, the memo is best treated as a permanent note written into somebody else's filing system. That framing produces the right instincts without requiring anyone to understand the cryptography.
Frequently asked questions
Is the Zcash memo field really private?
The contents are encrypted and readable only by the recipient, or by anyone the sender or recipient later gives a viewing key to. Two things are not covered by that. The memo is permanent, so a disclosure years from now still exposes what you wrote today, and the number of memo-carrying outputs in a transaction is visible on chain even though their contents are not. A Zcash proposal describes that count as a likely one-to-one correlation with recipients.
What should I put in a Zcash memo?
The protocol takes no view: its specification says the usage of the field is by agreement between sender and recipient, and the document defining content rules states that it does not define consensus requirements. The community's own guidance suggests a name or pseudonym so the recipient knows who paid, alongside invoice references and messages. That is useful and it is also voluntary disclosure on a chain that just hid your address, so it deserves a moment's thought rather than a reflex.
Why is the memo format still a draft?
ZIP 302, the standardized memo field format, carries the status Draft and was created on February 8, 2017. The protocol specification points at it for recommended, non-consensus constraints, so wallets follow it in practice while it remains formally unfinished. Its tracking thread on the repository closed long ago, which tells you about that conversation and nothing about the document. The reference library used across the ecosystem nonetheless models memos in exactly the four cases the draft describes, so it is unfinished on paper and settled in practice.
What are Zcash memo bundles?
A Draft proposal, ZIP 231, created in April 2024 and listed among candidates for the next network upgrade. It would replace the memo carried inside each shielded output with a 32-byte key pointing into a per-transaction bundle of encrypted chunks. That would permit larger memos, let one memo serve several recipients, and break the link between memo count and recipient count. Nothing about it is deployed or scheduled.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the Zcash protocol specification, ZIP 302 and ZIP 231, the specification repository's issue tracker, a dated company post from December 2016, and the community wiki. All facts independently verified against cited documentation current as of August 2026. Quotations are reproduced exactly, including one typographic error in the 2016 source.