The transparent source and spent value remain visible.
Privacy-respecting lookup
Explorer
Inspect public chain data, compare payment visibility, and learn what viewing keys disclose without uploading wallet secrets.
Public Chain LookupCurrent source snapshot
Current source snapshotEnter a public identifier
Shielded sender, receiver, amount, and memo fields are not exposed by public search.
Interactive privacy model
Shielding boundaryTransaction Visibility Lab
Choose the actual funding and receiving paths. The result shows what an unprivileged observer can learn from the public chain.
Showing Transparent to shielded. Observers can see the transparent source cross into a shielded pool, but cannot identify the shielded recipient from the chain alone.
transparentTransparent to shieldedshielded
Always public: transaction existence, transaction ID, and block inclusion.
The shielded receiver is not published on-chain.
Value entering the shielded side is observable, but shielded change prevents confirming one recipient's exact payment.
A shielded output can carry an encrypted memo.
Public-chain readoutObservers can see the transparent source cross into a shielded pool, but cannot identify the shielded recipient from the chain alone.
Privacy consequenceThis improves the recipient's privacy, but it does not erase the public history before the shielding transaction.
A Unified Address is a receiver bundle, not a fifth visibility mode.
A supporting wallet chooses an included transparent, Sapling, or Orchard receiver. This lab models the payment path the wallet actually constructs.
Compare all four payment paths
| Path | Source | Recipient | Amount | Memo |
|---|---|---|---|---|
| Transparent to transparent | Public | Public | Public | Unavailable |
| Transparent to shielded | Public | Encrypted | Not confirmable | Encrypted |
| Shielded to transparent | Encrypted | Public | Public | Unavailable |
| Shielded to shielded | Encrypted | Encrypted | Encrypted | Encrypted |
Educational model only. Real transactions can contain multiple inputs, outputs, change, and pool interactions; wallet and network metadata can add context that this matrix does not model.
Selective disclosure model
Payments to the accountViewing Key Disclosure Lab
Compare what different levels of viewing authority reveal. This tool never asks you to paste a key.
Showing Incoming viewing authority. Useful for receive-only auditing. Sharing it exposes incoming financial history across every supported component bundled into the key.
Incoming viewing authorityAn incoming viewing key reveals payments received by the account components it contains.
A scanner can identify shielded notes received by included account components.
The received note value and memo can be decrypted. Memo identity claims are not authenticated by the key alone.
Incoming authority is defined around payments to an address, not payments from it.
Incoming authority alone does not provide the full account scanning authority used to track spends.
Received value is visible, but a reliable current balance requires spent-note detection.
Addresses derived from the incoming authority can be associated with the same account-level key.
Disclosure consequence
Useful for receive-only auditing. Sharing it exposes incoming financial history across every supported component bundled into the key.
No key input. No account scan. No secret leaves your wallet.
This is a protocol education model, not a wallet importer or blockchain scanner.
Compare all three viewing levels
| Viewing authority | Incoming payments | Incoming amount and memo | Sent payment details | Spent-note detection | Account balance | Diversified address linkage |
|---|---|---|---|---|---|---|
| Public observer | Encrypted | Encrypted | Encrypted | Unavailable | Unavailable | Not publicly linked |
| Incoming viewing authority | Detectable | Readable* | Not included | Not included | Incomplete | Linkable |
| Full viewing authority | Detectable | Readable* | Usually readable* | Detectable | Trackable* | Linkable |
This model uses ZIP 316's UIVK and UFVK roles plus ZIP 310's Sapling security analysis. Exact coverage depends on the key components, wallet behavior, and scanner implementation.
Latest Blocks
| Height | Time | Transactions | Size | Reward | Pool |
|---|---|---|---|---|---|
| 3,421,096 | 4 min before snapshot | 4 | 11.3 KB | 1.5625 ZEC | Unknown |
| 3,421,095 | 5 min before snapshot | 1 | 1.6 KB | 1.5625 ZEC | ViaBTC |
| 3,421,094 | 5 min before snapshot | 10 | 18.0 KB | 1.5625 ZEC | ViaBTC |
| 3,421,093 | 12 min before snapshot | 4 | 20.4 KB | 1.5625 ZEC | Poolin |
| 3,421,092 | 13 min before snapshot | 1 | 1.6 KB | 1.5625 ZEC | Unknown |
| 3,421,091 | 13 min before snapshot | 2 | 10.9 KB | 1.5625 ZEC | ViaBTC |
| 3,421,090 | 14 min before snapshot | 10 | 18.9 KB | 1.5625 ZEC | Foundry |
| 3,421,089 | 18 min before snapshot | 5 | 3.0 KB | 1.5625 ZEC | Unknown |
Five-block observed interval: 2 min · ZcashInfo snapshot
Latest Block Transactions
| Time | Type | TXID | Visibility | Size |
|---|---|---|---|---|
| 4 min before snapshot | Coinbase | 36d6c8f2…3eba67 | Public reward | 141 B |
| 4 min before snapshot | Transparent | 213ce3a5…6a94d7 | Public transaction | 244 B |
| 4 min before snapshot | Transparent | 01d4b17b…91b55a | Public transaction | 240 B |
| 4 min before snapshot | Orchard | 56d1fd4a…f007a0 | Encrypted payload | 9.2 KB |
Public txids only. Shielded payloads stay encrypted and are never decoded here.