Zcash Programmable Locks Paper Gives Only A Plan For Two Proofs

A research group has proposed Zcash programmable locks for the shielded pool, and its own paper is candid about what is still unproven. Strahn Cryptography posted the announcement to the Zcash Community Forum on October 21 at 18:08 UTC. Behind it sits a paper that proves one core piece in Lean 4 and gives only a proof plan for two others.

What the Zcash programmable locks post claims

Forum readers get "programmable composable locks" for shielded Zcash. Conditions listed include revealing a witness, revealing the preimage of a hash, and reaching a certain time or block height. A decryption-key condition is still in development. Funds stay recoverable when all parties work together.

Its author calls the design "(mostly)" shielded and "fully anonymous." A footnote explains the "mostly." Some conditions leak the existence of a lock and the moment it is spent. That goes away, the authors say, if one ZIP is clarified and another passed. They point to ZIP 68 and an open ZIP 203 issue on lock times.

Abstract of the paper, Violet's Constrained Locks, 2026/0002. Source: swiss papers, paper 2026/0002.

How the paper builds a Zcash lock

Per the abstract, Zcash programmable locks work like this. Two parties jointly control a shielded address created through a FROST key generation. They agree offline on which transactions may spend from it. A lock's conditions come from composition, not from code on the chain. Zero-knowledge proofs constrain the outputs of the predicted transaction.

What releases the lock depends on the signing scheme. Plain FROST is one choice. Another is preFROST, a threshold adaptor signature, and a third is hashFROST, which ties the adaptor to a hash preimage. Transaction format v6, introduced in NU6.3 alongside the Ironwood pool, lets the scheme predict spends of notes that are not yet on chain.

A forum reply from the author adds detail. Only the transaction endpoints run on chain, as reduced Schnorr signatures, much as FROST already works. Most computation stays off chain. Zcash has no other contracts at present, the reply notes.

Where the paper marks its own limits

Two sentences in the abstract matter most. The authors prove the algebraic core in Lean 4 with Mathlib and give reductions for most of the rest. For the unforgeability of preFROST and hashFROST, they give "only a proof plan." An appendix lists the status of every claim.

A second limit concerns consensus. Under current rules, the paper says, the lock time of a shielded-only transaction is not enforced. It uses a transparent state output as an interim measure and proposes a consensus change.

What is already on testnet

Three example transactions are linked from the post, all on the Zcash testnet. One sets up a hash lock with a Poseidon hash, one claims it by revealing the preimage, and one refunds it. Setup shows on the cipherscan explorer in block 4,526,227 at 17:22:59 UTC on October 21. Its page lists 0.0002 TAZ leaving the Ironwood pool for a transparent address.

Setup transaction on the Zcash testnet explorer. Source: cipherscan testnet transaction.

Authors call the paper preliminary, so Zcash programmable locks remain a proposal and not a feature of the network. A vcl crate and machine-checked proofs are promised soon. Companion papers cover a Lightning-style channel and streaming payments.