Zcash draft proposes 20-second blocks with the same shielded capacity

Zcash developers revised a draft on November 8 that would cut the network’s target block interval from 25 seconds to 20 seconds after NU7. CoinAbout calculated that blocks would arrive 25% more often at the new target, while the daily budget for shielded activity would stay flat. The draft leaves activation to a separate proposal.

The authors, Dev Ojha and Evan Forbes, are proposing a change to how quickly the network aims to produce a block. A wallet waiting for its first confirmation could benefit from more frequent opportunities for inclusion. A wallet syncing a full day of shielded activity would face the same maximum shielded workload in the draft’s model, plus more block headers. These two outcomes follow from separate limits in the proposal.

More blocks, smaller shielded budgets

The November 8 revision reduces the global shielded budget and the limits for Orchard and Ironwood actions from 330 to 264 per block. It reduces the Sapling limit from 300 to 240 inputs and outputs per block. The revision matters because keeping the old per-block limits while raising the number of blocks would increase the maximum amount of shielded data light wallets must process. The published revision scales those limits down by one fifth instead.

CoinAbout compared the two schedules using 86,400 seconds in a day. Dividing by the target spacing gives 3,456 blocks at 25 seconds and 4,320 at 20 seconds. Multiplying the first count by 330 gives 1,140,480 Orchard or Ironwood actions. Multiplying the second by 264 gives the same total. The corresponding Sapling calculation is 3,456 times 300 and 4,320 times 240. Both give 1,036,800 inputs and outputs.

The figures are separate illustrations of the limits. Adding them together would overstate what a block can carry because the protocol also applies a shared shielded budget. An action or an input or output is a component of a transaction, so these totals cannot be read as daily transaction counts. They also assume blocks arrive at target spacing and the relevant limit is used throughout the day. Actual production and demand vary.

The pinned draft specification illustrates that distinction with a transaction carrying 300 Orchard actions. Such a transaction fits under the old Orchard action limit by itself. It would exceed the proposed limit on its own and could not be included after activation in that form. Even with the same aggregate capacity over a day, a wallet that creates large transactions would have to account for the smaller limit on each one.

What a shorter target could change for payments

Twenty seconds is a 20% shorter target interval than 25 seconds. The inverse relationship explains why the expected block count rises by 25%. A payment that is ready for inclusion gets more opportunities to enter a block over the same span. Its actual wait depends on when the next block is found and whether the transaction gets included. The proposal does not set a deadline for any individual payment.

Services can also wait for additional confirmations after inclusion. A service using a fixed block count would see a shorter expected elapsed time for that count. A service using an elapsed-time threshold or a measure of accumulated mining work might handle the change differently. A shorter target alone gives no basis to infer what an exchange will do with its deposit rules. A user evaluating deposit speed would need the exchange’s policy and observations from the live network after any activation.

The draft preserves the recommended three-block depth for choosing the reference point a shielded transaction relies on. Three target intervals would represent 60 seconds rather than 75. The authors flag a privacy trade-off because a shorter interval can give observers finer information about when activity occurred. They also describe a case in which a rollback invalidates a transaction’s reference point. If a replacement spends the same notes, matching spend identifiers can link the transactions. The draft’s discussion of blocks falling out of the selected chain does not establish how deep a future rollback could be.

The wallet and node costs move differently

The compact data model in the draft uses 90 bytes per block header. At target spacing the proposed schedule adds 864 headers per day. Multiplying by 90 gives 77,760 additional bytes, about 78 decimal kilobytes. The authors’ model excludes transport and serialization overhead, so the result is an estimate for one component of compact wallet sync. It does not describe the data use of every wallet.

The draft keeps the full block size limit at 2 MB. More blocks therefore raise the theoretical space available for transparent data over a given period. Full nodes also have more blocks to process and relay. That is a separate workload from a light wallet fetching compact data, and actual resource use depends on block contents and network conditions. The same shielded action budget does not imply that every part of the network faces the same load.

The strongest case for treating this as a modest change is that the new limits are designed to preserve shielded work per unit of time. The main counterpoint is that operations with a fixed cost per block happen more often, and shorter intervals give nodes less time to relay each block. Measurements across different node implementations, block loads and network conditions would help establish how those effects balance. The draft’s reported experiments are developer evidence, separate from any measurements of the proposed rules on mainnet.

The draft keeps some clocks close and leaves others open

The difficulty adjustment window is one example of why block count and elapsed time should be compared separately. The current 102-block window multiplied by 25 seconds gives 2,550 seconds. The proposed 128 blocks multiplied by 20 seconds gives 2,560 seconds. That is a difference of 10 seconds, or about 0.39% relative to the current target duration. The draft carries the lookback across activation instead of restarting it at that height.

The proposed halving interval rises from 5,040,000 to 6,300,000 blocks. At the respective target intervals both represent 126 million seconds. The draft also scales the scheduled subsidy down before rounding and carries forward progress through the current halving interval. Those choices aim to preserve the expected issuance schedule. Integer rounding and the rules that recycle value into future subsidies still matter to the exact result.

The draft identifies unresolved work on how to adjust funding stream end heights and payment address periods. It also leaves open how to set the trigger for reissuance if the proposed upgrade activates before reissuance starts. Those are decisions about the transition from one schedule to another. Preserving the duration of a halving interval does not settle them.

The specification gives an example of why implementations must agree on when they round. At halving index three, the formula yields a proposed scheduled subsidy of 20,833,333 zatoshi, the smallest units of ZEC. Starting from the already rounded baseline of 26,041,666 zatoshi, multiplying by four fifths and rounding down yields 20,833,332. The one-unit difference matters to nodes that must enforce the same consensus rule. The example describes a calculation in the draft and excludes any additional subsidy.

A separate deployment proposal would need to set activation heights and consensus branch identifiers. The November 8 revision provides numbers that wallet and node developers can evaluate today. An agreed deployment specification and compatible client releases would be the evidence to look for before treating 20-second blocks as an operational change.