Faster blocks and covenant-settled applications: evidence from DeFi, ZK, and privacy
I work on CashNotes (formerly BCH Cloak), a private note transfer protocol for Bitcoin Cash. Comparing its settlement model with Zcash highlighted where block time matters for covenant applications.
This is not an argument about payment UX generally. It is specifically about applications whose state transitions depend on confirmed covenant spends.
1. Covenant spends don’t get the usual zero-conf protections
BCH payments can often be accepted quickly because nodes relay double-spend proofs when conflicting spends appear. Bitgree, for example, waits four seconds for a proof before accepting.
But DSProof only covers transactions whose inputs are P2PKH with SIGHASH_ALL. The proposed ZCE has the same P2PKH-only constraint.
Covenant spends therefore sit outside that protection: AMM swaps, contracts that verify proofs, private note transfers, and other contract state transitions. For those cases, the DSProof specification’s guidance is to “wait for confirmation”.
The issue compounds when applications chain transactions, where each stage spends the output of the previous stage. If an earlier transaction is replaced, later stages disappear with it.
| Block interval |
1 confirmation: typical |
1 in 20 waits longer than |
3 chained confirmations: typical |
1 in 20 waits longer than |
| BCH today, 10 min |
6.9 min |
30 min |
27 min |
63 min |
| BCH at 1 min |
42 s |
3.0 min |
2.7 min |
6.3 min |
| Zcash today, 75 s |
52 s |
3.7 min |
one transaction |
one transaction |
| Zcash NU7, 25 s |
17 s |
75 s |
one transaction |
one transaction |
For covenant applications, the practical rule is roughly:
settlement latency ≈ number of sequential confirmed stages × block interval
There is an important distinction between confirmation count and accumulated work. The CHIP’s security analysis specifies one tenth the chainwork per block while preserving approximately the same chainwork accumulation per unit time. Ten one-minute blocks therefore accumulate approximately the work of one current ten-minute block.
That means one-minute blocks provide earlier, smaller increments of confirmation rather than making ten minutes of accumulated proof of work arrive sooner.
Effect of 1-minute blocks: strongly helpful when an application benefits from earlier confirmations; neutral where it requires the same accumulated chainwork as today.
2. Zero-knowledge applications
ZK applications can require multiple covenant transactions because verification and subsequent state transitions must fit BCH transaction and unlocking script limits.
There are two ways to reduce that latency:
- reduce the number of required transactions;
- reduce the time between confirmations.
New opcodes could eventually reduce transaction count, but CHIP-2025-05 covers secp256k1 arithmetic and leaves pairing and STARK verification to separate proposals.
Until then, block interval directly limits sequential covenant state transitions. A state machine that requires each parent to confirm can advance about six times per hour at ten-minute blocks versus about sixty times per hour at one-minute blocks.
The main concern is orphan rate. The CHIP estimates 0.41–1.94% at one-minute blocks.
Zcash offers a useful comparison. Zakura reported roughly 30% orphan rates during testing with 25-second blocks because proofs were being verified twice. After reusing mempool verification results, the rate fell to about 3.6% (Zakura 1.2.0).
BCH Node already caches script validation results from mempool admission and reuses cached results during block validation.
The remaining case I would like to see tested is blocks containing expensive transactions that verify proofs and that nodes have not already validated through their mempools. The CHIP considers this attack surface and argues that BCH’s VM limits and signature check limits bound worst case validation cost. It also scales maximum block size from 32 MB to 3.2 MB along with the shorter interval.
Those are useful analytical arguments, but Chipnet could provide empirical evidence that validation and propagation behave as expected when blocks contain significant amounts of proof verification.
Effect of 1-minute blocks: helpful for ZK applications because they reduce sequential settlement latency. Whether transactions requiring expensive proof verification impose a meaningful validation penalty at the shorter interval is a specific question that can be tested.
3. Proving time
Faster blocks do not make zero-knowledge proofs faster. They only reduce the confirmation delay after proving.
Zcash wallet developers report shielded proving times of roughly 142–550 ms on phones.
That distinction matters:
- if proving completes well within a minute, block time dominates user visible settlement latency;
- if proving or batching takes several minutes, reducing block time has less impact.
For a BCH application that proves quickly, a typical one confirmation wait falls from about 6.9 minutes to 42 seconds.
Effect of 1-minute blocks: helpful when proving is already fast; increasingly neutral as proving or batching becomes the dominant source of latency.
4. Competitive position versus Zcash
Zcash currently uses 75-second blocks, giving a typical one block wait of about 52 seconds.
NU7 moves to 25-second blocks and has been live on public testnet since 5 October 2026, with mainnet targeted for 5 November.
Its proposed Project Tachyon would allow block producers to aggregate shielded transactions without user coordination.
CashNotes uses a related model without a consensus change: users prove locally, then permissionless aggregators batch proofs and settle them through covenants. The difference is where aggregation occurs:
- Zcash aggregation can settle within block production;
- BCH aggregation may require multiple sequential covenant transactions.
For a three-stage BCH settlement:
- 10-minute blocks: ~27 minutes typical;
- 1-minute blocks: ~2.7 minutes typical.
That does not match a one block Zcash settlement, but it moves BCH from an order of magnitude disadvantage toward a difference of minutes.
Effect of 1-minute blocks: clearly helpful competitively. They do not erase Zcash’s latency advantage, especially at 25-second blocks, but they substantially narrow it for covenant privacy and proof applications.
Conclusion
For conventional BCH payments, faster blocks are less important because zero confirmation mechanisms already provide useful payment UX.
For covenant applications, the situation is different. DSProof and proposed ZCE protections do not cover covenant spends, and many applications require sequential confirmed state transitions. In those systems, block interval becomes application latency.
Moving from ten-minute to one-minute blocks would:
- reduce a typical confirmation from about 6.9 minutes to 42 seconds;
- reduce three sequential confirmations from about 27 minutes to 2.7 minutes;
- increase confirmation dependent state update capacity from roughly 6 to 60 updates per hour;
- substantially narrow BCH’s latency disadvantage for covenant privacy, DeFi, and ZK applications.
The security tradeoff is narrower than simply saying that faster blocks provide less security. The CHIP preserves approximately the same chainwork accumulation per unit time while dividing it into ten smaller increments: one tenth the chainwork per block and one tenth the maximum block size.
Its security analysis argues that most relevant properties scale with those changes. It also identifies effects that do not scale perfectly, particularly fixed network latency and the resulting propagation races.
That is the part I would like to see examined adversarially and tested on Chipnet. The question is not whether ten one-minute blocks contain roughly the same accumulated work as one ten-minute block; they do. The question is whether dividing block production into smaller, more frequent increments introduces practically significant behavior that the current analysis or assumptions do not capture.
Position: neutral, but strongly interested in being convinced
My incentives as an application developer point strongly toward one-minute blocks.
My goal with CashNotes is to make private payments and applications using cryptographic proofs on BCH competitive with what can be built on any chain. From that perspective, reducing settlement that depends on confirmations from tens of minutes to minutes or seconds would be a significant improvement.
What keeps me neutral today is narrower: I want stronger evidence that the change in block cadence and chainwork per block does not introduce a meaningful security disadvantage that outweighs those benefits.
The CHIP provides a substantial analytical case that security per unit time is preserved and it bounds several specific attack vectors. I would like to see that analysis subjected to adversarial review and, where possible, empirical testing, particularly around propagation, orphan behavior, and blocks containing transactions that require expensive proof verification.
If that evidence supports the CHIP’s security analysis, my position would move from neutral to strongly in favor. The application benefits are already clear to me; the remaining question is whether the security assumptions continue to hold under adversarial conditions and workloads involving substantial proof verification.
Sources are linked inline. The waiting times are closed form calculations from exponential and Erlang distributions, and I’m happy to share the script.
Disclosure: I drafted this with AI assistance, then reviewed, edited, and verified the arguments and figures against the sources linked above.
Still plenty of work to do, but it can and must be done. Beyond the UX gains, all Satoshi-derived nodes will continue to require security hardening this year, and spreading out confirmed throughput by 10× would meaningfully harden node security and tx censorship resistance.
