There is an important boundary to clarify first when discussing the quantum resistance of $ZEC : the development team has set a January target for signature support, but we cannot yet describe this as a completed quantum-resistant upgrade across all of Zcash. I’m more interested in the gap between the technical proposal and its implementation across the network, and whether the wallet experience can keep pace.
A report on October 9 brought a Zakura engineering article into the discussion. The article’s author, Roman Akhtariev, clearly stated that the team plans to bring post-quantum signature opcodes to Zcash in January. These opcodes are instructions the network uses to check payment authorization. The article discusses a hash-based signature scheme that would provide an alternative authorization path alongside existing elliptic-curve keys. It does not specify an activation height for the mainnet, so January is a team target, not a confirmed completion date.
The value of this work is that it turns a general risk discussion into engineering preparations that can be checked. Going forward, we can look at whether the implementation makes it into an official release, whether reviews are complete, and whether the network adoption rules and wallet support are clear. A target date can help organize the work, but it does not prove that deployment is complete, much less explain what caused the price of ZEC to move. Security preparations and market expectations need separate evidence.
The article focuses on transparent addresses. A standard transparent address first exposes a hash of the public key, and reveals the corresponding public key only when funds are spent; rotating addresses can reduce reuse after the same public key has been exposed repeatedly. Adding signature support concerns the payment-authorization layer. It does not follow that the encryption, proofs, and historical privacy of all shielded transactions receive the same protection at the same time. Different components use different mechanisms, so the scope of the upgrade needs to be checked item by item.
I also wouldn’t interpret “recoverable” as meaning “fully quantum-resistant.” Zcash’s official Ironwood documentation separately explains quantum-recoverable notes and a new pool, while still reusing some structures from the Orchard protocol. This is a reminder that recoverability, signature security, and privacy protection address different problems. Having “quantum” in the name is no substitute for explaining the specific threat and scope of protection.
There is another easily overlooked part of the user experience: even if a wallet generates multiple new addresses, routine balance checks may let a server link them together. PIR, as described in the Zakura article, hides the specific records requested when querying transaction history and balances; transparent transactions remain public on-chain. Protecting query information and concealing transactions are two different things. This tool should not be promoted as making on-chain payments shielded.
The article says that Vizor’s “Private queries” setting can be used to test an experimental deployment. That is an experimental status disclosed by the team; it does not mean that all wallets support it by default or that we have independently verified it in operation. Whether the actual user flow is smooth and the recovery process reliable still needs to be demonstrated by subsequent releases and review results.
The new focus this time is the signature plan and how it relates to address rotation and private queries—not repackaging an old discussion about BTC key risks with a different token. My view is that a clearly stated engineering goal is worth following, but the milestones that actually change the security boundary depend on the official rules and real-world adoption. Next, keep an eye on three things: the signature implementation, mainnet activation requirements, and wallet integration. Any delay or change in scope should update our understanding; a commitment to one month cannot be taken to mean that the entire network is already secure.
A report on October 9 brought a Zakura engineering article into the discussion. The article’s author, Roman Akhtariev, clearly stated that the team plans to bring post-quantum signature opcodes to Zcash in January. These opcodes are instructions the network uses to check payment authorization. The article discusses a hash-based signature scheme that would provide an alternative authorization path alongside existing elliptic-curve keys. It does not specify an activation height for the mainnet, so January is a team target, not a confirmed completion date.
The value of this work is that it turns a general risk discussion into engineering preparations that can be checked. Going forward, we can look at whether the implementation makes it into an official release, whether reviews are complete, and whether the network adoption rules and wallet support are clear. A target date can help organize the work, but it does not prove that deployment is complete, much less explain what caused the price of ZEC to move. Security preparations and market expectations need separate evidence.
The article focuses on transparent addresses. A standard transparent address first exposes a hash of the public key, and reveals the corresponding public key only when funds are spent; rotating addresses can reduce reuse after the same public key has been exposed repeatedly. Adding signature support concerns the payment-authorization layer. It does not follow that the encryption, proofs, and historical privacy of all shielded transactions receive the same protection at the same time. Different components use different mechanisms, so the scope of the upgrade needs to be checked item by item.
I also wouldn’t interpret “recoverable” as meaning “fully quantum-resistant.” Zcash’s official Ironwood documentation separately explains quantum-recoverable notes and a new pool, while still reusing some structures from the Orchard protocol. This is a reminder that recoverability, signature security, and privacy protection address different problems. Having “quantum” in the name is no substitute for explaining the specific threat and scope of protection.
There is another easily overlooked part of the user experience: even if a wallet generates multiple new addresses, routine balance checks may let a server link them together. PIR, as described in the Zakura article, hides the specific records requested when querying transaction history and balances; transparent transactions remain public on-chain. Protecting query information and concealing transactions are two different things. This tool should not be promoted as making on-chain payments shielded.
The article says that Vizor’s “Private queries” setting can be used to test an experimental deployment. That is an experimental status disclosed by the team; it does not mean that all wallets support it by default or that we have independently verified it in operation. Whether the actual user flow is smooth and the recovery process reliable still needs to be demonstrated by subsequent releases and review results.
The new focus this time is the signature plan and how it relates to address rotation and private queries—not repackaging an old discussion about BTC key risks with a different token. My view is that a clearly stated engineering goal is worth following, but the milestones that actually change the security boundary depend on the official rules and real-world adoption. Next, keep an eye on three things: the signature implementation, mainnet activation requirements, and wallet integration. Any delay or change in scope should update our understanding; a commitment to one month cannot be taken to mean that the entire network is already secure.