reference

Glossary

Plain-language definitions of the Zcash terms used in this explorer. Hover any underlined term elsewhere on the site to see the same definition inline.

Transaction statuses

Mined: Included in a block on the best chain. The confirmation count grows as more blocks pile on top.
Pending: Seen in the mempool, validated, but not yet mined into a block. May be mined, invalidated, or expire.
Conflicting: Tries to spend the same inputs as another transaction. Only one of the conflicting set can ever be mined.
Invalidated: Removed from the mempool by the upstream node: usually because a conflicting transaction was mined or the expiry height has passed.
Suppressed: Dropped by the node's mempool policy filter. The transaction is valid by consensus rules but did not meet the local relay policy (size, fee, or similar).
Not found: No transaction with this id is in the indexed state. The id may be wrong, or the transaction may exist on a chain the indexer is not tracking.
Unavailable: The upstream returned an unspecified status for this transaction. The indexer cannot tell whether it is in the mempool, mined, or invalid.

Privacy shapes

Public only: All inputs and outputs of this transaction are transparent. Counterparties, amounts, and any memos are visible on chain. Coinbase and ordinary transparent-to-transparent payments fall here.
Public to private: Transparent inputs feed at least one shielded output. Value is moving from the public chain into a private pool (Sapling or Orchard). The funding side is visible; the destination is hidden.
Private to public: At least one shielded input feeds transparent outputs. Value is leaving a private pool for the public chain. The exiting amount and destination are visible; the source is hidden.
Private only: All inputs and outputs are shielded. Counterparties, amounts, and memos are hidden by zero-knowledge proofs; only the component counts are public.
Mixed: Both transparent and shielded components appear on at least one side of this transaction. Some details are public; some are private.
Unknown: The indexer has not classified this transaction's privacy shape yet, or its components fall outside the known patterns.

Pools

Sapling: Zcash's second-generation private pool, in production since 2018. Hides sender, recipient, and amount of every transaction inside it.
OrchardZIP-224: Zcash's current private pool, activated in 2022. Uses Halo 2 proofs, which removed the trusted setup that earlier pools required.
Ironwood: Zcash's NU6.3 private pool. It uses the Orchard protocol shape with a separate note commitment tree and nullifier set.
Sprout: The original Zcash private pool from 2016. Now deprecated: funds in Sprout can be moved into Sapling, but no new Sprout transactions are accepted.
Shielded pool: A cryptographic pool where transactions hide sender, recipient, and amount. Zcash has had Sprout, Sapling, Orchard, and Ironwood.
Value pool: The total ZEC held inside one of Zcash's pools. The transparent pool works like Bitcoin's; private pools hide individual balances but the pool total is public.

Transaction components

Sapling spend: An input to a transaction, sourced from the Sapling private pool. The amount and the address it came from are hidden.
Sapling output: An output of a transaction that places ZEC into the Sapling private pool. The amount and the recipient are hidden.
Orchard action: A single Orchard input-and-output pair. One action can spend, receive, or both. Counts of actions are public; their amounts and parties are not.
Ironwood action: A single Ironwood input-and-output pair. Counts of actions are public; their amounts and parties are not.
Sprout JoinSplit: A grouped Sprout-pool transfer. You only see JoinSplits in older transactions: Sprout is deprecated.
Coinbase: The first transaction in each block. Mints the block reward and pays it to whoever mined the block. Unrelated to the exchange of the same name.
Input resolution: The explorer's process of looking up each input of a transparent transaction to recover its amount. Resolution can be partial or unavailable when inputs come from pruned, very old, or private sources.

Address types

Transparent address: A public Zcash address. Balances and history can be looked up by anyone. Starts with t1, t2, t3, or tm on testnet.
Unified addressZIP-316: A single Zcash address that bundles several receiver types (transparent, Sapling, Orchard). The sender's wallet picks the best receiver for each payment.
TEX addressZIP-320: A Zcash address that signals it must only receive funds sent directly from a transparent source. The public history mirrors the equivalent t-address.
P2PKH: Pay-to-PubKey-Hash. The most common transparent address shape: ZEC sent here is unlocked by a single signature. Starts with t1 on mainnet.
P2SH: Pay-to-Script-Hash. A transparent address whose unlock rules are defined by a custom script: multi-signature wallets and time-locks use this shape. Starts with t3 on mainnet.

Fees

ZIP-317: Zcash's fee standard. Sets a minimum recommended fee based on transaction shape rather than byte size, so private transactions pay their fair share.

Disclosure

Payment disclosureZIP-311: A signed proof that a specific private payment happened. Lets the sender reveal one transaction publicly without de-anonymizing the rest of their wallet.

Wallet concepts

Viewing key: A key that lets the holder see transactions to and from a private address, but not spend the funds. Useful for auditors and accounting tools.

Chain concepts

Transparent: Public Zcash. Balances, transactions, and amounts can be looked up by anyone, the same way they can on Bitcoin. The opposite of shielded.
Shielded: Private Zcash. Transactions hide the sender, the recipient, and the amount using zero-knowledge proofs. Only the holder of a viewing key can see them.
Chain tip: The most recent block in the longest valid chain. The tip height is its block number; the tip hash identifies it uniquely.
Chain reorg: A temporary branch switch where blocks that were visible are replaced by another valid chain segment.
Recorded reorg history: Reorg incidents recorded by Zinder's explorer projection. New projections backfill retained chain events first, then keep future incidents beyond event retention.
Reorg incident ID: Zinder's recorded chain-event sequence for this incident. Useful for support and logs; not a Zcash block height or chain-native ID.
Replay window: The current chain-event history Zinder can replay. It is operational history for subscribers, not a permanent record of every chain reorg.
Invalidated segment: The inclusive height range that was visible before a reorg and is no longer on the best chain.
Canonical replacement: The block or inclusive range that became the best-chain segment after a reorg.
Reorg depth: How many previously visible blocks were invalidated by one reorg incident.
Canonical lag: How many blocks the canonical store trails the upstream node by. Non-zero during bulk catch-up and after node restarts; reported when the operator has wired the IngestControl plane.
Ingest phase: Where the upstream writer is in its catch-up loop. `following tip` means the canonical store is at the upstream node's tip. `bulk catchup` means the writer is replaying a backlog. `awaiting upstream` means the upstream node itself is not yet ready.
Derive lag: How many blocks the derive projections trail the canonical store by. Non-zero when a heavy consumer is catching up; usually zero in steady state.
UTXO: Unspent transaction output. A discrete chunk of ZEC sitting at a transparent address, waiting to be spent. Each spend consumes one or more UTXOs and creates new ones.
Mempool: The pool of transactions that nodes have seen and validated but that haven't made it into a block yet. Membership is per-node; not every node sees the same mempool.
Confirmations: Number of blocks built on top of the block that contains this transaction. More confirmations means deeper finality: at 10+ confirmations a reorg is extremely unlikely.

Transaction statuses

Mined

Included in a block on the best chain. The confirmation count grows as more blocks pile on top.

Pending

Seen in the mempool, validated, but not yet mined into a block. May be mined, invalidated, or expire.

Conflicting

Tries to spend the same inputs as another transaction. Only one of the conflicting set can ever be mined.

Invalidated

Removed from the mempool by the upstream node: usually because a conflicting transaction was mined or the expiry height has passed.

Suppressed

Dropped by the node's mempool policy filter. The transaction is valid by consensus rules but did not meet the local relay policy (size, fee, or similar).

Not found

No transaction with this id is in the indexed state. The id may be wrong, or the transaction may exist on a chain the indexer is not tracking.

Unavailable

The upstream returned an unspecified status for this transaction. The indexer cannot tell whether it is in the mempool, mined, or invalid.

Privacy shapes

Public only

All inputs and outputs of this transaction are transparent. Counterparties, amounts, and any memos are visible on chain. Coinbase and ordinary transparent-to-transparent payments fall here.

Public to private

Transparent inputs feed at least one shielded output. Value is moving from the public chain into a private pool (Sapling or Orchard). The funding side is visible; the destination is hidden.

Private to public

At least one shielded input feeds transparent outputs. Value is leaving a private pool for the public chain. The exiting amount and destination are visible; the source is hidden.

Private only

All inputs and outputs are shielded. Counterparties, amounts, and memos are hidden by zero-knowledge proofs; only the component counts are public.

Mixed

Both transparent and shielded components appear on at least one side of this transaction. Some details are public; some are private.

Unknown

The indexer has not classified this transaction's privacy shape yet, or its components fall outside the known patterns.

Pools

Sapling

Zcash's second-generation private pool, in production since 2018. Hides sender, recipient, and amount of every transaction inside it.

OrchardZIP-224

Zcash's current private pool, activated in 2022. Uses Halo 2 proofs, which removed the trusted setup that earlier pools required.

Ironwood

Zcash's NU6.3 private pool. It uses the Orchard protocol shape with a separate note commitment tree and nullifier set.

Sprout

The original Zcash private pool from 2016. Now deprecated: funds in Sprout can be moved into Sapling, but no new Sprout transactions are accepted.

Shielded pool

A cryptographic pool where transactions hide sender, recipient, and amount. Zcash has had Sprout, Sapling, Orchard, and Ironwood.

Value pool

The total ZEC held inside one of Zcash's pools. The transparent pool works like Bitcoin's; private pools hide individual balances but the pool total is public.

Transaction components

Sapling spend

An input to a transaction, sourced from the Sapling private pool. The amount and the address it came from are hidden.

Sapling output

An output of a transaction that places ZEC into the Sapling private pool. The amount and the recipient are hidden.

Orchard action

A single Orchard input-and-output pair. One action can spend, receive, or both. Counts of actions are public; their amounts and parties are not.

Ironwood action

A single Ironwood input-and-output pair. Counts of actions are public; their amounts and parties are not.

Sprout JoinSplit

A grouped Sprout-pool transfer. You only see JoinSplits in older transactions: Sprout is deprecated.

Coinbase

The first transaction in each block. Mints the block reward and pays it to whoever mined the block. Unrelated to the exchange of the same name.

Input resolution

The explorer's process of looking up each input of a transparent transaction to recover its amount. Resolution can be partial or unavailable when inputs come from pruned, very old, or private sources.

Address types

Transparent address

A public Zcash address. Balances and history can be looked up by anyone. Starts with t1, t2, t3, or tm on testnet.

Unified addressZIP-316

A single Zcash address that bundles several receiver types (transparent, Sapling, Orchard). The sender's wallet picks the best receiver for each payment.

TEX addressZIP-320

A Zcash address that signals it must only receive funds sent directly from a transparent source. The public history mirrors the equivalent t-address.

P2PKH

Pay-to-PubKey-Hash. The most common transparent address shape: ZEC sent here is unlocked by a single signature. Starts with t1 on mainnet.

P2SH

Pay-to-Script-Hash. A transparent address whose unlock rules are defined by a custom script: multi-signature wallets and time-locks use this shape. Starts with t3 on mainnet.

Chain concepts

Transparent

Public Zcash. Balances, transactions, and amounts can be looked up by anyone, the same way they can on Bitcoin. The opposite of shielded.

Shielded

Private Zcash. Transactions hide the sender, the recipient, and the amount using zero-knowledge proofs. Only the holder of a viewing key can see them.

Chain tip

The most recent block in the longest valid chain. The tip height is its block number; the tip hash identifies it uniquely.

Chain reorg

A temporary branch switch where blocks that were visible are replaced by another valid chain segment.

Recorded reorg history

Reorg incidents recorded by Zinder's explorer projection. New projections backfill retained chain events first, then keep future incidents beyond event retention.

Reorg incident ID

Zinder's recorded chain-event sequence for this incident. Useful for support and logs; not a Zcash block height or chain-native ID.

Replay window

The current chain-event history Zinder can replay. It is operational history for subscribers, not a permanent record of every chain reorg.

Invalidated segment

The inclusive height range that was visible before a reorg and is no longer on the best chain.

Canonical replacement

The block or inclusive range that became the best-chain segment after a reorg.

Reorg depth

How many previously visible blocks were invalidated by one reorg incident.

Canonical lag

How many blocks the canonical store trails the upstream node by. Non-zero during bulk catch-up and after node restarts; reported when the operator has wired the IngestControl plane.

Ingest phase

Where the upstream writer is in its catch-up loop. `following tip` means the canonical store is at the upstream node's tip. `bulk catchup` means the writer is replaying a backlog. `awaiting upstream` means the upstream node itself is not yet ready.

Derive lag

How many blocks the derive projections trail the canonical store by. Non-zero when a heavy consumer is catching up; usually zero in steady state.

UTXO

Unspent transaction output. A discrete chunk of ZEC sitting at a transparent address, waiting to be spent. Each spend consumes one or more UTXOs and creates new ones.

Mempool

The pool of transactions that nodes have seen and validated but that haven't made it into a block yet. Membership is per-node; not every node sees the same mempool.

Confirmations

Number of blocks built on top of the block that contains this transaction. More confirmations means deeper finality: at 10+ confirmations a reorg is extremely unlikely.