ZecSafe is a hackathon proof-of-concept. It is not audited production custody software and must not be used to secure real funds.

ZecSafe is a hackathon proof-of-concept using re-randomized FROST tooling. The referenced NCC audit of the ZF FROST repository did not include rerandomized FROST. ZecSafe is not presented as audited production custody software.

Public repository files may contain:

• public proof fingerprints;
• public transaction id;
• public status words;
• public tool commit references;
• public-safe ProofEvent projections;
• documentation and screenshots.

Public repository files must not contain:

• seed phrases or spending keys;
• UFVK/FVK values;
• FROST signing shares;
• participant private configs;
• contact tokens or TLS private keys;
• raw PCZT bodies;
• raw SIGHASH bytes;
• raw aggregate signatures;
• Orchard action randomizers;
• nonces;
• wallet databases or private run logs.

The local security scan is:

npm run security:scan

The public proof data-classification test is:

npm run test:proof-data

ZecSafe does not describe the coordinator as privacy-blind.

In the ZIP 312 threat model:

• the coordinator is trusted with transaction privacy and unlinkability;
• key-share holders are also trusted with transaction privacy and unlinkability;
• share holders can link a signing operation to a transaction;
• network privacy is outside ZIP 312;
• ZecSafe does not claim to remove these risks.

The public proof route therefore shows fingerprints and status labels only. Raw PCZT, raw signing material, shares, nonces, randomizers, viewing keys, and wallet data stay outside the public proof.

Zcash validates the resulting spend authorization normally. FROST provenance is evidenced by the recorded ZecSafe/FROST signing session; the chain does not expose a special FROST marker.

The fixed runner is local-only and uses an operation allowlist. It rejects arbitrary binaries, path traversal, shell metacharacters, oversized or invalid run IDs, and non-local host execution. It redacts signing-secret-shaped output.

Coverage is in:

npm run test:runner

Covered classes include command injection, path traversal, arbitrary binary rejection, run-ID validation, local-only host enforcement, output redaction, and no-spawn behavior for rejected path payloads.

The proof verifier binds the public proof to:

• run ID;
• group fingerprint;
• PCZT fingerprints;
• selected signer set;
• intent commitment;
• txid;
• binding status.

Coverage is in:

npm run test:proof
make judge-proof-mainnet-tamper

Semantic mutations of txid, threshold, group fingerprint, selected signer, intent commitment, PCZT fingerprint, and binding status must fail.

ZecSafe uses these status meanings:

broadcast command accepted/txid returned -> SUBMITTED
network observer sees transaction        -> OBSERVED
block inclusion recorded                 -> MINED
confirmation rule satisfied              -> CONFIRMED
broadcast/network rejection              -> REJECTED
observer unavailable                     -> UNKNOWN

UI timers must not create mainnet truth. The W4 proof replay reducer tests assert that no txid, no chain observation, or no confirmation prevents broadcast success.

npm run test:demo-proof-state

Open a private issue or contact the project maintainer before publishing details if a bug could expose keys, shares, private run material, or incorrect proof verification.

The recorded mainnet run used signer_review_mode: semantic_pczt_review, now recorded inside the hash-covered proof bundle.

Selected signers checked PCZT semantics and compared the prepared, pinned-tool SIGHASH fingerprint. They did not independently recompute the SIGHASH. ZecSafe does not claim independent_sighash.

Consequence: SIGHASH derivation is trusted to the pinned tooling. A compromised pinned tool, combined with a malicious coordinator, is inside the trust boundary for that derivation and would not be caught by semantic review alone.

A binding_status: PASS means the PCZT spends what the human reviewed. It does not prove that the FROST group key is the PCZT action's spend-authorization key — the pinned PCZT inspect path does not expose a FROST group fingerprint.

That linkage comes from the pinned signer library verifying the aggregate signature against the action's rerandomized verification key at apply time, and from Zcash consensus accepting the shielded spend. Do not read a Binding Firewall PASS as the cryptographic linkage; they are separate claims.