8 NU7: 25-second blocks and bounded shielded work

The most-work rule remains Definition 2.2: compare the sum of the blocks’ work, not their count. Changing target spacing changes neither the work definition nor this ordering.

Assumption 4.2 freezes difficulty; Zcash retargets after every block. In ZIP-218, the NU7 target spacing is $25$ seconds and the target-averaging window is $102$ blocks. The timestamps determining the adjustment still come from the branch being evaluated, including on an attacker’s private branch.

Write $N=102$ for the target-averaging window and $T=N\cdot 25=2,550$ seconds for its nominal timespan.

The specification’s §7.7.3 defines the rest of the calculation. For a block height $h$, let $m(h)$ be the median timestamp of the eleven preceding blocks: their sixth-smallest timestamp. Let $\overline{t}(h)$ be the mean target of the $N$ blocks preceding $h$: the sum of their targets divided by $N$. Define the observed and damped timespans by

	$a(h)$	$=m(h)-m(h-N),$
	$d(h)$	$=T+\mathrm{trunc}\left({\displaystyle \frac{a(h)-T}{4}}\right),$

where $\mathrm{trunc}$ discards the fractional part towards zero. The bounded timespan $c(h)$ is $d(h)$ clamped between $\lfloor 0.84T\rfloor$ and $\lfloor 1.32T\rfloor$: values below the lower endpoint are replaced by that endpoint, and similarly above the upper endpoint. The maximum target $\mathrm{𝖯𝗈𝖶𝖫𝗂𝗆𝗂𝗍}$ is $2^{243}-1$ on Mainnet, the production network, and $2^{251}-1$ on Testnet, the test network (§5.3). The target calculation is

$$t(h)=\min (\mathrm{𝖯𝗈𝖶𝖫𝗂𝗆𝗂𝗍},\lfloor \frac{\overline{t}(h)}{T}\rfloor c(h)),$$

followed by the compact encoding defined in the specification’s §7.7.4. The order of the floor and multiplication matters. At NU7 the clamp endpoints are $2,142$ and $3,366$ seconds; the eleven-timestamp median, fourfold damping, and target cap are unchanged.

Activation does not reset the accumulated work or multiply the target by three in a single operation. The first NU7 blocks still look back over pre-NU7 history and adjust through the same bounded rule. Likewise, the timestamp rules do not shrink with the target spacing: a timestamp must exceed the median of the preceding eleven and be at most $90$ minutes above it (§7.6). A further non-consensus receipt check rejects blocks more than two hours ahead of the validator’s clock. Testnet’s exceptional minimum-difficulty rule continues to use six target spacings: its delay threshold becomes $6\cdot 25=150$ seconds. This exception does not apply to Mainnet.

Zcash’s proof of work is Equihash with parameters $n=200$, $k=9$ (specification §7.7, §7.7.1; the algorithm is Biryukov and Khovratovich’s, ePrint 2015/946), but the quantity the race counts is gated one step later: “[t]he difficulty filter is unchanged from Bitcoin, and is calculated using SHA-256d on the whole block header (including solutionSize and solution)”, required to be at most $\mathrm{𝖳𝗈𝖳𝖺𝗋𝗀𝖾𝗍}(\text{nBits})$ (§7.7.2). Each candidate Equihash solution therefore faces a fresh SHA-256d lottery. Treating distinct headers as independent trials is the usual random-function model for SHA-256d, not a property asserted by the specification; under that model these are the Bernoulli trials of Remark 3.7.

The specification nowhere asserts progress-freeness — the argument is this volume’s, not a citation. What Equihash changes is the granularity: candidates arrive in batches, one batch per memory-hard solver run. Progress within a run is discarded when a competing block arrives. Under independent identically distributed runs, the number of runs until an accepted header is geometric; replacing those discrete completion times by an exponential clock is a further approximation, coarse within one run and good only when a run is short relative to the target spacing: $25$ seconds in the NU7 draft. Run duration is implementation- and hardware-dependent and is not quantified here. A proof-of-work whose solve time were comparable to the spacing would make block discovery visibly non-exponential and pull the attribution sequence away from Proposition 3.4.

Consensus does not impose a maximum reorganisation depth. ZIP-218 recommends a node-local $600$-block rollback window: at the target spacing this is $600\cdot 25=15,000$ seconds, or $250$ minutes. Such a limit bounds the history that a node automatically reverses; it is not a proof that older blocks cannot be replaced by a higher-work valid chain. Following a branch outside that retained history requires different local state or operator intervention. Actual node implementations may choose a different window.

A transparent output records its value and destination in cleartext. The consensus maturity rule prevents spending such an output of a coinbase until the spending block is at least $100$ heights later (§7.1.2). ZIP-218 keeps that count, a nominal $100\cdot 25=2,500$ seconds. Coinbase outputs placed directly in a shielded pool do not have this transparent maturity restriction. A $600$-block rollback window can therefore reverse an already mature coinbase: maturity permits spending, not finality.

A wallet can distinguish trusted outputs that its own transaction handling can recreate after a rollback from an untrusted external payment that may require the sender to pay again. The examined wallet backend uses three confirmations for the former and ten for the latter, with zero-confirmation shielding of transparent funds allowed by its default policy. These choices are not consensus rules.

Table 1 quantifies their modelled trade-off: three confirmations assign a $10\%$ attacker risk $1.712\%$, while ten assign the same attacker about $0.0008\%$ and a $20\%$ attacker about $0.316\%$. The count remains a $(q,\epsilon )$ policy, not a guarantee.

The anchor is the note-commitment-tree root against which a spend proves membership (Crypto Guide, §Privacy-preserving membership via zero-knowledge paths). ZIP-218 keeps the recommended anchor depth at three blocks. Its recommended transaction-expiry delta is $120$ blocks, a nominal $120\cdot 25=3,000$ seconds, without overriding an explicitly configured expiry delta. There is no instruction to divide every confirmation count by three.

A byte limit does not directly bound the computational work inside a block. The $2,000,000$-byte limit must therefore be considered alongside the $25$-second target spacing and the costs of shielded validation and wallet scanning. ZIP-218 adds limits on the shielded components that drive this work.

An Orchard Action pairs one spend slot with one output slot; dummy slots allow either side to carry no real transfer. Ironwood is the newer shielded pool using the same Action structure (ZIP-229). The older Sapling shielded pool counts spends and outputs separately; its cryptographic construction is not needed for this accounting.

Let $O$ and $I$ count Orchard and Ironwood Actions in a block, and let $S$ count Sapling spends plus outputs. With the Ironwood coverage proposed in PR 1361, the complete shielded budget is

$$O\le 330,I\le 330,S\le 300,O+I+S\le 330.$$

The final inequality is shared across pools: their separate maxima cannot all be filled in one block. Sprout transfers cannot occur because NU7 rejects the version 4 format that represents them.

The Ironwood term remains under review rather than already specified by the merged ZIP-218 draft. For example, $O=100$, $I=200$, $S=30$ exhausts the shared budget; increasing $I$ to $201$ violates it even though each per-pool limit still holds. At two Actions per transaction, a block devoted to one Orchard-protocol pool fits at most $165$ such transactions under this budget, or a nominal $165/25=6.6$ transactions per second. This is a capacity calculation under a specified transaction shape, not a measured throughput guarantee. Transparent components remain subject to the byte limit rather than this shielded-action budget.

A zatoshi is the atomic currency unit: $1$ ZEC equals ${10}^8$ zatoshi. A halving divides the scheduled subsidy by two. Retaining its nominal wall-clock interval while tripling block frequency requires both three times as many blocks per interval and one third of the subsidy per block. ZIP-218 therefore changes the full interval from $1,680,000$ to $L=5,040,000$ blocks. These earlier intervals are needed to compute progress at activation, not to supply an alternative rule. The change preserves expected timing, not exact calendar dates, because actual block times remain random.

The progress already made towards the next halving must survive activation. Let $H_B$ be the Blossom activation height: $653,600$ on Mainnet and $584,000$ on Testnet. Before Blossom, halvings were separated by $840,000$ blocks; the initial slow-start schedule, which ramps up the subsidy during the first $20,000$ blocks, contributes a shift of $10,000$ blocks. These constants and the maximum subsidy $M=1,250,000,000$ zatoshi are defined in the specification’s §5.3 and §7.8. For a height $h\ge A$, the draft’s halving count and scheduled subsidy $s_h$, measured in zatoshi, are

	$k(h)$	$=\lfloor {\displaystyle \frac{H_B-10,000}{840,000}}+{\displaystyle \frac{A-H_B}{1,680,000}}+{\displaystyle \frac{h-A}{5,040,000}}\rfloor ,$		(4)
	$s_h$	$=\lfloor {\displaystyle \frac{M}{2\cdot 3\cdot 2^{k(h)}}}\rfloor .$		(5)

The factors $2$ and $3$ account separately for Blossom’s and NU7’s spacing changes. If activation occurs during the second-halving era, $k(h)=2$ gives $s_h=52,083,333$ zatoshi, or $0.52083333$ ZEC, until the next halving; $k(h)=3$ gives $26,041,666$ zatoshi.

The old Mainnet third-halving height $H_3=4,406,400$ is therefore not the NU7 third-halving height if . Converting the remaining interval gives

$$H_3^{\mathrm{NU7}}=A+3(H_3-A)=13,219,200-2A.$$

No numerical activation height is assigned here. Nor does retiming the halving function automatically retime a funding stream whose endpoint is specified as a literal block height. The draft does not provide such a change, so the funding-stream endpoints and the rescaled halving heights must be treated separately.

The Network Sustainability Mechanism (NSM) separates temporarily removed funds from the still-unissued scheduled subsidy. In the merged ZIP-237 draft, the issued supply $V_h$ is the total value recorded in the chain’s value pools after block $h$. Each pool is a separately tracked balance for one part of the protocol; tracking a shielded pool’s total does not reveal the values of its individual notes. The NSM reserve $R_h$ records value removed from circulation and not yet reissued. The reserve is public consensus state, not a spendable pool or an account with a spending key. In particular, it is not $21$ million ZEC minus the issued supply: that larger difference also includes future scheduled issuance.

The initial reserve recovers the historical subsidy and fees that miners left unclaimed before NU6. Since ZIP-236, a coinbase must account for its full available value, so that historical shortfall is fixed. The draft defines the seed $R_{A-1}$ as total scheduled issuance through the last pre-NU6 block minus issued supply there. The exact integer seeds for Mainnet and Testnet remain unspecified.

Let $D\ge A$ be the separately assigned height at which reissuance starts, and let $d_h$ be the non-negative number of zatoshi removed from circulation in block $h$ by whatever removal mechanisms have been deployed. With $L=5,040,000$ blocks per halving interval, the draft selects

$$f=\frac{\lfloor 6,931,680,000/L\rfloor }{{10}^{10}}=\frac{1375}{{10}^{10}}.$$

Its additional subsidy $u_h$, total block subsidy $b_h$, and reserve update are

	$u_h$			(6)
	$b_h$	$=s_h+u_h,R_h=R_{h-1}-u_h+d_h.$		(7)

All amounts are integers in zatoshi. Reissuance uses the previous block’s reserve, so a removal in the current block cannot finance its own additional subsidy. Before $D$, removals accumulate without payout. After $D$, a positive reserve pays at least one zatoshi: because $R$ is an integer and , one has $1\le \lceil fR\rceil \le R$ for $R>0$. The draft rejects a negative reserve; it does not silently clamp it to zero.

For a small exact example, take $R_{h-1}=100,000,000$ zatoshi ($1$ ZEC) and $h\ge D$. The additional subsidy is $\lceil 13.75\rceil =14$ zatoshi. Without a new removal the reserve becomes $99,999,986$; with a same-block removal of another $1$ ZEC it becomes $199,999,986$, but the current payout remains $14$. This example does not use the unassigned historical seed.