Simulating confirmation waits after Zcash's block time cut

Changoo — Tue, 10 Nov 2026 02:52:29 +0000

The change

Zcash's NU7 upgrade went live on mainnet on 6 November 2026 and cut the target block spacing from 75 seconds to 25. On 8 November a draft ZIP on the Zcash community forum proposed 20 seconds for NU7.1. The draft scales the per-block shielded limits by 4/5 and rescales issuance, the difficulty window and transaction expiry so that their wall-clock meaning stays the same. The authors call it a latency-only change.

If you write code that credits deposits, this raises a practical question: how long does it take to collect N confirmations, and how much does that number move when the spacing drops?

Why the average isn't enough

Under proof of work, block intervals are close to exponentially distributed with a mean equal to the target spacing. The time to collect N blocks is then the sum of N exponential variables, which is a Gamma(N, spacing) distribution. The mean is easy (N * spacing), but users feel the tail. With one confirmation the spread is huge; with 30 it narrows.

The script below samples that distribution with a seeded PRNG so the output is reproducible. No dependencies, Node 18+.

// How long does it take to collect N confirmations when blocks arrive at random?
// Block intervals under proof of work are roughly exponential with mean = target spacing,
// so the wait for N blocks follows a Gamma(N, spacing) distribution. We sample it.
// usage: node confirm-wait.mjs [trials]
const trials = Number(process.argv[2] ?? 200000);

// Deterministic PRNG (mulberry32) so the numbers are reproducible.
function rng(seed) {
  return () => {
    seed |= 0; seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

function waitTimes(confs, spacingSec, n, rand) {
  const out = new Float64Array(n);
  for (let i = 0; i < n; i++) {
    let t = 0;
    for (let k = 0; k < confs; k++) t += -Math.log(1 - rand()) * spacingSec;
    out[i] = t;
  }
  return out.sort();
}

const pct = (arr, p) => arr[Math.min(arr.length - 1, Math.floor(p * arr.length))];
const min = (s) => (s / 60).toFixed(1).padStart(5);

const cases = [
  { chain: 'Zcash before NU7', spacing: 75, confs: [30, 40] },
  { chain: 'Zcash after NU7', spacing: 25, confs: [30, 40] },
  { chain: 'Zcash at 20 s (draft ZIP)', spacing: 20, confs: [30, 40] },
  { chain: 'Zcash at 20 s, 25% more confs', spacing: 20, confs: [38, 50] },
  { chain: 'Bitcoin', spacing: 600, confs: [1, 3] },
];

const rand = rng(20261110);
console.log(`trials per row: ${trials}\n`);
console.log('chain'.padEnd(32) + 'confs'.padStart(6) + '   mean   p50   p90   (minutes)');
for (const c of cases) {
  for (const n of c.confs) {
    const w = waitTimes(n, c.spacing, trials, rand);
    const mean = w.reduce((a, b) => a + b, 0) / w.length;
    console.log(c.chain.padEnd(32) + String(n).padStart(6) + ' ' + min(mean) + ' ' + min(pct(w, 0.5)) + ' ' + min(pct(w, 0.9)));
  }
}

Output

node confirm-wait.mjs 200000:

trials per row: 200000

chain                            confs   mean   p50   p90   (minutes)
Zcash before NU7                    30  37.5  37.1  46.5
Zcash before NU7                    40  50.0  49.6  60.4
Zcash after NU7                     30  12.5  12.4  15.5
Zcash after NU7                     40  16.7  16.5  20.1
Zcash at 20 s (draft ZIP)           30  10.0   9.9  12.4
Zcash at 20 s (draft ZIP)           40  13.3  13.2  16.1
Zcash at 20 s, 25% more confs       38  12.7  12.6  15.4
Zcash at 20 s, 25% more confs       50  16.7  16.5  19.8
Bitcoin                              1  10.0   7.0  23.1
Bitcoin                              3  30.0  26.8  53.3

The 30 to 40 range is the confirmation threshold one swap service showed for ZEC deposits on 10 November 2026. The "before NU7" rows apply the same count to the old spacing for comparison only.

What the numbers say

At the same count, 25 s to 20 s takes about 2.5 minutes off the median wait for 30 confirmations and about 3.3 minutes for 40. The p90 moves by a similar amount.

The "25% more confs" rows are the other case. The draft says it doesn't ask anyone to lower their confirmation count, and that services that set policy by wall-clock time or accumulated work need no change. A service that keeps a time budget will scale the count by 5/4, and then the wait distribution comes out almost exactly where it was at 25 s. Users see no difference.

The Bitcoin rows are there for contrast. With one confirmation at a 10-minute target, the median is about 7 minutes, but one deposit in ten waits more than 23. That long tail is why a single-confirmation policy feels unpredictable even though the mean looks fine.

Things the model leaves out

Difficulty adjustment and hashrate swings move the real mean away from the target for hours at a time.
Orphaned blocks. The draft's stress-net test of full 2 MB blocks at 20 s measured 1.9% with one node implementation and 3.3% with a 50-50 mix of two.
Mempool delay before the first inclusion, which is a separate wait on a busy chain.

If you maintain a deposit pipeline

Store the threshold as what you actually mean. If the intent is "N blocks", keep a block count. If the intent is "about this much time or work", derive the count from the spacing so the next upgrade doesn't silently change your security margin. The draft's own argument is that a minority attacker's success probability falls exponentially per confirmation, so a modest count increase keeps the margin.

Sources: Zcash community forum, "Proposal: Lower Zcash block target spacing from 25s to 20s" (8 Nov 2026); Cointelegraph, "Zcash devs propose another block time cut days after NU7 upgrade" (9 Nov 2026).