Zcash Shielded News is a community article format based on the weekly Zcash Ecosystem Digest Newsletter.
Providing insight on current events and informing the community about important news in the Zcash ecosystem.
Check out the best Highlights below!
📅 Subscribe to the Zcash Event Calendar!
💡 Fact of the Week
OpenZcash is a public transparency dashboard that lets anyone explore how the Zcash Dev Fund is allocated and spent.
Instead of grant information being scattered across spreadsheets and meeting records, OpenZcash brings together ZCG and FPF accounting, the live Lockbox, grant payments, recipients, proposals, and governance data in one searchable place. The site currently tracks 176 approved ZCG projects and more than $22 million distributed.
It shows how open data can make decentralized funding easier to follow, giving the Zcash community a clearer view of where/how funding is allocated.
📩 In today’s edition:
🦓 Zebra 6.0.0 Release Candidate 0
• Zebra 6.0.0-rc.0 adds NU6.3 “Ironwood” Testnet support, security fixes, signed reproducible releases, pre-built Linux binaries, and an in-place state database upgrade with no resync required.
✅ NU6.3 Ironwood Testnet is Live!
• Ironwood consensus changes are implemented and under audit, with NU6.3 now live on Testnet and ZecRocks infrastructure ready for wallets and developers to begin testing.
🗳️ ZCG Election Results are in
• GGuy and Paul Brigner were elected to the Zcash Community Grants committee, finishing first and second in a competitive 14-candidate ZCAP election.
🧰 Sovright Announces Argos Tool
• Sovright launched Argos, a recovery workspace for legacy ZecWallet Lite seeds that scans for shielded funds and has completed an independent Least Authority security audit.
⛏️ Zcash Max Supply 80% Mined
• More than 80% of Zcash’s 21 million maximum supply has now been issued, bringing greater attention to the proposed solutions for Zcash long term security.
🛠️ Introducing zecd Wallet
• Zec.rocks introduced zecd, a production-ready, open-source wallet daemon built to help businesses move away from zcashd using Bitcoin-style RPCs and direct communication with Zebra.
Zebra 6.0.0 rc-0 🦓
Zebra 6.0.0-rc.0 has been released, bringing the first release candidate for the next major version of Zebra. The update adds Testnet support for the NU6.3 “Ironwood” network upgrade, along with security hardening, performance improvements, new operator tooling, and changes to Zebra’s release infrastructure. The release is primarily aimed at Testnet operators ahead of the final 6.0.0 release.
Key updates:
NU6.3 “Ironwood” support: Zebra now supports the Ironwood shielded pool and v6 transactions on Testnet. RPC methods including
z_gettreestate,z_getsubtreesbyindex, and verbosegetblockhave been extended to expose the Ironwood note commitment tree and subtree roots after activation.State database upgraded without a resync: the database format has been bumped to 28.0.0 to support Ironwood. Existing nodes can migrate their state in place, with no blockchain resync required. The migration adds the Ironwood note commitment tree, new database columns, and Ironwood value-pool tracking.
Reproducible and signed releases: Zebra’s release Docker images are now reproducible, allowing independent builds from the same commit to produce the same binary. Production images also include Cosign signatures, signed build provenance, and a signed SBOM, making it easier to verify that releases came from Zebra’s CI infrastructure.
Pre-built Linux binaries: official
zebradbinaries are now attached to GitHub releases for x86_64 and aarch64 Linux systems. Operators can run Zebra without Docker or compiling from source, with support for installation throughcargo binstall zebrad. Release archives include checksums, build-provenance attestations, and signatures.Zebra-mined blocks are now identifiable: Zebra places a 🦓 in the coinbase input of every block it mines. As part of this change, the configurable
mining.extra_coinbase_datafield is now limited to 86 bytes.Sync and chain handling fixes: a transaction verification timeout near the chain tip is now treated as a missing input rather than an internal error, preventing a possible sync stall. Zebra also fixed several
invalidateblockandreconsiderblockedge cases that could previously cause panics.Mining performance improved:
getblocktemplatenow caches the generated coinbase transaction for each block. Repeated short-poll requests no longer rebuild it, preventing CPU saturation and multi-second template delays when mining to Sapling or Orchard addresses.Indexer and reorganization tooling: co-located indexers such as Zaino can follow Zebra more efficiently without repeatedly re-streaming the full non-finalized state. New state APIs also allow clients to find the fork point between their known chain locator and Zebra’s current best chain.
New operator features: Zebra now supports a
block_notify_commandoption that runs whenever the best chain tip changes, similar to zcashd’s-blocknotify. Read-only database access also produces clearer errors when the configured state directory is unavailable or invalid.Security hardening: RPC cookie authentication now uses constant-time comparison. Zebra also closes a mempool accounting bypass where peers could push full transactions directly to avoid per-peer download limits, and fixes a
getblockRPC panic affecting blocks outside the best chain.Additional maintenance: the release updates Zebra to the NU6.3 pre-release wave of
librustzcashcrates, fixes a Rust security advisory by updatinganyhow, improves Regtest configuration, and ensures released binaries report their exact source commit.
The release marks a major step toward NU6.3 and Zebra 6.0.0, while also making the node easier to install, verify, operate, and integrate with mining and indexing infrastructure. Testnet operators are encouraged to test the release candidate ahead of the final version.
NU6.3 Ironwood Testnet is Live! ✅
Ironwood activated on Testnet at height 4,134,000, introducing a new shielded pool and the v6 transaction format. No Mainnet activation height has been configured yet.
Over the last few weeks, significant progress has been made toward activating NU6.3 “Ironwood” on Zcash. According to Sean Bowe, the core consensus work is now implemented, auditing is well underway, and the specifications and ZIPs are approaching their final state.
The upgrade is now moving from development into deployment. An official Mainnet activation height is expected soon, with the teams working toward readiness for an activation around July 21. In parallel, NU6.3 has now been deployed on Zcash Testnet infrastructure operated by ZecRocks, giving wallets and developers a live environment for testing Ironwood transactions!
Key updates:
Consensus implementation is complete: all planned consensus rule changes for Ironwood have been implemented and have been undergoing auditing. The related specifications and ZIPs have also been published and are nearing their final form.
Mainnet activation is approaching: a formal activation height has not yet been announced, but the current expectation is that the ecosystem should be technically ready for an activation around July 21.
Ironwood is now live on ZecRocks Testnet:
testnet.zec.rocksis now serving NU6.3 transactions, providing wallet developers and other ecosystem participants with infrastructure for testing the upgrade in a live network environment.Updated lightwalletd infrastructure: the ZecRocks Testnet deployment is currently running an Ironwood-compatible
lightwalletdbranch, allowing compatible wallets and applications to interact with NU6.3 transactions ahead of Mainnet activation.Zebra support is part of the rollout: the Testnet activation is being coordinated with Zebra support for NU6.3, giving node operators and developers the software needed to participate in testing the new consensus rules and transaction format.
Hashrate is signalling technical readiness: sufficient mining hashrate is already signalling readiness for the Mainnet upgrade. The primary remaining ecosystem concern is not consensus support, but whether every wallet will be prepared in time.
Wallet readiness remains the main outstanding issue: some wallets may not complete their upgrade work before activation. Bowe argues that this should not delay Ironwood, as users are expected to have adequate alternatives and wallet teams will have time to test against the activated Testnet.
Supply integrity remains a major focus: the prompt and safe activation of Ironwood is considered important for Zcash users, while formal verification work continues in parallel to provide additional assurance around supply integrity. More details on that work are expected separately.
Broad ecosystem coordination: teams including Valar and Zodl have been heavily involved in the activation effort, alongside engineers, infrastructure operators, wallet developers, and other ecosystem partners.
ZCG Election Results Are In! 🗳️
The June 2026 Zcash Community Grants election has concluded, with GGuy and Paul Brigner elected to fill two seats on the Zcash Community Grants Committee. The ZCAP poll closed with 14 candidates standing for election and strong participation from across the Zcash community.
GGuy finished first with 76 votes, while Paul Brigner secured the second available seat with 58 votes. Both will join the committee effective July 1, with GGuy continuing his involvement and Brigner beginning his new term.
Key updates:
GGuy elected with the highest vote total: GGuy received 76 votes, representing 76.8% of participating voters, placing first in the election and securing a seat on the committee.
Paul Brigner takes the second seat: Brigner received 58 votes, or 58.6%, making him the second successful candidate and confirming his place on the ZCG committee from July 1.
Ready Mouse: Mylo Bennett, standing as Ready Mouse, received 40 votes, or 40.4%, placing third in a competitive field.
Palmar and T.S.: Palmar received 24 votes, while T.S. of VASPHoldings received 20, followed closely by Aesobar with 19 votes.
Broad field of candidates: the election featured 14 candidates, with votes also cast for Valens, Daniel Goh, Dontbeevil, M.F., Decentrathai, Victor Zscharnt, Groggs, and USCMigs.
GGuy continues his committee service: the result represents a continuation of GGuy’s involvement with Zcash Community Grants and reflects strong support from ZCAP members for his ongoing work.
Paul Brigner joins the committee: Brigner will take up his position on July 1, bringing a new member onto the grants committee following the conclusion of the previous term.
Service recognised: thanks were extended to Decentralistdan for his work during the previous term, alongside recognition of GGuy’s continued commitment to the committee.
Strong community participation: the range and quality of candidates was highlighted as evidence of an active and engaged Zcash community, with each candidate contributing to a competitive election.
SIV supported the voting process: the SIV team was thanked for its continued role in helping administer ZCAP polls and support the election process.
ZCAP members determined the result: the election ultimately reflects the participation of ZCAP members who cast their votes and selected the committee’s two incoming representatives.
The result confirms GGuy and Paul Brigner as the two successful candidates. Their terms begin on July 1, as Zcash Community Grants enters its next committee period.
Sovright Announces Argos Tool 🧰
Sovright has released Argos Rescue Wallet, a desktop recovery workspace designed for people who still have a legacy ZecWallet Lite 24-word seed phrase but no longer have a working wallet environment. Argos validates the seed locally, scans historical Zcash activity, identifies funds associated with addresses derived from the seed, and guides the user through sweeping recoverable funds to a modern Zcash Unified Address.
Sovright@sovright_
Since 2022, some @Zcash holders have been locked out of their own funds, as ZEC was left stranded in an early wallet client that went unmaintained. No one came back to fix it. Until now. Today we're announcing Argos: a free tool to recover ZEC stranded in old ZecWallet Lite
11:03 AM · Jul 1, 2026 · 5.65K Views
1 Reply · 1 Repost · 22 Likes
Key updates:
Built specifically for ZecWallet Lite recovery: Argos is designed for users who still have their original 24-word ZecWallet Lite seed but cannot access a functioning legacy wallet. It does not require the original wallet database file, making the seed itself the starting point for recovery.
Scans every address derived from the seed: older ZecWallet Lite wallets could use multiple addresses, meaning funds may not appear when the same seed is imported into a newer wallet that derives only a single address. Argos scans historical wallet state to find activity associated with addresses generated from the legacy seed.
Supports multiple Zcash pools: the recovery process can identify funds across transparent, Sapling, and Orchard addresses derived by ZecWallet Lite. Sprout is not supported because ZecWallet Lite did not derive Sprout keys from its seed format.
Recovery happens through a guided desktop flow: users enter their seed, choose a starting date or block height, allow Argos to scan the blockchain, review the recovered balances, and then sweep the funds to a new wallet. The destination address, network fee, memo, and outputs remain visible before the final transaction is broadcast.
Sensitive operations remain local: the Argos website is only a download page and never accepts seed phrases. Seed validation, key derivation, blockchain scanning, transaction signing, and other sensitive operations take place inside the locally installed desktop application.
Uses a Rust core with desktop and command-line interfaces: Least Authority describes Argos as consisting of a Rust-based core library, a command-line interface, and a graphical interface built with Tauri. Its recovery process performs large-scale trial decryption against Zcash blockchain data to identify transactions belonging to the user.
Independently audited by Least Authority: Sovright commissioned Least Authority to perform a security audit of Argos, with the final report completed on June 29, 2026. The Argos website states that every issue and suggestion in the final audit report has been marked resolved.
A public lightwalletd connection is required: Argos downloads public Zcash block data from a
lightwalletdserver, so the recovery process cannot run fully air-gapped. According to Sovright, the seed remains on the local computer; public block data comes in and only the final sweep transaction is sent out.Long scans can be resumed: Argos stores scan progress in a local workspace as it runs. If the application is closed or the machine crashes, the recovery can continue from the saved state rather than starting the full blockchain scan again.
Recovery time depends on wallet history: users can choose how far back Argos should scan by selecting a date or block height. An earlier starting point provides a more thorough search but takes longer, while older or more active wallets may require several hours to complete.
Funds are swept to a fresh modern wallet: after balances have been identified, users review and send the recovered ZEC to a Unified Address they control. Sovright recommends retiring the old ZecWallet Lite seed permanently after recovery rather than continuing to use a seed that has been entered into a general-purpose computer.
Available across major desktop platforms: Argos provides desktop releases for macOS, Windows, and Linux, with the project source and releases also available through GitHub. Sovright advises users to install the application on a trusted machine and match their security precautions to the value of the funds being recovered.
Recovery is free with optional support for development: there are no accounts or subscription fees. During the final sweep review, users may optionally donate a percentage of recovered funds to Sovright, with both the recovery destination and donation output shown before confirmation.
Zcash Max Supply 80% Mined ⛏️
Zcash has crossed a major monetary milestone: more than 80% of the maximum 21 million ZEC supply has now been issued. In a post from ruZcash chain data shows a total chain value of 16,806,723 ZEC, equal to just over 80.03% of the nominal supply cap.
#prozcash 🦓🛡♥️@ruZCASH
Реально ли, что в целом X никто даже не отметил, что #Zcash пересёк 80% эмиссии на днях? Тогда я, возможно, буду первым. 4/5 эмиссии $ZEC добыто. Поздравляю!
11:37 AM · Jul 6, 2026 · 12.3K Views
7 Reposts · 42 Likes
That means 4/5 ZEC that can exist have already entered the network, leaving roughly 4.19 million ZEC remaining. The milestone also comes as work continues on the Network Sustainability Mechanism, a Shielded Labs proposal designed to address the long-term security of Zcash as new issuance declines. You can compare the different proposals using Zooko’s simulator.
Key updates:
Zcash has passed the 80% mark: the supplied chain data reports 16.806 million ZEC in total chain value. Against the protocol’s 21 million ZEC maximum, that places issuance at approximately 80.03%. ZIP 234 defines
MAX_MONEYas 21 million ZEC for the proposed sustainability mechanism.Around 4.19 million ZEC remains under the cap: crossing 80% means slightly less than one-fifth of the maximum supply remains available for future issuance. Because the issuance rate declines over time, however, the final 20% is designed to take far longer to issue than the first 80%.
The milestone is easy to overlook: unlike a halving or network upgrade, crossing 80% does not require a consensus change or a specific announcement. It is simply the point at which cumulative issuance moves beyond 16.8 million ZEC, making it an important monetary milestone even though the network continues operating normally.
Zcash currently follows a halving-based issuance schedule: the existing system reduces block subsidies in large steps at roughly four-year intervals. The Zcash supply simulator visualizes cumulative supply, daily issuance, and halvings across the chain, showing how total supply continues rising while the rate of new issuance falls over time.
The remaining supply will be issued increasingly slowly: simulator models show the historical issuance function block by block and shows the effect of repeated halvings on new supply. The supplied issuance chart similarly illustrates the staircase pattern, with issuance and inflation dropping sharply at each halving rather than declining gradually.
Declining issuance raises a long-term security question: Zcash, like Bitcoin, currently relies heavily on block rewards to compensate the participants securing the network. As subsidies fall, the question becomes how to maintain a sustainable security budget without abandoning the fixed supply cap. Shielded Labs says the NSM is designed specifically to address this challenge.
The Network Sustainability Mechanism keeps the 21 million cap: rather than proposing unlimited tail emissions, the NSM would allow ZEC to be removed from circulation and placed back into the network’s effective reserve, from which it could later return through future block rewards. The overall
MAX_MONEYlimit remains unchanged.Burned ZEC could support future network security: under the proposed mechanism, ZEC deliberately removed from circulation would not simply disappear from the monetary system forever. It would increase the amount remaining in the Money Reserve, allowing future issuance to continue at a slightly higher rate while still respecting the 21 million cap.
ZIP 234 replaces abrupt halvings with a smooth curve: the draft proposal would calculate each block subsidy as a fixed fraction of the ZEC remaining in the Money Reserve. Instead of large four-year subsidy cuts, issuance would follow a continuous exponential decay curve designed to remain similar to Zcash’s historical monetary schedule.
The design keeps an approximate four-year half-life: under ZIP 234, roughly half of the Money Reserve at the beginning of a four-year period would be issued over the following four years, assuming no additional ZEC is removed from circulation. The goal is to preserve the broad shape of the existing halving model without the sudden subsidy cliffs.
Burning ZEC effectively moves issuance into the future: Shielded Labs gives a simple example: burning 1 ZEC today would result in roughly 0.5 additional ZEC being available for issuance over the next four years, another 0.25 ZEC over the following four years, and progressively smaller amounts thereafter.
The broader NSM is built around three proposals: ZIP 233 establishes a mechanism for removing ZEC from circulation, ZIP 234 smooths issuance so that the reserve can be reintroduced predictably, and ZIP 235 proposes burning a portion of transaction fees. Together, they are intended to create a foundation for long-term network sustainability without increasing the maximum supply.
The simulator helps show why smoothing matters: the public Zcash Supply & Issuance tool calculates the current block issuance function across millions of blocks and plots cumulative supply, issuance per day, and halving events. The NSM work uses similar simulations to compare the existing staircase schedule with a smoother reserve-based model.
The proposal is about timing issuance, not creating more ZEC: ZIP 234’s central idea is that the network can change when remaining or burned ZEC is issued without changing the 21 million ceiling. This creates a mechanism for shifting some monetary resources toward the network’s future security rather than exhausting the available subsidy on the existing schedule.
The milestone makes the long-term discussion increasingly relevant: with more than 4/5 of the nominal maximum supply already issued, Zcash is moving deeper into the part of its monetary history where new issuance becomes progressively scarcer. Shielded Labs argues that building sustainability mechanisms before the security budget becomes an urgent problem gives the network more time to test and refine them.
Introducing zecd Wallet 🛠️
Zec.rocks has introduced zecd, an open-source Zcash wallet daemon built for businesses and infrastructure operators that need to move away from zcashd. Originally created to power Overpay.com, zecd is already running in production and was open sourced as the timetable for zcashd deprecation accelerated.
The project draws on Zec.rocks’ experience operating global Zcash infrastructure handling millions of wallet requests per day. Rather than reproducing zcashd, zecd takes a simpler approach: it uses familiar Bitcoin Core-style RPCs, communicates directly with Zebra, and keeps the wallet recoverable from a seed.
Key updates:
Built as a zcashd alternative for integrators: zecd is aimed at businesses, payment services, exchanges, and other server-side users that need a maintained wallet backend without waiting for a direct
zcashdreplacement.Already used in production: Zec.rocks originally built zecd for Overpay.com and began using an early version in production in January. The project is therefore being released as working infrastructure rather than an early prototype.
Uses Bitcoin Core-style RPCs: method names, response formats, authentication, and error handling generally follow
bitcoind, making the interface familiar to many infrastructure developers. Additionalz_*methods are included where shielded Zcash functionality requires them.Connects directly to Zebra: zecd communicates with a self-hosted
zebradnode over JSON-RPC. It does not requirelightwalletd, its own P2P network, or a separate full-chain index.Intentionally leaves zcashd compatibility behind: zecd does not support the
zcashdwallet RPC interface orwallet.dat. Existingzcashdusers must move funds on-chain to a zecd address rather than importing an old wallet database.Wallet state is recoverable from the seed: there is no permanent
wallet.dator keypool. The local data directory is treated as a disposable cache, while the mnemonic can be used to rebuild the wallet and recover shielded funds.Uses one account with diversified addresses: zecd uses account 0 and generates fresh diversified Unified Addresses through
getnewaddress. Zec.rocks says this simplifies recovery and enables faster, more predictable synchronization.Designed for cloud infrastructure: the daemon includes health and readiness endpoints, structured JSON logs, environment- or file-based secrets, reproducible container builds, and deployment patterns intended for horizontal scaling.
Available with a complete Docker stack: the repository includes a ready-made Zebra and zecd deployment, using Testnet by default. Operators can start Zebra, initialize a wallet, launch the daemon, and query it through JSON-RPC.
Can also run directly from source: users with a local Zebra node and Rust environment can build zecd without Docker, initialize a 24-word mnemonic, and interact with the wallet using standard Bitcoin RPC client libraries.
Seed-compatible with the wider Rust Zcash ecosystem: while zecd is not compatible with
wallet.dat, it is designed aroundlibrustzcashwallet primitives, giving it compatibility with other wallets using the same underlying seed standards.Built on existing Zcash engineering work: Zec.rocks credits the
librustzcash,zcash-devtool, Zebra, Zallet, and Zaino projects as foundations that made zecd possible.