Sending ZEC is easy. Sending it without publishing something you did not mean to publish takes 1 extra decision, and most people never learn they were making it at all. It is not a hard decision. It is made at a moment nobody looks at, and it cannot be taken back.
The decision is not made in a settings menu. It is made when somebody hands you an address, because the address they chose decides what the payment reveals. You can be careful at your end and still end up with a public record.
Search for how to do this and the results are a "1.0 User Guide", a forum thread about sending between two transparent addresses, plus a Medium post about moving funds to a shielded one. That vocabulary is a decade old, and the format built to fix the problem does not appear in any of it.
What you actually need before sending
You need three things before you send, and only one of them is obvious. The other two are the reason this guide exists, because neither is something a wallet asks you about and both decide what the payment leaves behind on a public chain.
The obvious one is the address. Someone gives you a string and your wallet sends to it.
The second is knowing what that string commits you to. On Zcash the address type sets the privacy outcome, and you do not get to override it from your side. A payment to a transparent address is a public payment, no matter what your funds were sitting in beforehand.
The third is knowing that the reverse is also true. Paying from public funds into a shielded address does not make the payment private. It makes the destination private and leaves the source visible.
Our guide to Zcash address types lays out all four combinations in a table, with what each one publishes. what follows assumes that table rather than repeating it, because what matters here is what you do about it.
The short version is that crossings between the public and private sides publish the amount crossing. In either direction, and that a payment staying entirely on one side publishes far less. Which side a payment lands on is decided by the address, and the address is chosen by whoever is being paid.
The vocabulary around all this is still catching up, which is worth knowing before the next section. Search the broad address query and the documentation the project maintains ranks near the top, describing the older address families without mentioning the bundled format that came after them (source: Zcash documentation).
So most explanations of this subject use a vocabulary that is one generation behind the tooling. That is worth naming, because it explains why the next section will look unfamiliar even to people who have used Zcash before.
If the underlying concept is new, start with what a blockchain address is and come back.
Payment request links, and what they carry
Here is the thing almost nobody sending ZEC has heard of, and it is the most useful item here. There is a standard format for asking to be paid. It carries considerably more than an address, and it has been a live standard for years rather than a proposal waiting on anybody.
The specification says so directly. It "proposes a standard format for payment request URIs", and the point is that "wallets that recognize this format enable users to construct transactions simply by clicking links on webpages or scanning QR codes" (source: ZIP 321).
The status matters and it is good news. The index lists this one as Active, not Draft and not Proposed, so it is a live standard rather than an idea.
What the format carries is the interesting part. It "must permit the representation of one or more tuples of payment address, amount, asset (if applicable), and optional memo". So a single link can specify who is paid, how much, then what note goes with it. It can also specify more than one recipient at once.
Compare that to the old way, which the specification describes without affection. Before the format existed, "the best option available was to manually specify a payment address, a payment amount, plus potentially memo field content", which "is tedious and may be error-prone".
Anyone who has pasted an address. They typed an amount, then squinted at both knows the failure mode. A request URI removes the typing, and with it the class of mistake that comes from typing.
The format went through open specification and public argument before adoption, and the reference wallet library ships an implementation of it as its own versioned component.
The memo field, and why it is a shielded feature
A memo is a note that travels with a payment. It is the closest thing Zcash has to the reference line on a bank transfer, it is genuinely useful for anyone who needs to say what a payment is for, and it has one property that people get wrong almost every time.
Memos are a shielded-side feature. The request format defines the parameter as "contents for the Zcash shielded memo field", and its own worked example with two recipients attaches the memo to the shielded address rather than the transparent one.
The reference implementation carries the same structure. A request is modeled as a set of payments, and "when constructing a transaction in response to such a request, a separate output should be added to the transaction for each payment value in the request" (source: zcash_client_backend).
So asking for a memo is asking for a shielded payment. If someone gives you a transparent address and wants a note attached. Those two requests are in conflict, and the address wins.
Now the part that looks like a limit and is actually a design choice. The rule is that "the decoded memo contents MUST NOT exceed 512 bytes, and if shorter, will be filled with trailing zeros to 512 bytes".
Read the second half again. Short memos are padded out. Every memo is the same size on the wire whether you wrote one word or five hundred bytes of them.
That matters because size leaks. If memos varied in length, an observer could learn something about what you wrote without reading it, in the same way that a thick envelope tells you more than a thin one. Fixed size removes that channel entirely.
Our guide to crypto privacy basics covers the general shape of that kind of leak.
Receiving well is where you have the power
Sending is mostly reactive. You use the address you were given, and you live with whatever it publishes. Receiving is the opposite of that, and it is where almost all of your actual control over this sits, which is why it deserves more attention than it usually gets.
When you hand somebody an address, you are choosing what the resulting payment can reveal. Publish a transparent one and the payment is public, regardless of how careful the sender is. Publish one that includes a shielded receiver and a capable sender will use it.
Our guide to Zcash unified addresses covers the format that bundles several receivers into one string, so a sender's wallet picks the best type it supports. For receiving, that is the whole point of it.
None of this is theoretical tooling either. The request-URI component ships as its own separately versioned crate in the reference library, updated across successive releases alongside the rest of the wallet stack (source: librustzcash changelog).
Two habits are worth building, and both are cheap.
Give out a fresh address rather than reusing one. Reuse links payments together whatever else you do, and it does so permanently.
And give out a payment request rather than a bare string whenever the amount is already known. It removes the typing step at the other end, and typing is where the errors come from.
Neither habit requires you to understand anything about pools or proofs. Both are simply choices about what you hand over.
There is a third habit that costs nothing and helps most: check the payment afterwards. A public chain means a transparent payment is inspectable by you as easily as by anyone else, so a quick look tells you what actually got published rather than what you expected to publish. Doing that once teaches more than reading about it.
Our guide to address reuse covers why the first one matters even on a chain with a private side, and our guide to reading a block explorer covers how to see for yourself what a payment published.
The mistakes that cost privacy rather than money
These are the ones worth knowing, because not one of them looks like a mistake while you are making it. Nothing is lost. No transaction fails. No warning appears. The cost shows up later, in what somebody else can reconstruct from a public record, which is the hardest kind of error to learn from.
Accepting whatever address you are given. The most common one by far. The sender has no way to make a payment private if the recipient published a public address, so the moment to ask is before the payment, not after.
Asking is easier than it sounds, and it is a single question: do you have a shielded address I can pay instead? Most people who hand out a transparent address do it because that is what their software showed them first, not because they wanted a public record.
Assuming your side controls the outcome. Holding shielded funds does not make your payments private. It makes them private until they leave, and a payment to a transparent address leaves.
This is the mistake that surprises careful people. Doing everything right on your own side genuinely does protect the funds while they sit there. It buys nothing at the moment they move to a public destination, because the destination is not yours to choose.
Reusing a receiving address. Every payment to the same string is visibly the same recipient. On the transparent side this is exactly the Bitcoin problem, and our guide to common beginner mistakes covers the general version.
Pasting an address without checking it. This one costs money as well as privacy, and it is the reason our guide to address poisoning exists. A request URI helps here too, because there is nothing to paste.
The attack works by getting a similar-looking string into your clipboard at the moment you are about to pay. Checking the first and last few characters catches most of it. A scanned request removes the step the attack targets, since you never copy or paste anything, though that is a statement about this attack rather than about every way a payment can be misdirected.
None of these are new observations. The problem of making payment requests easy and hard to get wrong was raised and worked through in public before the standard existed (source: zcash/zips issue 347), which is a reasonable place to look if you want the reasoning rather than the result.
Our guide to Zcash privacy leaks and metadata covers the leaks that survive even when you get all four of these right.
What this procedure leaves unfixed
Four things this procedure cannot do for you, and the first one shapes the rest. Each is something a careful reader might reasonably hope this procedure delivers, and each is a thing the procedure hands off to somebody else, usually to software or to a counterparty neither of you controls.
You cannot make a payment more private than the address allows. Everything above is about choosing well and asking early. Once an address is in hand, its type has already decided the outcome, and no wallet setting overrides it.
A request URI does not mean the sender's wallet understands it. The format is Active and implemented in the reference library, and a wallet that has not implemented it sees a link it cannot open. Standards work by adoption, and adoption is never total.
It does not undo anything already sent. If a payment landed transparent, that record is permanent. For what can be done afterwards, and more importantly what cannot, read our guide to Shielding ZEC after an exchange withdrawal.
And it does not address the layers underneath. The network you broadcast on, the server your wallet queries, plus any venue that verified your identity are all untouched by getting the address right. Those are separate surfaces with separate answers, and none of them is an address question.
There is a fourth thing worth saying about limits, and it is about this article rather than the chain. Everything here describes a standard and what it permits. Whether a given piece of software implements any of it is a fact about that software, checkable only by looking at it. The specification's own reference implementation is public and readable (source: zcash_client_backend), which is a starting point rather than an answer about the wallet on your phone.
The gap between what the tooling can do and what most explanations describe is the real difficulty here. The standards moved. The explanations did not.
BloFin has no stake in which address you hand out, which is why what follows is about the decision rather than a product.
A checklist for a payment that has to be private
Seven checks, and the first four are about the other party rather than about you.
Confirm the recipient can receive into the current pool. A payment is private only if both ends are, and a recipient running older software will hand you an address that cannot be.
Confirm which address they gave you. A unified address defers the choice to your wallet; an older shielded address commits to one pool; a transparent address publishes the amount whatever you do.
Ask before assuming. A one-line question about which wallet they use resolves more than any amount of inspection of the address string.
Decide whether the memo carries anything sensitive. It is encrypted and visible only to the recipient. That makes it useful, and it is still a permanent record in their wallet.
Then, on your side, check the amount you are sending against what a crossing would reveal if one is involved.
Check that you are spending from the private side rather than the public one, since a wallet holding both will often default to whichever is simpler.
And send a test payment first if the destination is new. This is the only check on the list that catches an address error, and address errors are the failure that cannot be undone.
What good receiving practice looks like
Receiving is where you have the most control and the least attention is usually paid.
Publish a unified address rather than a specific type. It defers the decision to the sender's software, which means you get the best option their wallet supports rather than the one you guessed they had.
Do not reuse an address across contexts you want kept separate. The transparent receivers inside a unified address behave exactly like any public address, and reuse links everything paid to it.
Keep the birthday. Record the date or block height when the account was created, alongside your backup, because a restore without it is dramatically slower.
And check what actually arrived rather than assuming. A payment landing transparent when you expected shielded is worth knowing about immediately, since the remedy involves your next transaction rather than that one.
Why sending is the easy half
The asymmetry in this subject is worth stating explicitly, because most guidance is organized the other way round.
Sending is largely mechanical. You have an address, an amount, and a wallet that constructs the transaction. The decisions available to you are few, and the main one, which pool you spend from, is usually made by the software.
Receiving is where the choices are. The address you publish determines what a sender's wallet is able to do, whether the amount ends up public, which pool the funds land in, plus whether the payment can be linked to everything else paid to that address. All four are settled before any payment happens, by you, in advance.
That is why the receiving section above is the longer one, and why the single most useful habit on this chain is publishing a unified address and checking what arrives. Most of what people try to fix at send time was decided at receive time by somebody else.
That asymmetry has a corollary worth acting on. If you are going to be paid more than once, the setup work is worth doing properly once: publish a unified address from software that supports the current pool, record the birthday with your backup, and check the first payment that arrives against what you expected. Everything after that is repetition, and the checks stop being necessary.
If you are going to be paid once, by someone whose software you do not control, the honest expectation is that the payment may land transparent regardless of what you publish. Planning for that is cheaper than being surprised by it, and the remedy, shielding afterwards, is a normal operation rather than a repair. Our guide to shielding after a withdrawal covers the operation and the timing decisions around it.
Frequently asked questions
Does sending from a shielded address keep my payment private?
Only if the destination is also shielded. The receiving address decides what the payment publishes, and a payment leaving the shielded side for a transparent address makes the receiving address and the amount visible. Holding funds privately protects them while they sit still. It does not protect a payment out to a public destination. Our guide to Zcash address types sets out all four combinations and what each one reveals.
What is a Zcash payment request URI?
A standard format for asking to be paid, defined in a specification the index lists as Active. Instead of handing over a bare address, you publish a link or QR code that can carry the address, the amount, an optional memo, and even multiple recipients. The stated purpose is to let wallets build transactions from a click or a scan, replacing the old routine of manually specifying an address, an amount and any memo content by hand.
Can I attach a note to any Zcash payment?
No, memos are a shielded-side feature. The request format defines the memo parameter as contents for the shielded memo field, and its own two-recipient example attaches the memo to the shielded address rather than the transparent one. So if someone gives you a transparent address and asks for a note with the payment, those two requests conflict and the address type decides.
Why is there a 512-byte memo limit?
The limit is less interesting than what happens below it. Memo contents must not exceed 512 bytes, and anything shorter is filled with trailing zeros up to 512 bytes. That means every memo is the same size regardless of what was written, so the length of your note reveals nothing to an observer. It reads like a size restriction and works as a privacy property.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, its public discussion record, and the reference wallet library's published documentation. All facts independently verified against cited documentation current as of August 2026. This article names no wallet, gives no command as an instruction, and makes no claim about which software implements the payment request format.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.