Post-Incident Node Operator Audit Checklist

When the Zcash security team or a core development group publishes a security advisory, the window for remediation is immediate. This page provides a practical, step-by-step audit checklist for node operators, exchanges, custodians, and mining pools to verify patch application, audit local logs for signs of exploitation, and confirm consensus with the network tip. The checklist is designed to be protocol-agnostic in structure but is tailored here for the specific operational realities of running zcashd and zebrad nodes, including the critical distinction between consensus-critical vulnerabilities and denial-of-service bugs.

The primary operational risk during a Zcash incident is not just a local node crash, but a silent chain split or the acceptance of an invalid shielded transaction. For vulnerabilities like CVE-2019-7167 or CVE-2024-3525, the failure mode is an undetectable inflation bug that the on-chain turnstile mechanism cannot flag. Therefore, the core of this checklist focuses on cryptographic integrity verification: ensuring the running binary matches the patched release, auditing peer-to-peer message logs for anomalous block proposals, and cross-referencing the local chain tip against multiple independent block explorers and a secondary node implementation to detect any consensus divergence.

Infrastructure teams should integrate this checklist into their existing incident response playbooks as a mandatory runbook. The steps are ordered by criticality: first, isolate potentially vulnerable nodes to prevent them from serving invalid data to light wallets or block explorers; second, verify the integrity and version of the patched client; third, perform a post-remediation log audit for any evidence of pre-patch exploitation. Chainscore Labs can assist security teams in stress-testing these procedures through tabletop exercises and by performing an independent review of your node's post-incident state to ensure no invalid state was accepted during the vulnerability window.

After a critical Zcash vulnerability is disclosed—such as the CVE-2019-7167 Sapling counterfeiting bug or the CVE-2024-3525 Orchard flaw—the immediate operational priority shifts from patch deployment to post-remediation verification. The post-incident audit model provides a structured, repeatable checklist that moves beyond simply confirming a binary version string. It requires operators to cryptographically verify that the patched zcashd or zebrad client is actually enforcing the new consensus rules, not just reporting a version number. This model is essential because the most severe Zcash bugs allow undetectable, infinite inflation; a node that fails to enforce the fix can be silently defrauded.

The core of the audit model rests on three pillars: patch integrity, ledger consistency, and network consensus. Patch integrity involves verifying the binary hash against the official Electric Coin Company or Zcash Foundation release signatures, ensuring the running node was not tampered with. Ledger consistency requires operators to replay shielded transaction history using the patched client and confirm that the chain state matches independently maintained checkpoints, particularly for the Orchard and Sapling value pools. Network consensus verification demands comparing the local tip hash and cumulative work against a diverse set of remote peers running different client implementations, guarding against a chain split where the operator's node is isolated on a minority fork that accepts fraudulent transactions.

For exchange and custodian risk teams, the audit model extends to application-layer verification. This includes re-scanning all inbound shielded transactions received since the vulnerability's introduction window to detect any that exploit the specific proof-verification or Merkle-path flaw. Because the turnstile mechanism failed to detect the Sapling inflation bug class, operators cannot rely solely on on-chain value-balance checks. The post-incident audit must include a manual or scripted re-validation of the affected cryptographic proofs against the patched verification logic. Chainscore Labs assists security teams in building these targeted re-scanning scripts and validating that their node infrastructure is enforcing the complete set of post-advisory consensus rules, not just reporting a healthy version string.