Rewrite Viewing Keys around software that still runs

[pdoxoverflow]

Closes the bounty "Every method on the Viewing Keys page is dead" on the ZecHub bounty board.

The problem

site/Zcash_Tech/Viewing_Keys.md documented three ways to work with a viewing key. All three were dead when I checked on 10 August 2026:

Method on the page | State -- | -- ./zcash-cli z_exportviewingkey / z_importviewingkey | zcashd reached its end-of-support halt on 18 July 2026 Ywallet find-and-import walkthrough, with screenshot | The Wallets page marks Ywallet Ironwood: Not Ready zcashblockexplorer.com/vk | HTTP 503, invalid certificate altname

The page never mentioned Zallet, Zodl, Zingo, Zkool or Ironwood. It is a curated page, so the same content is carried into 18 locales.

What this changes

Export, via Zallet. z_exportviewingkey and z_importviewingkey arrived in Zallet v0.1.0-beta.2 on 28 July 2026, so the page states that minimum version. It documents the UFVK form, the ivk argument for a UIVK, and the three limits the Zallet Book records: Sprout addresses are rejected, a Sapling extended full viewing key cannot be exported from an account that was itself imported as view-only, and the ivk form does work for imported view-only accounts.

Import, via Zkool. Zallet imports Sapling extended full viewing keys only — it will not import a uview… UFVK even though it can export one. Zkool accepts unified viewing keys and Sapling extended viewing keys, so the page pairs the two: export the UFVK from Zallet, import it into Zkool. Both wallets are marked Ironwood: Ready on the Wallets page. Zkool version guidance is 6.26.1 or later, since 6.24.0 added Ironwood support and 6.26.1 fixed Ironwood transaction detection in the mempool.

A new section on viewing keys after Ironwood, answering the question the old page could not: a viewing key issued before Ironwood keeps working after funds migrate. ZIP 326 specifies that a receiver and its corresponding incoming viewing key are scoped to the Orchard protocol rather than to a pool, so the same incoming viewing key trial-decrypts both Orchard-pool and Ironwood-pool note ciphertexts. Zallet's changelog corroborates this at the implementation level. The section also covers ZIP 2005's use_qsk distinction — those are genuinely different keys, and ZIP 326 forbids generating them before NU6.3 activated on Mainnet, so a pre-Ironwood key is necessarily a use_qsk = false key that stays correct for its account — and what ZIP 318 migration looks like to someone watching with a viewing key: many small canonical transactions on a randomised schedule, each revealing the value it moves.

Two disclosure warnings the page was missing. A unified incoming viewing key is account-scoped, so exporting one for a single Sapling address still grants incoming visibility across every pool in the account. And ZIP 326 notes that an adversary with a quantum computer could recover an incoming viewing key from a published diversified address, which is feasible in a way that recovering the nullifier key is not.

A short "what changed" section so readers arriving from search or from a stale translation learn why the commands they were looking for are gone.

Two editorial decisions worth flagging

The ECC block quotes are now paraphrased. The "Why use a viewing key?" section reproduced three paragraphs verbatim from the Electric Coin Company blog. I kept the section and all three use cases, rewrote them in ZecHub's own words, and kept the attribution and links. The framing was the good part of the old page and it is still there.

The stale Ywallet screenshot is removed rather than replaced. /content-images/image-2024-01-13-175554676-8cdf988797.webp is not in this repository, and I did not want to invent a click-by-click walkthrough for a wallet interface I could not verify, since that is roughly how the old page decayed. The Zkool instructions stay at the level its README documents and link out.

Relationship to PR #1905

PR #1905 "docs: expand Viewing Keys article with comprehensive coverage" is open on this same file, unchanged since 27 July. It removes the same three dead sections, but its replacement text still directs readers to zcashd commands for export and contains no mention of Zallet, Zodl, Zingo, Zkool or Ironwood, so it does not resolve the defect this bounty describes. Happy to rebase onto it instead if maintainers would rather land that one first — the substantive content here would need to be re-applied on top either way.

Verification

Run against main @ b1177731.

node translation/check-invariants.mjs --base origin/main
  → Manifest invariants hold: 181 curated pages, 18 locales.
node link-health/check-links.mjs --offline

→ 714 files, 11,133 links, 4 needing attention, 0 new

→ all 5 internal routes in this page resolve

→ repo-wide duplicate URLs down from 271 to 264

Every external link on the page returns 200: ZIPs 310, 318, 326, 2005 and 229, the Zallet Book, the Zallet and Zkool repositories, and both ECC posts.

Two known-failing checks, both pre-existing on main and neither introduced here:

• menu-titles-fresh fails on main today, for Zcash_Tech/FROST_Threshold_Custody.md, Zcash_Tech/The_Turnstile.md and guides/Raspberry_Pi_4_Full_Node.md. This PR keeps the H1 as # Viewing Keys, so it adds no drift, and it deliberately does not touch translation/menu-titles/en.json — the regeneration is already in PR i18n: Curate the 22 Ironwood-era pages missing from the translation system #1944 and doing it here would conflict.
• protected-terms fails on main with 558 missing terms. This PR takes it to 702: 144 new, being 18 locales × 8 terms (Electric Coin Company, NU6, Orchard, ZODL, Zallet, Zingo, Zkool, zebrad), all attributed to the 18 not-yet-retranslated copies of this page. That is the unavoidable consequence of the English source gaining current terminology, and it is the same pattern as the merged Raspberry Pi rewrite (Update Raspberry Pi 4 guide: migrate from zcashd to Zebra/Zal let #1928), which accounts for 72 of the existing 558. detect-staleness.mjs correctly flags the page in all 18 locales, taking the totals from 594 to 612 stale and 162 to 180 high-severity — the right signal for a rewritten curated page.

Closes the bounty ["Every method on the Viewing Keys page is dead"](https://bounties.zechub.wiki/) on the ZecHub bounty board.

The problem

site/Zcash_Tech/Viewing_Keys.md documented three ways to work with a viewing key. All three were dead when I checked on 10 August 2026:

Method on the page State
./zcash-cli z_exportviewingkey / z_importviewingkey zcashd reached its end-of-support halt on 18 July 2026
Ywallet find-and-import walkthrough, with screenshot The Wallets page marks Ywallet Ironwood: Not Ready
zcashblockexplorer.com/vk HTTP 503, invalid certificate altname

The page never mentioned Zallet, Zodl, Zingo, Zkool or Ironwood. It is a curated page, so the same content is carried into 18 locales.

What this changes

Export, via Zallet. z_exportviewingkey and z_importviewingkey arrived in Zallet v0.1.0-beta.2 on 28 July 2026, so the page states that minimum version. It documents the UFVK form, the ivk argument for a UIVK, and the three limits the Zallet Book records: Sprout addresses are rejected, a Sapling extended full viewing key cannot be exported from an account that was itself imported as view-only, and the ivk form does work for imported view-only accounts.

Import, via Zkool. Zallet imports Sapling extended full viewing keys only — it will not import a uview… UFVK even though it can export one. Zkool accepts unified viewing keys and Sapling extended viewing keys, so the page pairs the two: export the UFVK from Zallet, import it into Zkool. Both wallets are marked Ironwood: Ready on the Wallets page. Zkool version guidance is 6.26.1 or later, since 6.24.0 added Ironwood support and 6.26.1 fixed Ironwood transaction detection in the mempool.

A new section on viewing keys after Ironwood, answering the question the old page could not: a viewing key issued before Ironwood keeps working after funds migrate. ZIP 326 specifies that a receiver and its corresponding incoming viewing key are scoped to the Orchard protocol rather than to a pool, so the same incoming viewing key trial-decrypts both Orchard-pool and Ironwood-pool note ciphertexts. Zallet's changelog corroborates this at the implementation level. The section also covers ZIP 2005's use_qsk distinction — those are genuinely different keys, and ZIP 326 forbids generating them before NU6.3 activated on Mainnet, so a pre-Ironwood key is necessarily a use_qsk = false key that stays correct for its account — and what ZIP 318 migration looks like to someone watching with a viewing key: many small canonical transactions on a randomised schedule, each revealing the value it moves.

Two disclosure warnings the page was missing. A unified incoming viewing key is account-scoped, so exporting one for a single Sapling address still grants incoming visibility across every pool in the account. And ZIP 326 notes that an adversary with a quantum computer could recover an incoming viewing key from a published diversified address, which is feasible in a way that recovering the nullifier key is not.

A short "what changed" section so readers arriving from search or from a stale translation learn why the commands they were looking for are gone.

Two editorial decisions worth flagging

The ECC block quotes are now paraphrased. The "Why use a viewing key?" section reproduced three paragraphs verbatim from the Electric Coin Company blog. I kept the section and all three use cases, rewrote them in ZecHub's own words, and kept the attribution and links. The framing was the good part of the old page and it is still there.

The stale Ywallet screenshot is removed rather than replaced. /content-images/image-2024-01-13-175554676-8cdf988797.webp is not in this repository, and I did not want to invent a click-by-click walkthrough for a wallet interface I could not verify, since that is roughly how the old page decayed. The Zkool instructions stay at the level its README documents and link out.

Relationship to PR #1905

PR #1905 "docs: expand Viewing Keys article with comprehensive coverage" is open on this same file, unchanged since 27 July. It removes the same three dead sections, but its replacement text still directs readers to zcashd commands for export and contains no mention of Zallet, Zodl, Zingo, Zkool or Ironwood, so it does not resolve the defect this bounty describes. Happy to rebase onto it instead if maintainers would rather land that one first — the substantive content here would need to be re-applied on top either way.

Verification

Run against main @ b117773.

node translation/check-invariants.mjs --base origin/main
→ Manifest invariants hold: 181 curated pages, 18 locales.

node link-health/check-links.mjs --offline
→ 714 files, 11,133 links, 4 needing attention, 0 new
→ all 5 internal routes in this page resolve
→ repo-wide duplicate URLs down from 271 to 264

Every external link on the page returns 200: ZIPs 310, 318, 326, 2005 and 229, the Zallet Book, the Zallet and Zkool repositories, and both ECC posts.

Two known-failing checks, both pre-existing on main and neither introduced here:

menu-titles-fresh fails on main today, for Zcash_Tech/FROST_Threshold_Custody.md, Zcash_Tech/The_Turnstile.md and guides/Raspberry_Pi_4_Full_Node.md. This PR keeps the H1 as # Viewing Keys, so it adds no drift, and it deliberately does not touch translation/menu-titles/en.json — the regeneration is already in PR #1944 and doing it here would conflict.
protected-terms fails on main with 558 missing terms. This PR takes it to 702: 144 new, being 18 locales × 8 terms (Electric Coin Company, NU6, Orchard, ZODL, Zallet, Zingo, Zkool, zebrad), all attributed to the 18 not-yet-retranslated copies of this page. That is the unavoidable consequence of the English source gaining current terminology, and it is the same pattern as the merged Raspberry Pi rewrite (#1928), which accounts for 72 of the existing 558. detect-staleness.mjs correctly flags the page in all 18 locales, taking the totals from 594 to 612 stale and 162 to 180 high-severity — the right signal for a rewritten curated page.

Unified ZEC address: u1v7g6ngfwurrn3d34tukzlc6lrstn44pwhac7qdeeyl6yje3vrra2cshpuvpm2m9dwga8j3rlqp3fukzslyg5ghmudely7tkwwt909a4tadm0jx4tf0v40phke38degnqwrvzjs5qktqj3ygc9kwpmgnxekfnm2yrh0g4lu7tpywzn25s