Zcash is a proof-of-work cryptocurrency network, and ZEC is its native asset. It supports transparent activity and shielded transfers that can conceal selected transaction details when compatible wallets and address pools are used.
Use this page to assess whether Zcash fits a payment or privacy need, then review receiver compatibility, current fee behavior, confirmation policy and the limits of shielded activity.
This page is an educational network and market reference. It does not guarantee transaction privacy, wallet compatibility, exchange support or investment outcomes.
ZEC/USDT · Binance Spot · UTC
Long ranges automatically use a compatible candle interval.
Historical Binance Spot candles are available. JavaScript is required for current-candle updates.
| Time (UTC) | Open (USDT) | High (USDT) | Low (USDT) | Close (USDT) | Volume (ZEC) |
|---|---|---|---|---|---|
| Aug 25, 2026 11:00:00 UTC | 842.37 USDT | 843.75 USDT | 833.55 USDT | 836.27 USDT | 6,207.88 ZEC |
| Aug 25, 2026 10:00:00 UTC | 839.73 USDT | 846.44 USDT | 835.81 USDT | 842.39 USDT | 8,168.63 ZEC |
| Aug 25, 2026 09:00:00 UTC | 842.23 USDT | 854.97 USDT | 837.28 USDT | 839.61 USDT | 9,525.32 ZEC |
| Aug 25, 2026 08:00:00 UTC | 852.56 USDT | 855.53 USDT | 840.66 USDT | 842.23 USDT | 9,848.26 ZEC |
| Aug 25, 2026 07:00:00 UTC | 851.55 USDT | 866.93 USDT | 846.71 USDT | 852.50 USDT | 13,269.04 ZEC |
Market data: Binance Spot ZEC/USDT
Charting library: TradingView Lightweight Charts
Zcash supports both transparent and shielded transaction flows.
A shielded-capable protocol does not make every ZEC transaction private.
Zcash is useful only when the chosen wallet, receiver and transaction path support the privacy and compatibility you actually need.
Optional shielded transfers, privacy-aware payments or selective disclosure are relevant, and every participant uses compatible Zcash software.
Owning ZEC or using the Zcash network does not automatically hide a transfer. The source pool, destination receiver and wallet-constructed path determine what is protected.
Wallets, exchanges and payment services support different receiver types and pools. A valid Zcash address can still be unusable in a particular service flow.
Verify the receiver type, wallet support, selected transaction path, displayed fee and the recipient service confirmation policy before authorizing the payment.
One ZEC equals 100,000,000 zatoshis; wallet display precision does not change the underlying amount.
Wallet-facing base denomination
Smallest ZEC accounting unit
Zatoshis provide the integer accounting unit used when software represents ZEC amounts and fees. The denomination itself does not reveal whether value is held in a transparent or shielded pool.
0.01 ZEC equals 1,000,000 zatoshis.
Amount denomination is separate from whether a transfer uses a transparent or shielded pool.
Zcash transaction fees are paid in ZEC and represented in zatoshis. Current conventional fee guidance uses the logical work performed by a transaction rather than one universal flat fee for every transfer.
Under the active ZIP 317 conventional fee rule, wallets count logical actions contributed by transparent inputs and outputs and by shielded spends and outputs. A marginal fee of 5,000 zatoshis is applied with two grace actions, which keeps a minimal conventional transaction at 10,000 zatoshis while allowing more complex constructions to cost more.
Shielded transaction construction may include padding to reduce information leakage from unusual shapes. That padding and cross-pool activity can affect the action count, so two payments with the same ZEC amount can receive different wallet-calculated fees. The conventional fee is wallet policy guidance, not a claim that consensus requires every transaction to use one exact fee.
A minimal transaction within the two grace actions has a conventional fee of 10,000 zatoshis, equal to 0.0001 ZEC. A transaction with more logical actions may have a higher recommendation.
Use the fee shown by a current, trusted wallet. Do not hardcode an older flat-fee assumption or manually choose an unusual fee without understanding its privacy and relay effects.
A Zcash transaction can combine transparent inputs or outputs with Sapling or Orchard shielded actions. The resulting privacy depends on the complete path selected by the wallet.
Transparent activity exposes its public addresses and values. Shielding moves value from a transparent source into a shielded pool; deshielding exposes the transparent destination side; and a fully shielded transfer protects the relevant shielded addresses and amount fields from ordinary public inspection. Cross-pool transactions can include more than one transfer protocol, so the wallet must explain what is protected rather than treating every proof-bearing transaction as equivalent.
Source notes, destination receivers, change handling and wallet support determine which transparent or shielded components are constructed.
A zero-knowledge proof validates protected components without revealing their protected values, but it does not hide transparent components or metadata collected outside the protocol.
Zcash supports transparent, Sapling and Orchard receivers. A Unified Address can encode multiple receivers so a sending wallet can choose the best supported transfer protocol.
| Address Type | Common Prefix | Pool | Typical Use | Compatibility Note |
|---|---|---|---|---|
| Transparent receiver | t1 or t3 | Transparent | Public transfers and broad legacy integration | Addresses and transferred values are public |
| Sapling receiver | zs | Sapling shielded pool | Shielded payments in compatible wallets | Direct Sapling support varies by wallet and service |
| Orchard receiver | Inside a Unified Address | Orchard shielded pool | Current shielded payments through compatible wallets | No standalone user-facing Orchard address encoding |
| Unified Address | u | Receiver container | One address encoding that can carry supported receiver types | The sending wallet selects a compatible receiver; privacy is not guaranteed |
A Unified Address is an address container, not proof that the final transaction is shielded. The sender decodes the available receivers and selects one it supports; wallet policy and the recipient service therefore remain part of the privacy result. Viewing keys are separate sensitive credentials that can reveal shielded activity for accounting or selective disclosure without granting spend authority.
Confirm which receiver the sending wallet will use, especially when a Unified Address includes more than one option.
A wallet or exchange may support transparent deposits but not Sapling, Orchard or every Unified Address form.
The first confirmation records a transaction in an accepted block. Additional depth reduces reorganization risk according to wallet or service policy, but does not change the transaction privacy already established by its path.
The transaction is seen by the wallet or service but is not yet included in an accepted block.
The transaction is included in one accepted Zcash block, while reorganization risk remains policy-dependent.
Each later accepted block makes a reorganization less likely; required depth varies by wallet, merchant and exchange.
The wallet may wait for its configured confirmation or trust conditions before allowing the received output to be spent.
A wallet can display an incoming amount before it treats that output as spendable. The distinction depends on block inclusion, confirmation depth, whether the wallet treats the source as trusted, and its own risk policy. Official wallet guidance may recommend a confirmation threshold, but that recommendation is operational policy rather than a single consensus rule for every merchant, exchange and wallet.
Interfaces should distinguish a detected payment from a confirmed, policy-approved balance that can be spent.
Confirmation depth addresses reversal risk. Receiver and transaction-path choices address disclosure.
The two-path design preserves familiar public payment behavior while making stronger on-chain confidentiality available through shielded protocols.
Transparent Zcash activity behaves much like a conventional UTXO payment: addresses and transferred values are visible on the public chain. That makes basic inspection, exchange deposits and integrations easier for services built around public transaction records. It also means those transfers do not receive the address and amount protections of a fully shielded path.
Shielded pools let nodes verify that a transaction is valid without publishing the protected sender, receiver and amount fields in the same way. This changes what an ordinary chain observer can learn, but it does not erase the existence of the transaction, its fee or every clue created by timing, counterparties and the surrounding workflow.
Supporting both models helps Zcash interact with software that has different capabilities, yet it moves an important decision into the wallet. The wallet must recognize the receiver, choose a supported transfer protocol and explain when value crosses between transparent and shielded pools. A familiar send screen is not enough if it hides which path will be used.
A useful fit depends on deliberate shielded support, a workable receiver path and an operating policy that accepts Zcash-specific compatibility checks.
Zcash can fit when both sides deliberately support a shielded receiver and the sender can verify the path before signing.
Watch for: Confirm the wallet version, receiver type, fee and recipient support; a fallback to transparent activity changes the disclosure model.
Viewing capabilities can support reconciliation or reporting without handing over spend authority when the workflow is designed for that purpose.
Watch for: Define who receives viewing access, what it reveals and how the key material is stored and revoked operationally.
An application can use Zcash well when it explicitly handles Unified Addresses, shielded receivers, fees and confirmation states.
Watch for: Test every supported pool and migration path instead of assuming generic cryptocurrency wallet support is sufficient.
Support for shielded receivers and Unified Address components varies across services, so a privacy-preserving path may not be available everywhere.
Compare: Use a payment rail explicitly supported by every required counterparty, then compare its disclosure tradeoffs.
Zcash permits transparent activity and mixed pool transitions. The protocol cannot turn an unsupported receiver or transparent destination into a fully shielded payment.
Compare: Evaluate privacy-by-default designs if optional path selection is unacceptable, while reviewing their own compatibility limits.
This page describes Zcash as a payment and privacy network, not as a substitute for a general EVM-style application environment.
Compare: Evaluate a smart-contract platform when programmable application state is the central requirement.
Shielded protocols protect specific on-chain fields; they are not a promise of complete operational anonymity.
In a shielded transfer, the protocol is designed to keep protected addresses and values from ordinary public inspection while still allowing the network to reject invalid spends. Transparent inputs or outputs remain public, and moving value into or out of a shielded pool can reveal the transparent side of that path. Privacy therefore depends on the complete transaction, not simply on whether one shielded receiver appears in it.
Wallet behavior matters because the wallet chooses notes, receivers, change handling and transfer protocols. A Unified Address can contain more than one receiver type, and the sending wallet selects one it supports. That improves compatibility, but it does not guarantee that the final payment uses an Orchard or Sapling shielded receiver.
Viewing keys provide controlled read access without granting spend authority. They can support accounting, reporting or selective disclosure when the wallet and business process handle them correctly. They should still be protected as sensitive information because the holder may learn transaction details that are not public on the chain.
Network privacy also stops short of hiding information collected elsewhere. An exchange, merchant or counterparty may know an account identity, IP address, delivery details or timing relationship. More confirmations can reduce reversal risk, but they do not conceal information already visible in a transparent path or already shared with a service.
The useful distinction is not which network is universally better, but whether transparency, optional shielding or privacy-by-default behavior matches the intended workflow.
| Network | Transaction model | Address behavior | Consensus | Typical fit | Operating tradeoff |
|---|---|---|---|---|---|
| Zcash | Transparent, shielding, shielded and deshielding paths coexist. | Transparent, Sapling and Orchard receivers can be represented through compatible address formats, including Unified Addresses. | Proof of Work. | Workflows that deliberately choose shielded support or selective disclosure. | Receiver, pool and service compatibility must be checked. |
| Bitcoin | Transaction inputs and outputs are publicly inspectable. | Address formats identify supported script destinations, not a shielded pool. | Proof of Work. | Broadly supported public UTXO payments and settlement. | The public transaction graph requires separate privacy practices. |
| Monero | Protocol privacy features apply to ordinary transfers by default. | Wallet addressing is built around private transaction behavior rather than optional transparent receivers. | Proof of Work. | Users who want privacy behavior without choosing a transparent or shielded path. | Service support, audit methods and operational tooling differ from transparent UTXO systems. |
Most errors come from treating a network capability as an automatic property of every wallet, address and transaction.
Correction: Zcash supports transparent and shielded paths. Only the fields protected by the chosen shielded transfer protocols receive those on-chain confidentiality properties.
Why it matters: A transparent sender or destination can expose addresses and values that cannot be hidden later by waiting for more blocks.
Correction: A Unified Address is a container for compatible receiver types. The sending wallet selects a receiver it supports according to the applicable standard and its capabilities.
Why it matters: The final path may differ across wallets, so the sender must verify the displayed receiver and privacy result.
Correction: Confirmations increase depth after block inclusion and reduce reorganization risk according to policy. They do not rewrite previously disclosed transaction data.
Why it matters: Security against reversal and confidentiality are separate properties and need separate checks.
Correction: Support varies by product, version and service policy. A receiver valid under the protocol may still be rejected by a particular interface.
Why it matters: Sending or deposit workflows should be tested before a time-sensitive or high-value transfer.
Correction: Current conventional fee guidance accounts for logical actions and includes grace actions. Wallets may calculate different conventional fees for differently constructed transactions.
Why it matters: Hardcoding an old flat amount can understate the wallet-selected fee and may create unusual fee behavior.
Correction: Shielded protocols protect defined on-chain fields, not information collected by devices, networks, exchanges, merchants or counterparties.
Why it matters: Operational privacy still depends on wallet connections, account identity, timing and what is shared outside the chain.
The practical checks differ for someone making one payment, a wallet team, a service accepting deposits or an organization using selective disclosure.
Before sending, identify whether the destination is transparent, Sapling, Orchard or a Unified Address and read the wallet preview for the actual transfer path. A ZEC balance alone says nothing about receiver support or what the transaction will reveal.
A wallet should parse current address formats, select receivers correctly, calculate the current conventional fee and distinguish received from spendable balances. Error messages should explain unsupported paths instead of silently falling back.
Services should state which receiver types they accept, whether they can return funds to a shielded destination and how many confirmations their own risk policy requires. Deposit operations also need a recovery path for unsupported addresses or delayed spendability.
Selective disclosure can support reconciliation or reporting without granting spending authority, but the viewing material may reveal protected activity to its holder. Access, storage, handoff and incident procedures should be defined before it is shared.
The snapshot is CoinGecko aggregated ZEC/USD data. The chart is Binance Spot ZEC/USDT data. USD and USDT are different quote assets, so displayed values can differ.
Primary technical standards used to review the transaction, receiver, fee and wallet explanations on this page.
Additional operational questions not answered by the main transaction and receiver sections.
Viewing keys can provide read access to supported shielded activity without granting the ability to spend. The organization still needs a policy for access, storage and the exact disclosure scope.
A wallet may detect an incoming transaction before it reaches the confirmation depth or trust policy required for spending. The interface should distinguish detected, confirmed and spendable balances.
It depends on the Unified Address contents and the sending wallet. The wallet may select a supported transparent receiver when one is present, but the sender must verify the displayed path because that choice changes what is public.
Verified technical content, reviewed sources and update history.