Zcash in SSP: Transparent Only, and Why Upgrades Matter Here
Zcash is known for one thing above all others: it can hide the amounts and addresses in a transaction. That capability is real, it is cryptographically serious, and it is the reason the project exists.
SSP does not use it.
That sentence is the most important thing in this guide, so it comes first rather than buried in a caveats section at the end.
Two pools, and which one you are in
Zcash is really two ledgers sharing one coin.
The transparent pool behaves exactly like Bitcoin. Addresses begin with t, amounts are public, the history is fully auditable by anyone, and script types like P2SH multisig work the way you would expect.
The shielded pool is the part Zcash is famous for. Addresses begin with zs or u, amounts and participants are encrypted, and validity is proven with zero-knowledge proofs rather than by publishing the details. It uses entirely different key material and an entirely different transaction structure.
SSP operates only in the transparent pool. Your Zcash 2-of-2 vault is a P2SH address in the t family, and every transaction you make from it is as publicly visible as a Bitcoin transaction. There is no setting to change this.
The reason is structural rather than a matter of priorities: SSP's security model is a two-of-two multisig built from two independent devices, and the shielded pool does not offer an equivalent multi-party spending arrangement that SSP could use. Choosing shielded would mean giving up the two-device protection that is the entire point of the wallet.
So the honest summary is: SSP gives you custody of ZEC, not confidentiality of ZEC. If you hold Zcash specifically for its privacy properties, you need a shielded-capable wallet, and no amount of care inside SSP will substitute for one. If you hold ZEC as an asset and want it behind two devices, SSP does that well.
The upgrade problem, and why it is worth your attention
Here is the property that makes Zcash operationally different from every other chain in SSP.
Zcash performs periodic network upgrades, and each one changes a value called the consensus branch ID — a number that must be embedded in every transaction signature. After an upgrade activates, transactions signed with the previous branch ID are rejected by the network outright.
This is not a subtle degradation. It is a hard cutoff. The most recent example is concrete: NU6.3 activated on Zcash mainnet at block 3,428,143 on 28 July 2026, and from that block onward transactions carrying the old NU6.2 identifier stopped being accepted.
For a wallet, this means Zcash support has an expiry date attached to every network upgrade. A wallet that has not been updated to know the new branch ID will build transactions the network refuses. Nothing is lost — a rejected transaction never happened, so no fee is paid and no coins move — but sends will simply fail until the wallet is current.
The practical consequence for you is short and worth remembering: keep SSP updated, and pay particular attention around Zcash network upgrades. This is the one chain in the wallet where being a version behind can stop you transacting.
Transactions expire here too
Like Flux, which shares Zcash's lineage, Zcash transactions carry an expiry height. SSP sets it 60 blocks ahead of the current tip, which at Zcash's block times works out to roughly an hour and a quarter.
The implication is the same as on Flux and worth repeating because it interacts with two-device signing: start the transaction when you are ready to finish it. If you approve on the extension and then leave your phone in another room for an hour, the transaction can expire before the second signature arrives.
The failure is benign. An expired transaction was never accepted by the network, so no fee was paid and nothing moved. You rebuild it and sign again.
Fees and mechanics
SSP defaults to 30 units per byte on Zcash — higher than Litecoin's 20 and far below Bitcoin's 100. The dust limit is the familiar 546 units, and SSP will not attach a fee above 0.1 ZEC to any transaction.
Zcash does not support replace-by-fee. Combined with the expiry window, that gives Zcash the same shape as Flux: a transaction is accepted as built or it ceases to exist. There is no stuck-in-the-mempool state to manage.
Your vault is P2SH, derived from the same seed as every other chain, protected by the same two-of-two arrangement as the rest of the wallet.
What Zcash is for
Zcash is the most technically serious privacy project in the top tier of crypto assets. The zero-knowledge cryptography it pioneered has influenced the entire field, and the shielded pool does what it claims to do.
The persistent tension is that most ZEC does not sit in the shielded pool. Transparent balances have historically dominated, which means the privacy set — the crowd you blend into — is smaller than the market cap suggests. Privacy technology gets stronger the more people use it, and Zcash's shielded adoption has been the project's long-running challenge rather than its long-running achievement.
None of that is an argument against the technology. It is an argument for being clear-eyed about what holding ZEC gets you, and for not assuming that owning the asset confers the privacy the asset is famous for. In SSP specifically, it does not — by design, and stated plainly here so you do not have to discover it.
Getting started
Zcash appears in SSP's chain switcher alongside every other supported network, derived from the seed you already backed up. Balances, portfolio value and history behave like the other UTXO chains.
Four practical notes. Expect t addresses, and expect them to be public. Keep the wallet updated, especially around network upgrades. Have both devices to hand before you start, because the transaction expires. And don't worry about the fee, but get it right first time — there's no replace-by-fee.
For the click-by-click walkthrough, sending Zcash with SSP picks up from here. For the wider question of what the multisig does and does not protect, what actually stops a transaction is the piece to read next.
