A Privacy Layer for Transparent Wallets

Anyone worrying about AI-assisted advancements in cryptography is careful to keep public keys hidden. This means posting only the address containing a hash of the public key, and rotating transparent addresses on every transaction. Then, you add a hash-based spending signature escape hatch, such as WOTS, alongside your elliptic-curve public key.

There is no integrated UX flow for this, and ordinary wallet lookups undermine your privacy. The RPC server learns which addresses belong to the same client. Private information retrieval (PIR) removes this lookup leak, letting wallets monitor rotating addresses without revealing which ones they are checking. Using WOTS, this is deployable today, yielding post-quantum-safe, private rotating transparent addresses.

Our team plans for post-quantum signature opcodes to land in Zcash in January.

In this post, we’ll explain the PIR techniques that let a wallet recover its transparent history and balances without revealing the addresses it queries to the RPC server. Transparent transactions remain public on-chain; PIR protects the lookups needed to manage them.

How Rotation Helps

Each standard Zcash t1… transparent address contains a hash of a public key. The address and its transaction history are public, but the address alone does not disclose the underlying public key. Spending from it publishes that public key alongside the signature.

This distinction has enormous implications for address reuse. Once a public key is exposed, any funds remaining at that address, or arriving there later, remain controlled by the same key. Moving the remaining funds to a fresh address places them behind a different public-key hash. That offers additional protection under the scenario where public-key recovery becomes practical but the hashes remain secure.

Creating a fresh address does not require a new wallet or seed phrase. Standard wallet derivation produces a tree of distinct key pairs from one seed. Here is a simplified view:

Spending from A reveals public key A. It does not automatically reveal public keys B–E or the seed. The derivation below illustrates how each key uses its own offset:

If those other public keys have never been disclosed, they retain the protection of their hashes. The same backup can regenerate the sequence of addresses.

Keeping those public keys hidden also requires care with an extended public key. An account’s extended public key derives the public keys for its receiving and change addresses. Equivalent information can also appear in the transparent component of a Unified Full Viewing Key. Sharing it, therefore, exposes more public keys than an ordinary spend.

If an attacker obtains the account’s extended public key and recovers one of its transparent private keys, they can also recover the account’s root private key, deriving all others. Keeping the wallet secure requires protecting this key derivation information as well.

What else can go wrong?

Generating fresh addresses is only part of making privacy work. The wallet must continue checking addresses for payments, tracking their spends and reconstructing their history after a restore.

Ordinary transparent lightwallet requests make those checks using readable addresses. The wallet effectively asks, “Show me transactions for A, then B, then C.” The receiving server sees each address and can associate the searches with the same client. Encrypting the connection protects the requests in transit but the server can still read them.

That creates a privacy leak beyond what the blockchain already reveals. Separate addresses may appear unrelated on-chain, but sending a batch of address queries to the server tells it that they are all owned by the same user.

Addressing the “Lookup Leak”

We address this leakage with private information retrieval (PIR): retrieving a selected database record while cryptographically hiding which record was selected. Our design divides confirmed transparent activity into block ranges, each served by a shard. Because PIR retrieves records by position, the wallet hashes the address’s payment script locally to calculate candidate positions in the shard’s directory, then retrieves those records using PIR. The server does not learn which positions were selected.

To avoid making private lookups in every range, each shard also provides a compact public activity filter (think Bloom filters). The wallet downloads these filters and checks its addresses against them locally. This tells it which ranges might contain relevant activity, without sending its addresses to the PIR server. These filters are small: a range containing 10,000 distinct payment scripts would need roughly 15 KB of filter data. When a filter indicates a possible match, the wallet makes a private lookup.

The retrieved records describe confirmed receives and spends. Short histories fit in the initial response. Longer histories continue in privately retrieved additional pages. This lets a wallet monitor an expanding collection of fresh addresses without turning synchronization into a readable list of those addresses.

The same history is needed for recovery from a mnemonic. An old address may have received funds that were later spent or shielded. Its current balance is zero, but its history still needs to be retrieved. PIR lets the wallet fetch it without revealing the address it is checking.

Once the wallet has reconstructed its transparent ledger and checked which funds are spendable, it can retrieve more transaction details using PIR. This lookup starts from a transaction ID the wallet already knows and returns additional details, such as fees and output destinations, including outputs outside its own address set. All without submitting the transaction ID as a plaintext search term.

This is how PIR enables rotating transparent addresses: it provides the private monitoring and recovery foundation that wallets can combine with fresh address creation. Rotation limits public-key exposure and address reuse. PIR protects the searches needed to manage the resulting address set.

These protections address different risks. Learning that several addresses belong to one wallet does not itself reveal their hidden public keys. The benefits are complementary: rotation reduces exposure to a potential key-recovery attack, while PIR reduces information available for profiling and targeting.

Overall security benefits from addressing each of these exposures. This is yet another example of how Zcash's clever early protocol design and continuous investment in updating the security stack keep it reliable, even in an age of rapid algorithmic improvement.

Closing Thoughts

Post-quantum-safe rotating transparent addresses are achievable today. The transparent PIR component is coming up in Vizor this week. You can already test its experimental deployment by toggling "Private queries" in settings.

And we achieve full post-quantum safe Transparent pools with hash based signatures in January.