Zcash has 5 address types in circulation, and the difference between them is not cosmetic. Each one sits on either the public side of the chain or the private side, and the pair at both ends of a payment decides what an observer can read. Pick the wrong one and the amount becomes public.
The part that catches people is that this is not a setting you configure once. You choose a type every time you hand someone an address to pay you, and the person paying you chose one too.
So the useful question is which pair you are actually creating, and what that pair publishes. Best is not a property any single type has.
The address types, side by side
Five types are in circulation. Two sit on the public side, two on the private side, and one is a container holding several receivers at once. They differ in encoding and in which side of the chain they settle on. One of them can no longer be paid at all.
| Type | Side of the chain | What a payment to it publishes | Can receive new funds |
|---|---|---|---|
| Transparent | Public | Sender, receiver and amount, readable by anyone | Yes |
| Transparent-source-only | Public, restricted | The same, and senders are expected to pay it from the public side | Yes |
| Sprout | Private, legacy | That a valid payment happened | No, the pool is closed to new value |
| Sapling | Private | That a valid payment happened | Yes |
| Unified | Container | Depends which receiver inside it gets used | Yes |
The table is the whole map, and the column that matters is the second one. Everything else follows from which side a type settles on.
One name people expect is missing from it, and its absence is the point. Orchard is the current private protocol, and its specification states plainly that there is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. There is no Orchard address to hand anyone. The only way to be paid into that pool is a unified address, which is why the container is a type in its own right rather than a convenience.
Two other rows deserve a note. Sprout is legacy, and a consensus rule is what makes it so. That rule disables the ability to add new value to the Sprout chain value pool balance, described in the specification as a step toward being able to remove the Sprout shielded protocol altogether. Since receiving from outside the pool is exactly what adding new value means, it is not a type anyone should hand out to be paid on. Movement between two holders already inside the pool is a different case, and a vanishingly rare one. Unified, the container, is a single string carrying one or more receivers (source: Zcash Improvement Proposals), so the sending wallet uses whichever one both ends support. Our guide to Zcash unified addresses covers how that selection works; here it is one row, because what matters for choosing is that it defers the choice rather than making one.
If the words private and public are doing unfamiliar work here, our guide to what a blockchain address actually is covers the general case, and the reasoning transfers to every chain.
Which raises the practical question of which one you are holding right now.
How to tell which one you are holding
You rarely have to guess, though it takes a second look rather than a glance. A Zcash address carries its type in how it is encoded, and the encodings differ in ways you can see without any tool. Wallets almost always label them too, though the labels differ between programs.
Three checks, in order of how much they prove.
The letter case. The types do not share one encoding scheme, and the two schemes look different at a glance. Bech32 was introduced for Sapling addresses, and the same document says transparent and Sprout addresses will continue to be encoded using Base58Check and MUST NOT be encoded using Bech32. It also fixes the tell: encoders "MUST always output an all-lowercase Bech32 string", while Base58's mixed case is called out as the thing that makes it inconvenient to write down (source: Zcash Improvement Proposals).
So: an address with capital letters in it is Base58Check, which puts it in the transparent or Sprout family. An address that is entirely lowercase is Bech32 or its successor, which is the Sapling, unified and restricted family. That check needs no wallet to cooperate, and it proves more than the other two.
The length. Private addresses run substantially longer than public ones, because they carry more key material. Length narrows the field rather than settling it, since several types share the lowercase family and differ from each other only in how much they carry.
What your wallet calls it. Most software labels the receiving screen, and some offer a choice at the moment you generate. That label is the most useful of the three, and the least portable: two wallets can use different words for the same type.
There is one thing this check cannot tell you, and it is worth knowing before you rely on it. A unified address does not reveal which receivers it contains just by being looked at. It resolves at send time, so two unified addresses that look equally opaque may behave completely differently depending on what the sending wallet supports.
Knowing the type is only useful because of what the type does, which is the next question.
What each type publishes
A Zcash transaction settles on one side of the chain or the other, and the address type is what determines which. On the public side the transaction records its inputs and outputs in the clear, exactly as a Bitcoin transaction does. On the private side it records that a valid payment occurred and nothing about who or how much.
The critical detail, and the one most explanations skip, is that both ends count. Your address type governs what is published about your end. The other party's type governs theirs. Neither of you controls the whole outcome.
One hardware-wallet vendor's explainer puts the public case plainly: transaction details such as sender, receiver, and amount are publicly visible on-chain, similar to Bitcoin (source: CoolWallet). That produces a result people find counterintuitive: you can hold a private address, receive into it, and still have the amount published, because the payment came from somewhere that had to leave the private side to reach you. Our guide to crypto privacy basics covers the same point on other chains: what leaks is decided by the payment as a whole, and no single wallet setting overrides that.
A second detail matters for anyone reusing an address. On the public side, every payment to the same address accumulates in one readable history, so the address becomes a running record of everything it has ever received. Our guide to reusing an address explains how that record builds up. On the private side the same reuse does not build a public history, which is the single largest practical difference between the two. Nothing accumulates against the address, so handing the same one to twenty people leaves twenty payments that cannot be grouped.
Which is why the combination, not the type, is the thing to reason about.
What happens when you mix them
Four combinations exist between the public and private sides, and each publishes something different. The type on the sending end and the type on the receiving end together decide the outcome, so this matrix is the real answer to "which address should I use".
| Sender's side | Receiver's side | What an observer sees |
|---|---|---|
| Public | Public | Sender, receiver and amount |
| Public | Private | The sending address and the amount entering the private side |
| Private | Private | That a valid payment happened. Nothing else, if both ends sit in the same pool |
| Private | Public | The receiving address and the amount leaving the private side |
The matrix is the rule for crossings between the two sides, and the two middle rows are where people lose privacy they thought they had. A payment that crosses between sides publishes the amount crossing. It does not matter which direction it crosses in, and it does not matter how careful the other end was.
The third row carries a condition worth reading twice. The private side is not one pool but several, and the transaction format records the net value moving in or out of each one as a plain integer field, not an encrypted one (source: Zcash Improvement Proposals). A payment that stays inside one pool publishes nothing. A payment from one private pool to another publishes how much moved between them, even though both ends are private addresses. The chain keeps a balance for each of those pools and refuses any block that would drive one negative (source: Zcash Improvement Proposals), which is why the movement between them has to be recorded in the open.
Work through the common case. You hold funds privately and want to pay someone. They send you a public address, because that is what their software gave them. Your wallet does not refuse; it builds a payment that leaves the private side, and the amount and their address become readable. You did nothing wrong, your setup was correct, and the outcome is a public payment.
This is why the practical advice on this chain is about coordination rather than configuration. The private side only stays private when both ends stay on it, and the other end is not yours to control. Our guide to Monero's stealth addresses shows the alternative design, where the chain removes that coordination problem by not offering a public side at all. That project describes itself as the only major cryptocurrency where every user is anonymous by default (source: Monero Project), which is the same property stated from the other direction.
One of the five types adds a rule the chain itself does not enforce, and the specification names losing funds as what that gap can cost.
The type that only works one way
One of the five types is meant to be paid only from the public side. The specification that introduces it is titled, in full, "Defining an Address Type to which funds can only be sent from Transparent Addresses" (source: Zcash Improvement Proposals), and it is a re-encoding of an ordinary public address rather than a new kind of destination.
Read the next part carefully, because it is the opposite of what the name suggests. The same specification says it is not necessary for the restriction on the source of funds to be enforced as a consensus rule, and that a sender failing to adhere to the restriction risks loss of funds. The chain will not stop the payment. The obligation sits with the sending wallet, and the penalty for a wallet that ignores it falls on you.
It exists for a practical reason. Some services need to know which public address a payment came from, in order to credit the right account or to return funds if something goes wrong. A payment arriving from the private side carries no such origin, so those services could not process it. This type makes the requirement explicit in the address itself rather than leaving it to a note on a deposit page.
The consequence for a holder is specific and worth planning around. If you hold funds privately and need to pay one of these addresses, a conforming wallet moves the funds to the public side first and pays from there. That is two steps, and it publishes the amount on the way. A wallet that does not implement the rule may simply send from the private side, and that is the case the specification calls a risk of loss. So the practical question is not whether your wallet will let you, it is whether your wallet knows what it is looking at.
Most address documentation predates this type entirely. The project's own documentation set still describes only the two older private types on its address page (source: Zcash documentation), which reflects the page's age rather than the type's obscurity. Anyone working from documentation of that vintage meets this constraint for the first time as an error message rather than as a paragraph.
The practical rule is short. If a service that needs to identify the sender gives you an address, expect this type, and pay it from the public side yourself rather than trusting the software to arrange it. Our guide to sending to the wrong address or network covers the general failure mode, which is far less recoverable on most chains than people assume.
None of which tells you which type to hand out.
Which one to use, by situation
The choice is easier than the type list suggests, because most of the decision is made by what the other party can handle rather than by preference. Three situations cover almost everything, and none of them requires knowing a wallet's name.
Receiving from a service that verified your identity. Use whatever it offers, and expect it to be public. Services generally pay to public addresses so they can reconcile the payment against your account, and some require the restricted type for exactly that reason. The Zcash developer's own post on the newer format concedes the pattern: while all partners are strongly encouraged to support unified addresses, some may continue to only offer support for transparent addresses (source: Electric Coin Co.). Arguing with this is not productive; the identity check our guide to identity checks at exchanges describes already happened, so a private receiving address buys you less than it appears to.
Receiving from a person. Hand out a private address, or a unified address if your wallet issues them. This is where the choice actually pays, because the payment can settle entirely on the private side if their software supports it. If it does not, you learn that when the payment arrives public, which is a reason to ask first when the amount matters.
Holding. Keep funds on the private side. Sitting still requires nobody else's cooperation, costs nothing beyond the move that got you there, and leaves your next payment beginning on the private side instead of the public one. Our guide to holding your own keys covers the custody half of that decision, which matters more to most outcomes than the type does.
A note on the legacy type. If a wallet offers you the closed private type as a receiving address, almost nobody can pay it. The rule blocks value entering that pool from outside, which is where any payment you are likely to receive would come from. Someone already holding inside the pool is the narrow exception, and building a payment for you around that is not something you should ask of anyone.
Before acting on any of that, be clear what the choice does not buy.
What choosing a type leaves unchanged
An address type decides what a future payment publishes. It does not reach backwards, does not bind the other party, and does not survive their software's limitations. Four beliefs sit in that gap, and every one of them has cost someone real money.
| The belief | What the protocol does |
|---|---|
| A private address makes my holdings private | It governs payments to that address from now on. Anything already published stays published |
| My type protects the whole transaction | You cannot repair the other end from your side, and you usually learn their choice after the payment lands |
| Any wallet can pay any type | Support varies, and one type carries a rule the chain does not enforce for you |
| The exchange loses track once I use a private address | It recorded your identity and the address it paid, and neither is undone |
Each of those four deserves more than a table cell.
The first is the expensive one, because it feels like a fix. Switching to a private address changes what happens next and nothing before it, and the switch itself is a payment that crosses sides, so it publishes an amount. Our guide to keeping a coin's history private is really about the same principle on any ledger: information that is public does not become private later.
The second is the one this whole article exists to correct, and its cost is that it removes the step that would have prevented the loss. Someone who believes their own type settles the matter has no reason to ask the other party anything before sending.
The third is why the pairing matrix matters more than the type table. Support is not uniform, and it is not settled either: the specification index that governs all of this carries entries at Draft, Proposed, Active, Final and Withdrawn at the same time (source: Zcash Improvement Proposals). On the restricted type the gap is not a refusal you will notice, because the obligation sits with the sending wallet and getting it wrong costs the funds rather than throwing an error.
The fourth sits outside the protocol altogether. Identity checks and the records they create belong to the venue, and no address type reaches back into them.
There is also a plainer risk that has nothing to do with types. Addresses of every kind get substituted in transit by software that watches your clipboard, and a Zcash address is long enough that people check the first few characters and stop. Our guide to clipboard hijacking and address poisoning covers the habit that prevents it, which is to check the end as well as the beginning.
From where BloFin sits, the types matter to a customer at exactly one moment: the withdrawal. Before it the venue holds the coins and the question does not arise; after it the address you chose is already on the chain and cannot be reconsidered. That is a narrow window, and it is worth spending a minute inside it rather than an hour afterwards.
Frequently asked questions
Can I send from one type to a different type?
Usually yes, and the mixed cases are exactly where privacy leaks. Public to private and private to public both work, and both publish the amount crossing between the sides. The exception is the restricted type, which is meant to be paid only from the public side. A conforming wallet moves the funds out first and pays from there, without asking, which is why the public outcome surprises people. A wallet that does not implement the rule may send from the private side anyway, and the specification names that case as a risk of losing the funds.
What happens if I paste the wrong type?
Most of the time the payment simply settles differently than you intended, publishing an amount you meant to keep private, and there is no way to undo it. Pasting a valid address that belongs to a stranger is the unrecoverable case; nobody can reverse it for you. Pasting a malformed string is the harmless case, since the wallet refuses it. Two habits prevent the expensive versions. Read the closing characters, not only the opening ones. Then move a token amount first to see where it lands.
Do I need a different wallet for each type?
No, and needing one would be a sign the wallet is dated. Current software generally handles both sides of the chain from a single seed and shows one balance, splitting it by side where that matters. What does vary is which types a given program will issue and which it will pay, and that varies enough to be worth confirming before you rely on it. Which programs do what is an article-time fact, so check rather than trusting any list.
Are the older types still safe to use?
Holding on the closed private type carries no risk from age by itself. What has changed is settled at the protocol level rather than left to software: a consensus rule blocks new value entering that pool, and the specification frames it as a step toward removing the protocol altogether. So treat it the way you would treat any format on its way out. Fine to hold for now and worth moving out of. Never hand it to someone who has to pay you.
Does my address type show up on an explorer?
Yes, and looking yours up is a cheap way to confirm what you think you have. Paste it into a block explorer. If the page comes back with a spendable figure and a payment list underneath it, you are on the public side. If the explorer tells you the figure cannot be shown, you are on the private side and the explorer is behaving correctly. One trap: a blank page proves nothing either way, because a brand new public address is equally blank. Send yourself a small amount and look again.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, Electric Coin Co. and the Monero Project. All facts independently verified against cited documentation current as of August 2026. Wallet support for individual address types is an article-time fact that changes, so confirm the current position with your own software rather than relying on any list, including this one.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Regulatory treatment of privacy assets differs by jurisdiction and changes over time. Do your own research before making any decision.