Zcash’s NU7 upgrade will cut the target time between blocks from 75 seconds to 25, giving deposits a chance to confirm sooner while leaving exchanges to decide when to credit them. The upgrade also changes what miners earn from transactions, with 40% of fees going to miners and the remaining 60% set aside for future rewards.
Summary
- NU7 takes effect at block 3,543,405, so the switch depends on when miners reach that height.
- Target block spacing falls from 75 seconds to 25, but exchanges can change how many confirmations they require before crediting deposits.
- The subsidy per block falls by about 67%, keeping scheduled daily issuance steady as the network produces blocks three times as often.
- Miners keep 40% of transaction fees, with the remaining 60% set aside for reissuance scheduled to begin at block 8,939,664.
- Zcash retains its 21 million ZEC supply cap, while funds left in the legacy Sprout pool become unspendable after activation.
Zcash has scheduled its NU7 upgrade for block 3,543,405, when the network will cut its target time between blocks from 75 seconds to 25 and start setting aside most transaction fees for future mining rewards.
The Zcash Foundation’s Zebra 7.0.0 release notes identify the software that supports the switch. For someone depositing ZEC at an exchange that requires six confirmations, the shorter interval brings the target wait for those blocks from seven and a half minutes to two and a half, assuming the exchange keeps the same requirement.
For miners, the change is in how they earn their rewards. Zcash will issue a smaller subsidy in each block to keep scheduled daily issuance steady, while miners will collect 40% of transaction fees and the remaining 60% will go into a reserve for later reissuance.
What changes between sending ZEC and getting a usable balance
A payment can pass through several different stages even when both parties use the same currency. The sender creates a transaction and broadcasts it to the network. A node checks the transaction against its rules, a miner includes it in a block, and the recipient’s software recognises the payment. The recipient then decides how many confirmations to wait for before treating the funds as available.
NU7 changes the expected spacing between the blocks in that sequence. It does not establish a guaranteed time for each of the other steps. A wallet that is offline cannot display the payment until it reconnects, and an exchange can keep a balance pending while it applies its own checks. As crypto.news reported, NU7 sets a 25-second target for blocks. The effect on a deposit still depends on the service receiving it.
A direct transfer gives the simplest comparison. If the sender’s transaction is accepted and miners include it in the next block, the recipient has a chance to see the first confirmation sooner. If the recipient is a merchant that waits for multiple confirmations before handing over goods, its policy determines how much of the benefit reaches the buyer.
An exchange adds a crediting system between the blockchain and the customer account. It can recognise the transaction onchain and show the user a pending item, then credit the account after the required count has accumulated. A trader who wants to sell the ZEC cannot use the first timestamp alone to compare exchanges. The useful comparison is the time between broadcasting the same type of transaction and receiving a tradable balance.
A six-confirmation policy also depends on how the exchange defines the count. Some interfaces count the block containing the transaction as the first confirmation. The simple calculation of six times the target spacing is a benchmark for block production, while the observed wait depends on where in the interval the transaction was sent and whether the next miner included it. A measurement should record those details before comparing results.
A wallet receiving a shielded transfer has another source of work. It scans the chain to find data it can decrypt with the relevant keys. Faster blocks can improve the payment experience while creating more frequent updates for software to process. The upgrade ran on Zcash’s testnet before the mainnet switch. Its per-block rules limit particular types of shielded work.
A comparison of confirmation policies can be expressed in minutes without guessing what any exchange will choose. At the old target, three blocks represented 225 seconds of expected production. At the new target, nine blocks represent the same target duration. Six old blocks and 18 new blocks likewise both represent 450 seconds.
| Illustrative policy | Block target | Target production time |
| 3 confirmations before NU7 | 75 seconds | 3 minutes 45 seconds |
| 3 confirmations after NU7 | 25 seconds | 1 minute 15 seconds |
| 9 confirmations after NU7 | 25 seconds | 3 minutes 45 seconds |
| 18 confirmations after NU7 | 25 seconds | 7 minutes 30 seconds |
The table multiplies the count by target spacing. It cannot measure how much work secures any specific transaction or what an exchange’s risk team will consider equivalent. Two policies with the same expected duration can have different properties if the network’s mining conditions or the distribution of block times changes.
The most useful before-and-after test would use the same service, wallet and transaction type. One timestamp would record when the user broadcasts the transaction. A second would mark inclusion. A third would record when the exchange or merchant makes the balance available. If the first interval falls and the second remains steady, the network change may have improved one part of the process while the service kept its existing checks.
A customer making a payment also has to consider the availability of the recipient’s software. A merchant using a compatible backend may be able to act as soon as its policy allows. A customer sending to a wallet that has not finished synchronising can wait for the wallet to catch up even after miners have confirmed the payment. Both experiences can be accurate descriptions of different parts of the same transaction.
For miners, changes in the pace of blocks can complicate comparisons made during the transition itself. A short sample could include slower or faster blocks than the target, and operators may update their software at different times. A one-hour reading could capture the switch and the ordinary variation in block arrivals together. Longer windows give a better view of whether realised production is settling near the target.
An operator assessing fees needs similar discipline. Comparing the total per block can give a misleading result because transactions are distributed across more blocks. A comparison based on fees per day can show how much users paid in total. The operator can then calculate how much of that total is available immediately and how much is reserved under the new rules.
The ability to make these distinctions matters more than a simple claim that the network is three times faster. For most users, the observable benefit will be a specific change to a particular payment route. For miners, the observable change will be the distribution of subsidy and fees over a period long enough to account for the greater number of blocks.
What the Orchard capacity estimate measures
The foundation’s Orchard estimate concerns the rate of transactions under a specified model. Shielded transactions can have different shapes and require different amounts of work. Two transactions can count as two transfers to the people using them and still impose different loads on the network because of the number of actions involved.
A limit on actions is consequently different from a quota on payments. It sets a bound on what one block can contain for the relevant pool. The network can combine that tighter bound with more frequent blocks. How many transactions actually fit depends on the composition of the transactions miners select and the interaction between the pool-specific and global limits.
For a wallet developer, the value of a bound is that it makes some worst-case loads easier to reason about. A user who synchronises a lightweight wallet relies on the software being able to retrieve and process the data required to discover its payments. If unusually costly blocks can dominate that work, a user may experience slower synchronisation even when individual blocks arrive more quickly.
The capacity estimate should be evaluated alongside performance under real traffic. Useful observations would include which pools account for the activity, the number of actions per transaction and how long a wallet with an older synchronisation point takes to catch up. A faster sync under everyday load and a smaller worst-case load address related but different problems.
Users cannot infer payment demand from the size of the new limits. Capacity can rise while the number of payments stays stable. Conversely, an application can generate a burst of shielded activity that makes the limits relevant even though the network’s longer-run average remains low. That distinction matters when comparing the upgrade’s usefulness with a price move around the activation date.
Why miners should compare revenue over a day or week
The change to the subsidy means a single block is a poor unit for comparing total mining revenue across the activation. A miner receiving one-third as much subsidy per block can still compete for roughly three times as many blocks over the same period. Over a long enough interval, the miner’s share of the network’s computing power matters more for its expected share of the subsidy than the number of ZEC attached to one block.
The move can still change the way payouts are distributed over time. A solo miner experiences blocks as discrete events and can go a long time without finding one. A pool combines the work of many miners and has its own accounting for distributing proceeds. A more frequent stream of smaller rewards can change the pattern of receipts even when the scheduled aggregate subsidy remains steady.
A pool statement may combine subsidy, fees and adjustments from the pool’s payout formula. To isolate the effect of NU7, a miner would need to compare the fee and subsidy components separately and use the same unit of time. Comparing a payout per block with a daily payout, or comparing two periods with substantially different computing power, would obscure the part attributable to the new rules.
Operating costs introduce a further distinction. Mining revenue measured in ZEC does not describe how much miners keep after paying electricity and hardware expenses. A pool could earn a similar amount of ZEC over a period and see the dollar value of that income change if the token price moves. A decline in net profit would not by itself show that the block subsidy schedule changed.
Transaction fees can vary much more than the scheduled subsidy. If activity rises, total fees over a day could increase even though miners retain a smaller fraction. If activity stays the same, the split itself reduces their immediate fee income. A comparison needs both the new percentage and the amount of fees to which it is applied.
There is a simple threshold for this narrow comparison. If the amount paid in fees rises to two and a half times its earlier level, miners keeping 40% would receive the same immediate fee amount as before, holding other factors constant. That arithmetic does not predict traffic. It shows why the effect on miners depends partly on the use the upgrade enables and partly on the starting level of fees.
Confirmation policies will decide what customers actually notice
Block spacing tells a wallet how often the network expects to create a new place for transactions. A wallet still has to build and broadcast a payment, a node has to accept it, and a miner has to include it. If a transaction is competing for limited space, the block interval alone does not determine its wait.
An exchange has a separate decision to make once it sees the transaction. It can display a pending deposit before it makes the balance available for trading or withdrawal. A customer could therefore see the deposit appear sooner after NU7 while waiting longer for the exchange to apply its own final credit policy.
Confirmation counts also change meaning when blocks arrive more frequently. Six blocks at the new target represent a shorter stretch of elapsed time than six at the old target. An exchange that wants to preserve roughly the same wait could move from six to 18 confirmations. The trade-off for the customer depends on whether the exchange keeps its count, changes it or temporarily pauses deposits during the transition.
Payments sent between personal wallets have a different practical bottleneck. The recipient’s wallet has to scan the chain for transactions it can decrypt. A faster first block helps, but someone opening a wallet that has been offline for days can still spend time catching up. Limits on shielded actions address that other part of the experience by bounding the amount of work each block can impose on the wallet.
That distinction also matters for measurements after activation. A sample of deposits made shortly before and after the fork could contain service downtime or withdrawals held for manual review. It would make a weak basis for estimating ordinary confirmation times. A more comparable sample would track when users submitted a transaction, when it first appeared in a block and when a provider credited it. Breaking the wait into those intervals helps isolate the part that consensus actually changes.
Three times as many blocks changes how mining results look
Miners can compare daily rewards before and after the upgrade by separating the subsidy from the fee component. The subsidy is the amount allocated by protocol rules. Transaction fees vary with the transactions users send and the fees included in blocks.
Using the block targets alone, a day contains roughly 1,152 blocks at 75 seconds and 3,456 at 25 seconds. With one-third of the subsidy per block, that produces the same scheduled aggregate subsidy over the day. The realised block count can vary, so an individual day can still come in above or below either benchmark.
A mining pool operator will therefore have to compare returns over the same time period. A chart showing the payout per block will drop at the transition by design. A chart showing aggregate subsidy over a week asks a different question. Pool fees, hardware costs, electricity and the share of network computing power a miner controls determine how much that miner keeps.
The fee split can be assessed with a separate calculation. If the subsidy accounts for 99% of a miner’s pre-upgrade rewards and fees account for 1%, cutting the fee share by 60% would reduce total rewards by 0.6%, assuming all other inputs remain constant. If fees account for 10%, the same change would reduce total rewards by 6%. Both examples are hypothetical and isolate the fee rule from changes in usage and competition.
The first comparison for mining pools is similarly sensitive to the window selected. Taking one hour on either side of activation can give unusual results if a pool happened to find several blocks or a few unusually large transactions landed close together. Measuring total fees and issued subsidy over the same number of hours gives a more interpretable result. A pool’s crediting rules can further separate when revenue is recorded onchain from when individual miners see the balance in their account.
As an illustration, a pool that accounts for a constant share of successful blocks would expect to record more block discoveries in a day under the new schedule. The smaller reward attached to each discovery changes the units in which its income arrives. If the pool reports rewards per block without also showing how many it found and how much it paid per unit of work, a user looking at the dashboard can mistake a change in distribution for a change in income. This is why a daily comparison needs both the subsidy and fee components, together with a comparable measure of participation.
The reserve changes when fees support miners
Under the Network Sustainability Mechanism, the protocol retains a record of value set aside for later reissuance. That pool gives the network a source of future rewards that originated in fees or eligible unclaimed amounts. The reserve balance and the rules for drawing it down determine how much can be made available over time.
Two periods can therefore have different relationships between use and security spending. While fees are being accumulated, current miners keep only the share paid immediately. Once reissuance is scheduled to begin, future miners can receive rewards from activity that happened much earlier. The participants who collected the original fee share and those who later receive the reserve-funded rewards may be different.
The design preserves a reason for miners to include fee-paying transactions through the portion they retain. It also raises a question about how much block demand is required before the reserve becomes economically significant. If fees are modest compared with subsidy, a large percentage of fees can still amount to a small share of the funds supporting mining.
A separate proposal to direct an additional portion of rewards towards the reserve illustrates that distinction. The contribution already specified in NU7 and a proposal for future funding are separate policy choices. A description of the launch rules should use the parameters in the upgrade specification and keep later funding proposals distinct.
The reserve creates a different question for someone tracking issuance. Value set aside from fees can be counted when it enters the reserve and again when the rules eventually reissue it. Those are separate events in the life of the same value. An accounting view that treats each as fresh supply can obscure how much is available to users at a particular height. ZIP 259 gives the event dates in blocks, which allows an observer to tell which rule is in force without extrapolating from a wall-clock forecast.
The software transition affects services as well as node operators
Zebra 7.0.0 is the stable release that supports the mainnet activation. A service using an older node can continue running software even when its view of the chain no longer follows the upgraded network. An exchange, wallet backend or pool therefore needs to consider what its own infrastructure sees at the activation height.
The distinction becomes visible when different services report different block heights. A front end can remain accessible even if the node behind it stops tracking the chain users expect. For a business that credits balances, the relevant question is whether its internal system follows the same consensus rules as the network on which customers are sending funds.
The release preparations included fixes affecting synchronisation and verification. Those fixes address operational behaviour alongside the consensus upgrade. For an operator, the switch therefore involves more than checking the advertised block interval. It includes running a compatible version and making sure the service’s dependencies continue to read and process the chain correctly.
Testnet provided a place for developers to exercise the rules before the mainnet change. It supplies evidence that the code can process blocks under the new settings in a testing environment. Mainnet adoption depends on the operators who support actual wallets, deposits and mining. Their behaviour becomes observable through the chain and through any service notices issued around activation.
An exchange preparing for the transition has to reconcile two records. Its node tracks blocks and the transactions in them, while its customer ledger records what users can trade or withdraw. A chain upgrade can proceed while the exchange keeps those ledgers apart for a period, particularly if the service wants to confirm that deposits observed before the upgrade remain visible to its upgraded infrastructure. The time a customer waits is then governed by when the service reconciles the ledgers and resumes crediting accounts.
Sprout gives the upgrade an irreversible consequence for some funds
The original shielded pool is a legacy part of Zcash’s history. Later pools gave the network different ways to represent shielded transactions, but a balance left in Sprout still depends on the formats that can spend from that pool. NU7 changes the valid transaction versions, which makes the format question material for the owner of a legacy balance.
A wallet balance displayed as ZEC gives the owner the currency amount. It may take more information to identify the pool and the available spending path. The action relevant to a legacy holder is moving funds through a compatible route before the consensus change. Updating software on its own cannot create a valid transaction after the old format ceases to be accepted.
A public figure for the balance in a pool cannot tell an observer how many holders are actively using it or what portion is recoverable with keys still available. A small number of large balances and many small inactive balances could produce the same total. The rule applies to funds remaining in the pool at activation regardless of how they came to be there.
That consequence is separate from the monetary supply cap and from fees reserved for future rewards. The protocol’s handling of an old transaction version removes a spending path. The reserve rule accounts for fees that can later be reissued according to its own schedule. The upgrade specification treats those as distinct changes, with version 4 transactions invalid from the mainnet activation height.
Sprout’s deadline is the exception to a story otherwise measured in intervals and averages. Wallets and exchanges can revise confirmation rules, and mining income will vary with activity. The rule affecting the legacy pool is fixed to the activation height. Once the upgraded chain applies the restriction, the availability of a newer wallet alone does not restore the ability to spend a balance left there.
What to watch
- Activation. The network reaching block 3,543,405 and producing subsequent blocks under the new rules.
- Deposit policies. Exchanges publishing new confirmation thresholds or reopening paused deposits.
- Orchard activity. Observed actions per block and elapsed time across busy periods.
- Mining revenue. Daily fee receipts and subsidy income compared across equivalent windows.
- Sprout. Wallet notices spelling out which legacy balances were eligible to move before activation.
FAQ
When does NU7 activate?
The rules switch at block 3,543,405. Clock time estimates change as miners produce blocks. The estimated date can change as blocks arrive. The consensus trigger is block 3,543,405.
How much faster is the block target?
The target falls to 25 seconds from 75 seconds. The target is an average across blocks, so the interval between two particular blocks can be longer or shorter.
Will exchange deposits always arrive three times faster?
Each exchange sets its own confirmation and credit policy. Providers can change their confirmation thresholds or keep deposits paused during the switch. Their crediting decisions determine how soon the funds appear in a customer account.
Does NU7 change scheduled daily subsidy?
The subsidy per block falls to one third as the target number of blocks triples. The per-block subsidy falls to one-third as target block production increases threefold. Compare revenue over equal periods to see the combined effect.
How much of the fee do miners keep?
Miners retain 40% of transaction fees. The remainder goes to the network reserve under the new fee rules. A miner’s receipts still depend on the total fees paid.
What happens to the rest of the fees?
The protocol sets aside 60% for future reissuance under its reserve rules. The reserve’s rules set a later height for reissuance. It is separate from the portion miners can collect when a transaction is included.
Can users spend funds left in Sprout after activation?
NU7 invalidates version 4 transactions, which Sprout transfers require. The restriction applies to legacy Sprout balances. Users of other pools face different wallet and confirmation considerations.
Does the upgrade change the ZEC supply cap?
The cap remains 21 million ZEC. The reserve changes the timing and treatment of eligible amounts within the existing monetary rules. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of November 5, 2026. Legal questions should be discussed with qualified counsel.
Leave feedback about this