# Proposal: Lower Zcash block target spacing to 25s **URL:** \ **Category:** Technology\ **Created:** [February 6, 2026, 10:06am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577 "2026-02-06T10:06:46Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Mohak](https://avatars.discourse-cdn.com/v4/letter/m/5f9b8f/32.png) [@Mohak](https://forum.zcashcommunity.com/u/Mohak)\ **Post date:** [February 6, 2026, 10:06am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/1 "2026-02-06T10:06:46Z")
# Proposal: Lower Zcash block target spacing to 25s This post proposes we lower the ZCash network block target spacing from 75s to 25s in a small upgrade this year. The aim is to start discussion on the metrics, benchmarks and improvements required to make this happen. Zcash faces a few performance bottlenecks limiting its path to serving billions, the two from consensus are: 1. **Transaction inclusion time** : Users wait on average 75 seconds for block inclusion, regardless of network utilization. This causes delays to every usecase: private payment users, people onboarding via exchanges, and cross-chain bridges (Near Intents). 2. **Bandwidth scaling** : Right now, consensus bandwidth can only support 2.9 shielded Orchard TPS (27kb/s), this is far too low. This proposal introduces a step on improving this: namely reducing block target spacing by 3x, which leads to multiplicative throughput improvement with Tachyon, along with significant UX improvements. ### Precise proposal - Lower block target spacing from 75s to 25s - Keep the following parameters at same expected wall clock values: - Anchor block interval - All economic parameters (e.g. issuance per block is lowered, and issuance is kept as the same per day) - Any rounding concern can get sent to the NSM. - Difficulty adjustment stays at the same number of blocks, as was done in Blossom[[1](https://zips.z.cash/zip-0208)]. - Introduce limits for the 2MB blockspace, based on the pool - All 2MB can be used for Orchard txs - All 2MB can be used for Transparent txs - Up to 600kb of blockspace can be used for Sapling txs - Up to 600kb of blockspace can be used for Sprout txs Furthermore, we claim: - This raises 3x’s the 2 Action Orchard TPS from 2.9 to 8.6 TPS - This significantly improves the worst case wallet bandwidth from trial decryption. - The chain at maximum (adversarial) capacity would cause 9.8GB/year _less_ bandwidth to wallets. - Wallets will have to download extra compact block headers due to faster block time (80MB per year). - Bandwidth reductions for Sapling and Sprout cause no empirical usage concern - Worst case block processing time will not meaningfully increase - Stale block rate will remain well under 5% (Ethereum long term operated at 5.4%, with 12s blocks[[2](https://etherscan.io/chart/uncles)]) We expand on these claims in more depth. First more motivation on why. ## Motivation ### Why raise max TPS Zcash operates with a 75-second current target block time, with the max blocksize of 2 MB which implies that the Orchard pool’s max TPS is 2.9. Bitcoin’s max theoretical TPS is 7, and empirically at 5.4 TPS in production. Our ambition is far higher than both of these Bitcoin figures, with an aim to serve billions of users. Just enabling users to quickly migrate to post-quantum recoverability requires higher TPS. Bitcoin at its 7 theoretical TPS will already have issues: [https://x.com/zkDragon/status/2017899288378904941?s=20](https://x.com/zkDragon/status/2017899288378904941?s=20) For reference, Mastercard and Visa operate in the thousands of TPS consistently. To realize Zcash’s end-state vision, we must scale the TPS considerably over time, and bandwidth scaling is a critical step in that direction. ### Why reduce latency Today, every transaction waits ~75 seconds for inclusion, even when blocks are not full. This imposes unnecessary friction across the ecosystem. - **Cross-chain swaps** : Market makers must see a transaction on-chain before acting. While they tolerate PoW finality risk, they require at least 1 confirmation (often 2–3). - This increases inventory risk, leading to worse pricing and longer user-facing delays. - **Spendability of received funds** : - Directly limits ZEC’s money velocity. - Zashi currently waits 10 blocks (~12.5 minutes) before funds are spendable. - Bots at minimum _must_ wait one block, just due to anchor references. All current use cases benefit from lower latency. Today, users are forced to wait even when blockspace is underutilized, degrading UX without providing additional security or throughput benefits. 25s is not where we should long term stop, but is a great next move. ### Tachyon Project Tachyon [[3](https://seanbowe.com/blog/tachyon-scaling-zcash-oblivious-synchronization)] is going on to address critical, privacy-specific scaling challenges. Namely eliminating wallet sync overheads, full node processing times, and nullifier state growth. As Tachyon delivers, we need to focus on raising consensus bandwidth limits even higher. ## Justification of claims #### TPS Count This is straightforward. a 2-in-2-out Orchard tx is 9.14kb. The usable space in a block is 1.998MB [[4](https://github.com/ZcashFoundation/zebra/tree/main/zebra-chain/src/block)]. So its a max of 218, two Action txs per block. At one block every 75s on average, thats 2.9 TPS. At one block every 25s, that is 8.7 TPS. #### Worst Case Wallet Bandwidth A major bottleneck for Zcash wallets is trial-decrypting shielded outputs. Wallet’s bandwidth requirement scales with the number of compact block headers, and the number of shielded outputs. An empty block’s compact blockheader size is ~100 bytes [[5](https://github.com/zcash/lightwalletd/issues/527#issuecomment-3671783278)]. Thus faster block time leads to an additional 80.2MB/year being downloaded by clients. However, the worst case number of shielded outputs stays the same here. To adversarially grief wallets, you’d maximize `# outputs / tx size`. Today, you do this via Sapling txs, due to Groth16’s much smaller proof size. We need to compare 1-in-many-amt-out Sapling txs, and many-action Orchard txs. Today, a 1-in-32-out Sapling tx has size 30.8kb. This lets you have `32 * (1.998 MB / 30.8kb) = 2075 outputs/block` or `27.6` outputs per second at today’s block time. A 32 action Orchard tx takes 104kb. This leads to `32 * (1.998 MB / 104kb) = 614 outputs/block`. At the proposed new block time, this is 24.5 outputs per second. Thus the proposed Orchard max outputs per second is less than today’s from Sapling, so Orchard doesn’t increase max wallet overhead. The proposed parameters for Sapling slightly _lower_ the bandwidth available for Sapling transactions today, dropping it from today’s 1.998MB available per 75s, to 1.8MB available per 75s. That drops worst case Sapling outputs per second to be `24.9`. (assuming 32 out txs) Doing such a reduction _improves_ the worst case for wallets, in the event of another sand-blasting. A compact Sapling output costs 117 bytes for a client to trial decrypt. Dropping sapling max outputs per second by `2.7` saves light clients 9.8GB of download a year in the worst case. Correction (02.09.2026): When accounting for compact orchard action overhead (148 bytes including nullifier, vs Sapling’s 117 bytes), unlimited Orchard becomes the primary sync bottleneck at 25s blocks. With our proposed 600KB Sapling limit, worst-case client bandwidth improves by 10 GB/year compared to current network conditions. Further optimizations to pool limits may be considered to maximize this improvement. #### Bandwidth reductions on Sapling and Sprout Sapling and sprout txs have never taken anywhere the full block space allotted. (The sandblast was in Orchard) Today, Sapling accounts for ~12% of all shielded supply and ~0.5% for Sprout, with these relative percentages continuing to decline. So lowering their allocated bandwidths by 10% as proposed causes no user friction(See [zcashpulse.net](http://zcashpulse.net)). #### Worst case block processing time We are concerned with the time it takes to validate a block, since this affects: - Block propagation delay - Note, that all of the expensive ZKP verifications and signature checks should be cached from nodes seeing them in the mempool. - There is not an advantage to miners “withholding” orchard txs from the mempool. That is the equivalent of selfish mining, which they could just directly do. - The advantage a non-block-validating miner can have over one who validates their block - This concern is minimal with miners who can parallel verify blocks - Full node’s ability to sync on cheaper hardware The block validation time consists of: - Verifying Transparent/Sapling/Orchard transactions - Merkelization updates We will do more in-depth posts into this in the future. But intuitively the main bottleneck for consensus is verifying ZKP’s, and the second bottleneck is doing merkelization updates. An under-appreciated fact about Orchard, is the ZKP’s batch verify incredibly well by design, and this is already done on-chain. On our twelve core machine, `1` standard 2 action tx verifies in `9.8ms`, whereas `64` standard 2 action txs batch verify in `59ms`. (This is full action verification, not just the ZKP) Under this new parameterization, our current estimate is that verifying a max capacity block, with nothing checked from the mempool, should not take more than **1s** on a 4-physical core machine. However, we expect most transactions to have already been mempool checked, leaving verification time **sub 300ms**. We will more rigorously test this, as was done for Blossom. We get to **1s** as the estimate, by noting that max capacity blocks are 218 2-action txs. If nothing was pre-checked, we would verify with three 64 bundle batches and one 26 bundle batch. This gives a total verification time of ~215ms on our 12 core machine. Scaling down to 4 physical cores yields 650ms. Considering state updates, I/O and mempool overhead of an additional ~200ms, we get 850ms of worst-case full block verification time, and we roundup. If 90% of the transactions were checked in the mempool (as is the case in almost every network without MEV), we get the **300ms** estimate. We will optimize, and far better benchmark this over the coming weeks. (There are many known improvements) Note that for live consensus, this should be very safe. The load almost perfectly scales with num cores. Miners spend millions on GPU’s, they can be asked to have a 16 physical core CPU. Furthermore, realistically all the txs under load will have been pre-gossipped and verified from the mempool. Keeping verification times for miners likely well under 300ms. ### Stale rate Stale rate is the percentage of blocks that get orphaned. This is going to relate to block propagation delay between miners, and the block production rate. Proof of work block times are typically modelled as a Poisson process (If there were no P2P delays, it would _exactly_ be a Poisson process). Today, our stale rate is 0.4%. However, our stale rate is likely artificially lower than gossip delay, due to centralization within the mining pools. ([https://zecminers.xyz/](https://zecminers.xyz/)) The stale rate is then the percentage of blocks that get mined + gossipped within a “block\_propogation\_delay”. Doing the poisson distribution math yields an expected network delay of 300ms, without accounting for any “flat overheads” applied to all nodes or the many low level p2p concerns which we need to optimize. We empirically measure the network conditions of a new, 1 physical CPU node in US-East, as having a median gossip delay of 350ms, and p90 of 700ms. ([https://zcashpulse.net/](https://zcashpulse.net/)). At 25s, the same “theoretical” model estimates the stale rate would go to 1.3%. If we took today’s measured p90, rounded it up to 1s, and assumed that was always gossip delay, we would predict a 3.9% stale rate. Both are far less than the Ethereum POW’s demonstrated 5.4% stale rate.[[6](https://ethereum.stackexchange.com/questions/38121/why-did-ethereum-abandon-the-ghost-protocol)] Also note, that the delays all significantly improve as gossip engineering improves, e.g. Compact Blocks and UDP packets. The typical “folklore”[[7](https://github.com/zcash/zcash/issues/3690#issue-381886781)] is to keep gossip delay + processing times to be less than 10% mean block time, which we are well within then. ### Conclusion: Conservative Improvement, Clear Path Forward We propose going towards 25-second blocks in a small upgrade this year. We view it as a key step to improve UX for users, and scale the TPS to address demand and enable swift quantum migrations. We think it is conservative on the consensus safety side as well, and look forward to discussing strategies to better prove this. As a next step, we will prove out the gossip delay and processing time overheads on more recent hardware (e.g. assuming more parallelism), in a similar fashion to what was done for Blossom[[8](https://github.com/zcash/zcash/issues/3690#issuecomment-466220010)]. And aim to get optimizations for these. While Tachyon will enable true scale on the privacy front, we must lay the right foundation today to unlock its full potential. Reducing block target spacing is one key step in that direction. Co-written with @valardragon ---
**Author:** ![Autotunafish](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/autotunafish/32/7827_2.png) [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)\ **Post date:** [February 6, 2026, 9:51pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/2 "2026-02-06T21:51:13Z")
The relevant discussion from when it was done the first time and why the values were chosen. And to be fair, it was based partly on sprout > > > Who is affected: all users > What: shorter target blocktimes > Why: faster finalis…ation \[\*\] and greater throughput of transactions per hour. > > \[\*\] It's controversial whether this change actually provides this benefit. > > Data: > > \* BTC has 1 MB blocks, 600 second blocktimes, \[please reply and insert typical BTC full block verification time here\] and has often sustained full load without failing. > \* LTC has 1 MB blocks, 150 second blocktimes, but I don't know if it has ever sustained full load. > \* ETH has sustained full load at about 20 KB blocks about every 15 seconds, and according to \[according to Frederick\](https://twitter.com/zooko/status/1061719812701736960) with verification time around 300 ms. (Edit: after other changes to the difficulty in ETH, the \[average block time for ETH is currently 12.5 seconds\](https://www.trustnodes.com/2019/03/03/ethereum-blocks-drop-to-12-seconds).) > \* BCH may have sustained load during "stress tests" on their mainnet — I'm not sure about that. Please reply and add that data. > \* ZEC (1.0 “Sprout“ and 2.0 “Sapling”) have 2 MB max block size, 150 second block times, estimated worst-case verification time of maybe 20s (??? Please reply and add this data), but to my knowledge we've never sustained full load, not even on testnet or a simulation. > > Expert opinion: I've heard from Bitcoin Core developers, Vitalik Buterin, Arthur Breitman, James Prestwich, Daira Hopwood, and Emin Gün Sirer, and probably from lots of other well-informed people who I'm momentarily forgetting (sorry), and they seem to be in rough agreement that if the worst-case block verification time (i.e. the time for a miner to verify a winning block that a different miner just supplied to them, and which that other miner might have maliciously constructed with their own transactions designed to be slow to verify) is no more than 10% of the target block time, then you're probably okay. > > Proposal: > > 1. Write benchmarks of worst-case block verification time. > 2. Wire them up to https://speed.z.cash so that we can all see their current results (on a typical 64-bit modern multicore Intel/AMD machine). > 3. Optimize the verification code (batch verification of the SNARKs is allowed, SIMD implementation is allowed, multi-core and multi-threading are allowed). > 4. Change the target blocktime to be 10X the new worst-case block verification time. ---
**Author:** ![ValarDragon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/valardragon/32/16586_2.png) [@ValarDragon](https://forum.zcashcommunity.com/u/ValarDragon)\ **Post date:** [February 6, 2026, 10:09pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/3 "2026-02-06T22:09:04Z")
My read of [Strad’s benchmarks](https://github.com/zcash/zcash/issues/3690#issuecomment-466415814) in that issue was that Sapling was the bottleneck. Though thankfully if sprout ends up being even slower, we can further lower the blockspace available to that pool. (Its also a griefing attack available to only very few people in the world) ---
**Author:** ![Autotunafish](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/autotunafish/32/7827_2.png) [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)\ **Post date:** [February 6, 2026, 10:12pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/4 "2026-02-06T22:12:50Z")
That very well could be true 👍 ---
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [February 6, 2026, 11:33pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/5 "2026-02-06T23:33:12Z")
Not reviewing the entire proposal yet, but: > [@Mohak](#): > > Sapling and sprout txs have never taken anywhere the full block space allotted. (The sandblast was in Orchard) This is false. Sandblasting initially started in Orchard for a few weeks just after NU5 activation, then moved briefly to transparent, but then was almost entirely Sapling starting in late June 2022 through until ZIP 317 was deployed in April 2023. You can see the transition from Orchard to Sapling sandblasting in e.g. these scanning cost graphs I put together in early July 2022: > > > I just completed a reindex of my node, and the node crashed near the end (for un…related system issues) in a way that meant when I restarted it, it happened to rescan from almost the beginning to the end (so to be clear, I didn't use \`-rescan\`, but it was running the rescanning logic). I extracted the times and block heights from the log ("Still rescanning. At block N." lines), and you can see a distinct phase shift in scanning speed: > > !\[image\](https://user-images.githubusercontent.com/4993799/177413859-3bc2e523-35ea-456f-8d2e-22dd5e3438c9.png) > > This should not be due to slow block validation speed (#6049) because rescanning happens over the already-indexed local chain state. However they may share a common cause in the recent stretch of very full blocks (though I haven't checked if the slowdown started before the large blocks started). Note that this graph shows time vs blocks scanned, not time vs transactions scanned; the latter is what matters for throughput, so this graph might just be misleading. Briefly searching around the chain, it looks like block 1735000 is an example of a block full of Sapling bundles. ---
**Author:** ![ShieldOrder](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shieldorder/32/42014_2.png) [@ShieldOrder](https://forum.zcashcommunity.com/u/ShieldOrder)\ **Post date:** [February 7, 2026, 3:48am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/6 "2026-02-07T03:48:25Z")
Well-framed proposal. The technical benchmarking approach is the right way to evaluate something like this. One question that will come up: how does this get evaluated alongside Crosslink? 25s blocks address latency and throughput. Crosslink addresses finality. These solve different problems, and the community should be clear about which problem is being prioritized in NU8 and what can be sequenced independently. @str4d’s correction on the sandblasting history is worth incorporating before this moves further. ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [February 7, 2026, 6:05am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/7 "2026-02-07T06:05:13Z")
I want to draw attention to something that is not obvious, namely that 25 seconds is a very bad option for a network with a Bitcoin design, because you will not get a round number for the block reward due to division by 3. Furthermore, right now, blocks in Zcash are barely filling up to [1% on average](https://blockchair.com/zcash/charts/median-block-size) (сan I rely on Blockchair data? after doing a rough manual calculation, I concluded that I can.). Therefore, I’m not sure if this makes any sense at all right now. ---
**Author:** ![ValarDragon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/valardragon/32/16586_2.png) [@ValarDragon](https://forum.zcashcommunity.com/u/ValarDragon)\ **Post date:** [February 7, 2026, 8:29am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/8 "2026-02-07T08:29:32Z")
> [@str4d](#): > > This is false. Sandblasting initially started in Orchard for a few weeks just after NU5 activation, then moved briefly to transparent, but then was almost entirely Sapling starting in late June 2022 through until ZIP 317 was deployed in April 2023. You can see the transition from Orchard to Sapling sandblasting in e.g. these scanning cost graphs I put together in early July 2022: Ah thank you! That makes much more sense, since it is the more effective option for a sandblast. Will remove that line. (Though that was just used to support lowering bandwidth allocated for Sapling per 75s. Its not the key point, I think lack of utilization, and it only being a 10% reduction that lowers sand blast risk.) ---
**Author:** ![ValarDragon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/valardragon/32/16586_2.png) [@ValarDragon](https://forum.zcashcommunity.com/u/ValarDragon)\ **Post date:** [February 7, 2026, 8:47am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/9 "2026-02-07T08:47:15Z")
> I want to draw attention to something that is not obvious, namely that 25 seconds is a very bad option for a network with a Bitcoin design, because you will not get a round number for the block reward due to division by 3. So thankfully, the round down is tiny, it would be at most 1 zatoshi. 1 Zatoshi is 10^-8 ZEC. So at ZEC=$10,000 , thats $0.0001 rounded down. Concretely, the block reward right now is 1.5625 ZEC/block. This change would make it 0.52083333 ZEC/Block, which is a round down of 0.333… Zatoshi per block, or less than $0.00004 @ ZEC=10k. Its magnitude is super low, and having that go to the NSM for further distribution to miners fixes fairness concerns. ---
**Author:** ![ValarDragon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/valardragon/32/16586_2.png) [@ValarDragon](https://forum.zcashcommunity.com/u/ValarDragon)\ **Post date:** [February 7, 2026, 8:56am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/10 "2026-02-07T08:56:13Z")
> [@ShieldOrder](#): > > One question that will come up: how does this get evaluated alongside Crosslink? 25s blocks address latency and throughput. Crosslink addresses finality. These solve different problems, and the community should be clear about which problem is being prioritized in NU8 and what can be sequenced independently. These should sequenceable fully independently. In terms of what causes the greater user facing problem, I personally think inclusion time is it. (Enables faster payments + NEAR intents actions) ---
**Author:** ![ValarDragon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/valardragon/32/16586_2.png) [@ValarDragon](https://forum.zcashcommunity.com/u/ValarDragon)\ **Post date:** [April 9, 2026, 3:38am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/11 "2026-04-09T03:38:19Z")
Wanted to post an update on here. Made a ZIP a month ago with @evan-forbes here: [[ZIP TBD]: Block time reduction of 75s -\> 25s by ValarDragon · Pull Request #1215 · zcash/zips · GitHub](https://github.com/zcash/zips/pull/1215) The updates to the proposal: - We actually fix a long-standing tension between “What a sandblasting attacker can do” and “What normal behavior is” by actually directly limiting the number of actions in a block (per pool-type and in total). This eases parameterization relative to block size (Where we limit usage based on a DOS attacker rather than normal users) - Incorporated some feedback from Zodl team members who pointed out “If we are touching these parameters, we actually aren’t happy with today’s maximum client load and want to be ensuring its lower than today, not just marginal. We are currently compute blocked” - Number in ZIP show this being much better with the adaptation of Action Limits. - 3x’ing Orchard TPS (making us 8.76 max TPS) would in net be a 17% bandwidth reduction, and 38% compute reduction. - 2.1x’ing Orchard TPS (making us 6.12 max TPS) would be a 42% bandwidth reduction, and 58% max client compute reduction - Separately we have a lot of work on PIR to eliminate components of shielded sync load, and a 2x improvement for “remove internal viewing key trial decrypt”. Given those, I think we should err to the 3x TPS improvement, but ZIP as-is is on the 2x. - PR’s for these in the works by [Adam](https://x.com/czarcas7ic) and [Roman](https://x.com/akhtariev) ! Various videos for this on X - Build a shielded sync load simulator: [http://164.92.225.227:5174/](http://164.92.225.227:5174/) , default choices on the RHS are what is part of the ZIP. (Remove internal viewing key trial decrypt is being PR’d regardless ) @evan-forbes has been building out testnets + many p2p benchmarks proving out things work @ 25s! ---
**Author:** ![evan-forbes](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/evan-forbes/32/44746_2.png) [@evan-forbes](https://forum.zcashcommunity.com/u/evan-forbes)\ **Post date:** [May 4, 2026, 4:36pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/13 "2026-05-04T16:36:23Z")
linking to the forum post that proves out and measures the stale block and fork rate after reducing the block times. if we configure tcp correctly, we can maintain an under %5 stale block rate even in the worst case conditions > [@Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra Only Devnet](https://forum.zcashcommunity.com/t/zcash-block-time-reduction-appears-safe-for-nu7-w-zebra-only-devnet/55586): > > Authors: Evan Forbes, Dev Ojha (@ValarDragon) Valar Group Summary A key question when choosing PoW block times is what happens with stale block rates, and fork/re-org rates. Lower block times improve UX of users and market makers, giving them faster confirmation times for small size transactions. However, lower block times increase the stale block rate as block propagation delay takes a larger percentage of block time. We want to understand how stale block rates perform at very decentralized, … ---
**Author:** ![bitcoincashautist](https://avatars.discourse-cdn.com/v4/letter/b/77aa72/32.png) [@bitcoincashautist](https://forum.zcashcommunity.com/u/bitcoincashautist)\ **Post date:** [May 22, 2026, 6:07pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/14 "2026-05-22T18:07:25Z")
Hi, first of all I’m thankful to Zcash for pioneering the change of target block time (150s → 75s in 2019) on a live network of the Bitcoin source family, you’ve already shown us it can be done. Over at BCH we want to go from 10min to 1min (“CHIP-2025-03 Faster Blocks for Bitcoin Cash”), and this is all very useful information for us. While discussing our own change, the BCH community was mainly concerned about: - Impact on SPV wallets (header overheads) - Orphan rates (“stale rate”) - Maintaining equivalence of supply, DAA, adaptive blocksize limit algorithm, locktime and sequence checks, etc. - Impact on downstream software (various backends like indexers, Electrum servers, pool software, block explorers, metrics pages, exchange systems, etc.) I want to ask you specifically about the last one. Did you have any issues when making the first switch in 2019? Risk of breaking some user-space software is a big concern for us. It’s actually reassuring that you’re proposing a 2nd change from 75s to 25s and calling it a “small upgrade”. To me it signals that there were no big issues with the first one in 2019, is that right? ---
**Author:** ![bitcoincashautist](https://avatars.discourse-cdn.com/v4/letter/b/77aa72/32.png) [@bitcoincashautist](https://forum.zcashcommunity.com/u/bitcoincashautist)\ **Post date:** [May 22, 2026, 6:48pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/15 "2026-05-22T18:48:21Z")
> [@artkor](#): > > I want to draw attention to something that is not obvious, namely that 25 seconds is a very bad option for a network with a Bitcoin design Zcash started with 150s, right? In that case, to maintain alignment with now “chunks” of 150s, the new target interval times should be picked from factors of 150, which are: 1, 2, 3, 5, 6, 10, 15, **25** , 30, 50, **75** , 150. Additionally, to maintain alignment with original emission schedule, the switch should be made at a height that’s aligned with original chunks, i.e. after an even number of 75s blocks, so the entire 75s era would align with a round number of 150s blocks. There will still be some losses in emission, but that is negligible. For your reference, I did an analysis for Bitcoin (Cash) (copied from our CHIP): **Table: Block Subsidy Shortfall Due to Reducing Block Target Time** | Target Time (s) | First Affected Era1 | First Affected Year | Total Minted (BCH) | Total Shortfall (BCH) | Subsidy End Year | | --- | --- | --- | --- | --- | --- | | 600 | | | 20,999,999.9769 | 0.0000 | 2140 | | 300 | 10 | 2044 | 20,999,999.9538 | 0.0231 | 2136 | | 200 | 1 | 2009 | 20,999,999.8971 | 0.0798 | 2132 | | 150 | 9 | 2040 | 20,999,999.9076 | 0.0693 | 2132 | | 120 | 11 | 2048 | 20,999,999.8635 | 0.1134 | 2128 | | 100 | 1 | 2009 | 20,999,999.8026 | 0.1743 | 2128 | | 75 | 8 | 2036 | 20,999,999.8152 | 0.1617 | 2128 | | 60 | 10 | 2044 | 20,999,999.7270 | 0.2499 | 2124 | | 50 | 1 | 2009 | 20,999,999.6136 | 0.3633 | 2124 | | 40 | 1 | 2009 | 20,999,999.4750 | 0.5019 | 2124 | | 30 | 9 | 2040 | 20,999,999.4540 | 0.5229 | 2120 | | 25 | 1 | 2009 | 20,999,999.2608 | 0.7161 | 2120 | | 24 | 11 | 2048 | 20,999,999.3700 | 0.6069 | 2120 | | 20 | 1 | 2009 | 20,999,998.9710 | 1.0059 | 2120 | | 15 | 8 | 2036 | 20,999,998.9080 | 1.0689 | 2116 | | 12 | 10 | 2044 | 20,999,998.7400 | 1.2369 | 2116 | | 10 | 1 | 2009 | 20,999,998.0260 | 1.9509 | 2116 | | 8 | 1 | 2009 | 20,999,997.7425 | 2.2344 | 2112 | | 6 | 9 | 2040 | 20,999,997.4800 | 2.4969 | 2112 | | 5 | 1 | 2009 | 20,999,996.1360 | 3.8409 | 2112 | | 4 | 1 | 2009 | 20,999,995.6950 | 4.2819 | 2108 | | 3 | 8 | 2036 | 20,999,994.9600 | 5.0169 | 2108 | | 2 | 1 | 2009 | 20,999,991.6000 | 8.3769 | 2104 | | 1 | 1 | 2009 | 20,999,984.0400 | 15.9369 | 2100 | 1 First Affected Era: Halving era where integer division first reduces the subsidy. ---
**Author:** ![shielded-nate](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shielded-nate/32/33294_2.png) [@shielded-nate](https://forum.zcashcommunity.com/u/shielded-nate)\ **Post date:** [May 27, 2026, 1:15am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/16 "2026-05-27T01:15:26Z")
Hi all, I’m glad to see this proposal and how it is thought out. There is one issue I don’t see addressed in this thread, though I haven’t reviewed the ZIP yet, and I’d feel more comfortable if it was analyzed better and there was a widespread consensus about how to address it prior to shipping. Also, to be fair, I think this exact same issue applied with the earlier block target time reduction, and I don’t recall if this issue was analyzed. I still think it’s worth doing better than last time if we can! If we assume a fixed mining capacity + difficulty, then one analysis of security against PoW rollbacks is the opportunity cost of the time / energy / money spent on an attack. Lowering or raising the block target time doesn’t affect this cost (time / energy / money). The implication of this is that for any users who follow a heuristic of waiting for K block confirmations to have some security guarantee against rollbacks, if those users do not adjust their heuristic when this change activates, they will be receiving confirmations faster on average for _less security_ against rollbacks. So ideally, each user would (a) know about this impact, then (b) decide if they want faster confirmations with less protection against rollbacks, or to maintain their previous (approximated) level of protection against rollbacks (which would take approximately the same wall clock time, and would require adjusting a `K`-block threshold heuristic, probably by around 3x). Since real users aren’t the ideal, we should also decide, as a dev community, how to address this issue. My first stab at next steps would be: (a) educate wallet devs, exchanges, etc… of the trade-off, since all of them implement some kind of UI around confirmations, and some of them use “depth `K`” security heuristics. (b) I haven’t thought about the impact of variable mining capacity and Zcash’s quickly responding DAA. I also haven’t yet read [this post](https://x.com/zkDragon/status/2056990016203796749), which looks promising. Hopefully there’s overlapping analysis. (c) I think we should avoid, as a community, saying this change _simply_ “lowers confirmation times” without _also_ including the fact that it’s trading off confirmation time with rollback protection level. I haven’t seen this issue mentioned explicitly anywhere in this thread, although I did see that section about wall-clock time economic parameters. We might consider rollback security an example of a wall-clock time economic parameter (but even so, I think it deserves explicit mention). FWIW, I’m a fan and supporter, of this change for NU7, and I think we can and should address this to make this change even more solid for NU7. I also expect that for many users / use-cases the quicker single-block confirmation may be a helpful option that doesn’t currently exist. Thanks for your effort on this! ---
**Author:** ![bitcoincashautist](https://avatars.discourse-cdn.com/v4/letter/b/77aa72/32.png) [@bitcoincashautist](https://forum.zcashcommunity.com/u/bitcoincashautist)\ **Post date:** [May 28, 2026, 9:29am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/17 "2026-05-28T09:29:29Z")
> [@shielded-nate](#): > > The implication of this is that for any users who follow a heuristic of waiting for K block confirmations to have some security guarantee against rollbacks, if those users do not adjust their heuristic when this change activates, they will be receiving confirmations faster on average for _less security_ against rollbacks. One often forgotten aspect of PoW is that, against _minority_ attackers (\<50% hashpower), security grows exponentially with number of confirmations! So, users requiring a fixed number of confirmations may only need to require +1 instead of x3. This has been demonstrated in Bitcoin whitepaper ([“11. Calculations”](https://nakamotoinstitute.org/library/bitcoin/#calculations)). If your threat model is a \>50% attacker (imagine someone rents enough hash for a short-term burst), then it is economics that determine whether attacker can extract ROI or not, and expected break-even is when the attacked amount is greater than `(required number of confirmations) x (coinbase value)`, which led to the common framing of measuring accumulated chainwork for security - which grows linearly with number of confirmations (assuming flat difficulty). > [@shielded-nate](#): > > Since real users aren’t the ideal, we should also decide, as a dev community, how to address this issue. I’m coming from BCH and we’re considering a block time change as well, so Zcash experience is of interest to us, and this has been a concern of ours, too. We’re addressing that by introducing a block `ticks` abstraction, where ticks are an uniform measurement of chain progression: 1 tick = 1 second worth of target time. So height expressed in ticks is actually a cumulative sum of target times, and invariant of underlying blocks individual target times, 6x10min = 60x1min = 600 ticks. Idea is to expose `height_ticks`, `confirmations_ticks` and `target_time` in node APIs, so downstream users can abstract away the target time and be forward-compatible with any future target block time changes. Instead of requiring 6x10min confs you’d require 600 ticks. So even if target time changes 1/2, your system will automatically start requiring x2 confirmations - if set up in such way to make use of the extended APIs. See our [“Blockchain Height Abstraction”](https://gitlab.com/0353F40E/fablous#blockchain-height-abstraction) for more details. ---
**Author:** ![shieldedpool](https://avatars.discourse-cdn.com/v4/letter/s/e19b73/32.png) [@shieldedpool](https://forum.zcashcommunity.com/u/shieldedpool)\ **Post date:** [June 2, 2026, 8:35pm UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/18 "2026-06-02T20:35:03Z")
I prefer alter the block size to a lower amount. ZCash has suffered many spam attacks in its history. This has caused unnecessary blockchain bloat. A lower block size and a real fee market will help this. Otherwise ZCash continued to be vulnerable to DOS from blockchain bloating spam txes. ---
**Author:** ![Uscmigs](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/uscmigs/32/44450_2.png) [@Uscmigs](https://forum.zcashcommunity.com/u/Uscmigs)\ **Post date:** [June 3, 2026, 4:59am UTC](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577/19 "2026-06-03T04:59:33Z")
There is onegoing work regarding a dynamic fee, that is referenced in another thread here. I’ve done backtesting on historical blocks utilizing the dynamic fee model based on how it was proposed in the dynamic fee working group. Looking at a 50,000 block history from blocks 3,000,000 to 3,050,000 the dynamic model (called marginal fee in the plots below) show that there is a higher probability backtesting for spam to be more successful. This is likely due to times in the 1,000 block history when the mean base fee is at its lowest so a transaction with many logical actions will be slightly cheaper to implement in these regimes. Due to the dynamic nature though, it would reprice the mean base fee if the spamming is consistent. One thing about reduce the block size is that you would really affect scaling if block utilization increased over time as more adoption happens. I know Tachyon has things to additionally help scaling, but reducing block size I think would be self defeating. Right now block space utilization is below 5% on average ![image](https://global.discourse-cdn.com/zcash/original/3X/f/6/f6b9747c7bec9373813b4acc6ece981040360061.png) This second plot shows how the marginal fee rate (aka dynamic rate) adjusts over this 50,000 block backtest, but it does stay marginally lower than static 200 zat/byte currently implemented in ZIP317. ![image](https://global.discourse-cdn.com/zcash/original/3X/1/5/15deebe4a26f002b3e7303ccb6b17cee5765c82b.png)