How far Zcash has come on selective disclosure, and what's left

In Zcash, a viewing key lets an account holder reveal shielded transaction history to a party of their choosing. The keys are live and user-controlled. Builders and policy advocates are still at work on getting them to serve the compliance workflows that could use them.

On August 17 the Zcash Community Grants committee met to consider a proposal called the Shielded Compliance Bridge. Deborah Olaboye, an open-source contributor whose work includes Ethereum's execution-specs repository, had built a proof of concept that ingests a unified full viewing key, scans compact blocks against a testnet indexer, and carries a "compliance reference" in a Zcash memo field linking a shielded transfer to an off-chain Travel Rule record. She asked for a grant to finish it, but the committee declined.

The reasoning was that compliance integrations are shaped by the specific exchange or institution that will use them, that there are no common standards to build against, and that without a partner asking for the tool, adoption was unlikely. The same meeting declined other proposals for similar reasons, one for a "programmable selective disclosure" virtual machine, and a privacy and trust architecture framework, which included a map of US legal issues.

Of course, these decisions are not a sign that nobody wants this. Considered alongside the rest of the year, it is the opposite. Binance made a protocol-level ask in 2024 and had a ZIP within the year. Gemini has run shielded withdrawals under regulatory supervision since 2020. The ecosystem stood up a Washington policy organization in June and an institutional-integration shop in August. What the committee said, in effect, is that the need has not yet been written down as a requirement anyone can build to.

How the system works

A shielded Zcash address is controlled by a spending key. Derived from it are viewing keys that can read transaction data without being able to move funds. The full viewing key sees incoming and outgoing transactions for the account, the incoming viewing key sees only received funds, and the outgoing viewing key lets a sender reconstruct what they sent. Since ZIP 316, these are bundled into unified viewing keys, one full and one incoming, limited to an account, where an account is a position in the wallet's key tree under ZIP 32. A unified full viewing key bundles the per-pool components for every shielded pool the account uses, and it also has the account's transparent extended public key, so sharing one exposes the transparent chain as well as the shielded history.

A viewing key is in this sense retroactive. It decrypts the account's entire history from the moment the account was created, and it cannot be withdrawn once shared, short of moving funds to a new account. There is no per-transaction viewing key and no time-bounded one. Josh Swihart, chief executive of ZODL, the company formed this year by the protocol's former ECC engineering team, confirmed this, also mentioning that per-transaction payment disclosure is "not implemented anywhere."

zcashd, the original reference node, shipped two RPC methods, z_getpaymentdisclosure and z_validatepaymentdisclosure, that let a sender prove a single payment to a third party. The RPC documentation marks them experimental, disabled unless the operator set an experimental-features flag, and implementing a "work-in-progress Payment Disclosure ZIP." That ZIP, 303, is now marked withdrawn, and its successor, ZIP 311, remains a draft with no implementation attached. The methods covered only the Sprout pool, the original 2016 shielded pool, and were never extended to Sapling or Orchard, which is to say to the pools that carry every modern shielded transaction. zcashd itself reached end of life on July 18, 2026, a planned halt ahead of the Ironwood upgrade. Neither Zebra, the Zcash Foundation's consensus node, nor Zallet, the successor wallet, lists a disclosure method. For the pools that matter, per-transaction disclosure remains a design intention.

The intention is still live, but further out than it looked in July. ZIP 231, memo bundles, is the draft that would make room for it: Swihart described memo bundles as the eventual basis for an authenticated reply-to that could function as proof of payment, and the dependent draft, authenticated reply addresses, needs proofs too large for the current memo field. Memo bundles is a transaction format change, and the five organizations coordinating the NU7 coinholder vote agreed in August that format changes are out of scope for NU7 and in scope for the upgrade after. The vote itself, which runs from August 25 to September 14, put issuance, fee policy, block spacing and Sprout deprecation to holders; disclosure was not on the ballot. The older route, ZIP 311, needs no consensus change but remains a draft with no implementation and no Orchard coverage.

So what ships today is account-scoped viewing keys, full or incoming-only, retroactive, irrevocable and shared at the account holder's initiative, with transaction-level disclosure on the roadmap.

Understanding disclosure

Disclosure mechanisms, in Zcash or anywhere else, can be located on the following: What is revealed (scope). To whom (grantee). When the grant takes effect and how far back it reaches (timing). Whether it can be withdrawn (revocability). And who initiates it, the data subject or an authority (initiation).

Compliance regimes are requirements over those, and architectures are positions on them. Zcash's viewing keys are by design broad scope, holder-chosen grantee, fully retroactive, irrevocable, user-initiated. The requirement side, as it is applied by exchanges and supervisors, tends to be scoped to a relationship or a period, granted to a named institution or its analytics vendor, continuous from onboarding forward, revocable when the relationship ends, and initiated by the institution as a condition of service.

Both of these things get called selective disclosure. In the credential world, selective disclosure means presenting a subset of attributes from a signed credential without revealing the rest, which is what SD-JWT, ISO mdoc and BBS+ signatures are built to do. The unit of disclosure is an attribute, the moment is presentation time, and the holder decides per interaction.

In the shielded-payments world the phrase means revealing transaction data to a chosen party, where the unit is an account's history and the moment is whenever the key is handed over.

What the requirement side has asked for

Swihart said the only protocol-level compliance request the engineering team has ever received came from Binance, which in January 2024 required a transparent-provenance guarantee for deposits. The team's response was ZIP 320, transparent-source-only addresses, and the ZIP text indeed records the origin "as required by Binance." A TEX address is an ephemeral transparent pass-through that guarantees the exchange receives funds from a transparent source. It gives the exchange a return path without giving it the sender's history. The one accommodation the protocol made to an exchange discloses exactly what the exchange asked for and nothing more.

Since the Sapling upgrade, Swihart argues, there has been no technical reason for an exchange not to support shielded transactions, because proving is fast, exchange customers are already identified at onboarding, and enhanced due diligence exists for the cases that need it. On that view the span between the machinery and the compliance workflow is not really a missing primitive, but in fact a missing conversation.

Divij Pandya is working the other end of that conversation. He is executive director of Pretty Good Policy for Zcash, the Washington policy organization stood up in June as a continuation of an earlier ECC-led initiative, and his organization's project is to get viewing-key disclosure recognized as an acceptable compliance mechanism in a document a compliance officer can cite. To his knowledge, he said, no regulator has yet engaged with viewing keys as an instrument. PGPZ's scope, naturally, is recognition rather than builder guidance. A tool cannot be specified against a requirement until someone with authority has ruled on the instrument, so recognition is the upstream step. The organization's filings are signed by Paul Brigner as PGPZ's founder and as ZODL's chief policy and regulatory officer, so the policy and engineering efforts share an officer as well as a thesis.

A July 21 statement for the record to a House subcommittee on FinCEN oversight describes Zcash as having "selective disclosure capabilities, allowing users to voluntarily share transaction details through the use of viewing keys with auditors, tax authorities, or compliance officers," and refers to zero-knowledge proofs "paired with selective viewing keys" for proving specified facts. A comment letter on FinCEN's docket, FINCEN-2026-0101-0050, argues, per Pandya, that viewing keys and selective disclosure should be acceptable compliance mechanisms. The open question they put to the regulator is one of granularity, whether account-scoped, all-history disclosure is enough for "targeted transaction information," or whether the answer waits on ZIP 231.

Until that resolves, compliance teams face a constraint that a pseudonymous forum poster, strahncryptography, described in the discussion of Olaboye's proposal: they follow the rule to the letter, and will not adopt an unrecognized path without a regulator's or a law firm's attestation, however sound the cryptography. Any disclosure design that attaches a reference to a transaction proves only the last hop, and the last hop could be the depositor themselves. A viewing key has the same limit. It reveals the account holder's transactions, not where the counterparties' funds came from, which is the question a sanctions screen asks.

Viewing keys clear the bar wherever the requirement is proof by the data subject of what happened, like provenance of a deposit the depositor chooses to explain, a voluntary audit, a tax filing, a proof that a specific payment was made. Those are user-initiated, retroactive, one-time disclosures. They do not clear the bar where the requirement is continuous monitoring from onboarding forward, sanctions screening against counterparties the account holder does not control, scoping to a period or a relationship, or revocation at offboarding.

Gemini has accepted withdrawals to shielded addresses since September 2020, when a spokesperson credited ongoing conversations with regulators, extended that to the Orchard pool in November 2025, and to the post-Ironwood pool two days after activation in July 2026. It accepts deposits sent from shielded addresses into transparent custody. Kraken's withdrawal address list supports transparent ZEC addresses only, Coinbase is likewise transparent-only, and Binance requires TEX. What no major regulated exchange yet offers is shielded custody, a shielded deposit address, or a workflow into which a customer's viewing key would go.

The ingestion is being built one layer down. Among the proposals in the coinholder-directed retroactive grants round under review this September are ZecBooks, a Mac bookkeeping tool that imports a view-only key, classifies notes, and exports a scoped package of rows for an accountant without granting lasting access to the wallet; ZecLedger, a read-only cost-basis and reconciliation tool built around a unified full viewing key, tested against a mainnet wallet; and seer-sync, a chain-sync engine that takes a viewing key so a payment processor or accounting system can observe shielded activity without holding spending keys. None is an exchange workflow, and none has a regulator's attention. Each is the accountant-facing half of the same problem, built by one or two people without a partner asking, and ZecBooks' scoped export is selective disclosure operating at the interface where it is most often needed first: between a shielded user and the person keeping their books.

The class, not the coin

The Zcash builders are working on a problem shared by every privacy architecture.

In Zama's confidential-EVM design, an access control list determines which addresses may request decryption of a ciphertext, and a threshold network of key-management operators performs the decryption on request. That moves the grantee axis from a key the user hands over to a permission a contract records, and makes initiation programmable, since a contract can grant an auditor decryption rights as a condition of use. It does not make disclosure revocable in the sense a compliance officer means, because a ciphertext already decrypted stays decrypted, and it trades a user's key custody for operator honesty as the trust base. Asset-level auditor keys, of the kind in Solana's confidential transfer extension and Avalanche's encrypted ERC design, fix a grantee at the token level in that the issuer or a designated auditor can read balances and transfers for that asset.

Inco has published a framework for pre-defined viewing, where access is fixed in key material at transaction time, against programmable view access, where viewing rights are contract state that can be granted, scoped and withdrawn afterwards.

Why it's so difficult

What separates a viewing key from a compliance workflow?

A viewing key discloses the account holder's own history. Sanctions screening and continuous monitoring ask about counterparties, where the funds on the other side of each transaction came from, and that is precisely the information a shielded pool exists to withhold. Nobody has yet shown a design that answers a counterparty question without either a transparent ledger or a trusted third party.

If memo bundles land in the upgrade after NU7 and the reply-address draft follows, "targeted transaction information" in PGPZ's filings becomes literal. That is at least two upgrades away, and the regulatory answer arrives on a regulator's timeline.

The demand is easily seen by the number of people building toward it. What is missing is a fixed requirement for privacy-preserving disclosure. Zcash is the ecosystem where that decision is being negotiated in the open, by engineers, advocates, builders, an exchange and a grants committee who seem to agree on the destination and are arguing about the order of the steps. It is also being worked by solo developers who started on the accounting layer without waiting for the requirement to be written.

Disclosure: this piece is funded by Zcash Community Grants under grant #339. ZCG had no editorial input.