Registration Period for Coinholders: Protocol Feature Sentiment Poll

[aquietinvestor]

I’m opening the registration period for ZEC holders to participate in an upcoming poll to gauge sentiment on protocol features that are finished or expected to be completed within the next year, including Zcash Shielded Assets (ZSAs), the Network Sustainability Mechanism (NSM), Tachyon, Dynamic Fees, and other proposals. Coinholders will need to move their ZEC into the Orchard pool or refresh their notes during the registration window, which runs from Block 2,978,050 (July 1, 2025) through Monday, January 26 at 11:59 PM UTC.

I’ll share detailed instructions on how to vote before polling opens on Wednesday, January 28.

Please note that the safest way to participate in the poll is to wait until the registration window has ended, then move your ZEC out of the wallet you plan to use for voting before you complete the poll. That way, when you enter your seed phrase to vote, the wallet will be empty, minimizing any risk of losing funds.

I’m also looking for community members to help run voting servers. The Coin Voting 2.0 system relies on a dedicated blockchain secured by CometBFT and maintained by a group of validators, known as voting authorities. If there’s only one authority, there’s a risk that votes could be selectively included or excluded. However, with at least four independent validators, the system becomes resistant to manipulation, as long as two-thirds are honest. This ensures the results are finalized through consensus, rather than by a single centralized operator.

If you’re interested in running a voting authority or have questions about what’s involved, please respond below or send me a DM.

Lastly, transparent ZEC holders can also participate in the poll by signing a transaction, following the same process used in previous polls.

Please let me know if you have any questions.

[outgoing.doze]

Happy to help and run a voting server if there’s a way to participate in a completely public manner (no dm).

[frankbraun]

Coordinating setting up the last voting authorities comprised at least 1000 messages to coordinate the process between the unpaid volunteers over multiple days.

[outgoing.doze]

I am not sure how to interpret your reply, but I don’t mind the unpaid volunteer work over multiple days; I just don’t do dm.

[frankbraun]

The current situation is that setting up voting authorities requires intense coordination via DMs. If you offer helping but only if it’s not over DMs is akin to me saying I offer helping but only if it’s paid. Both are currently not happening.

[hanh]

Well, it’s the troubleshooting that required DMs. There are many steps which have to be followed exactly. The process isn’t user friendly for sure but I am developing new tools to facilitate the setup.

[nuttycom]

As described at last week’s Zeboot conference, I and other core engineers plan to put forth a proposal for a new, extensible transaction format for NU7 onward. The intention is to make it possible to make smaller, more focused network upgrades going forward. Anyone can watch and contribute to development of this proposal here (fair warning, this is currently more of a sketch than a well-specified ZIP): [ZIP TBD]: Define a forward-compatible, extensible transaction format. by nuttycom · Pull Request #1156 · zcash/zips · GitHub.

With this change in place, it would be possible to, for example, release an NU7 that consists of:

• this new transaction format
• explicit fees in transaction data
• the Network Security Mechanism (excluding issuance smoothing)
• quantum resilience in key generation / note encryption

Then, potentially fast-follow network upgrades, either as individual releases or in some combination:

• ZSAs
• Memo Bundles
• disallowing V4 transactions on the network
• consensus key rotation
• lockbox disbursement (generalized to “consensus accounts”, another idea floated at the summit, ZIP draft in progress but not yet in a PR)

With the new transaction format in place, it will be much simpler for wallets and other entities in the ecosystem to adapt to new network upgrades. Keep an eye on the ZIP draft(s) for more information.

[nuttycom]

To expand on this, yesterday in ZIP Sync @arya2 had a really good idea, which is that, with this new transaction format in place, it would be possible to activate the minimal NU7 on testnet, but then as soon as any of the other features are complete, go ahead and activate e.g. NU8 on testnet even if we haven’t activated NU7 yet on mainnet (due to constraints around zcashd deprecation). Then, when zcashd deprecation is complete, mainnet could be updated to whatever release has been sufficiently proven out on the testnet.

[shieldedmark]

For what it’s worth, I think this path forward (extensible NU7 transaction format → aggressively activate features on testnet) seems entirely reasonable and prudent given all of the ambient discourse on protocol features right now.

@nuttycom @arya2

[nuttycom]

Yup. Or multiple forks of testnet.

One significant advantage of the new format is that, for regression testing purposes, adapting a wallet to work on a fork with a new feature is just changing the consensus branch ID - all the existing functionality of the wallet should keep working, so you kind of get regression testing “for free”. It also lends itself to better modularity across the stack; for example, I think that feature flagging will get easier.

[aquietinvestor]

@nuttycom

the Network Security Mechanism (excluding issuance smoothing)

@nuttycom This proposal is interesting; thanks for putting it forward. Just so I understand, what’s the reason for excluding issuance smoothing (ZIP 234)?

[nuttycom]

I don’t have a strong position on introducing issuance smoothing in this network upgrade one way or the other. As we’ve discussed in the past, in order to avoid a weird jump in block rewards, the consensus smoothing itself is specified to activate at the “crossover point” which is the first block in which the block reward according to the smoothing algorithm is less than the fixed block reward. If that crossover point has been determined, the code change can go into any network upgrade prior to that block height.

[aquietinvestor]

Assuming there’s support for the NSM, I think ZIP 234 should be included in your proposal. Based on runs of the NSM Simulator, the next estimated crossover point in the issuance smoothing schedule will occur at approximately block 3,662,980, around March or April 2026.

From block 3,662,980 through block 4,406,400 (November 2028), the NSM smoothed issuance will be below the current fixed issuance (see graph). ZIP 234 could be activated at any height within this interval without increasing issuance relative to the existing schedule or “pulling issuance forward.”

Hypothetically, even if ZIP 234 were activated after block 4,406,400 but before the next crossover point, which will occur around March or April 2030, the inflationary impact of “pulling issuance forward” would likely be limited, given the relatively low remaining issuance at that stage of the curve and the recent increase in demand for ZEC. However, I don’t expect this to be an issue if there’s support to activate the NSM earlier.

[aquietinvestor]

The registration period is now closed. The eligibility window covers Orchard notes created between Block 2,978,050 (July 1, 2025) and Block 3,218,812 (Jan 26, 2026, 11:59pm UTC). You may now move your funds.

The poll will open on Wednesday, January 28th. I’ll share detailed instructions on how to participate in the coming days.

[artkor]

@aquietinvestor

However, I don’t expect this to be an issue if there’s support to activate the NSM earlier.

I believe that, for issuance to remain verifiable, smoothing should activate strictly halfway between the second halving (2,726,400) and the planned third halving (4,406,400), which places it at block 3,566,400, as clearly shown on this issuance graph:

Source

If this point cannot be met for any reason, the correct approach is not to shift it, but to avoid activating smoothing in the current cycle. Any displacement effectively alters the issuance schedule rather than just smoothing it.

I am opposed to any period in which daily issuance becomes even 1% higher than the original, publicly defined emission curve ( 1,800 ZEC per day after the second halving).

At this point, Zcash practically needs a dedicated “protocol historian” to keep track of all past adjustments: the fast start in the first 20,000 blocks, the halving of block time together with the reduction in block reward, and the subsequent corrections. The total supply formula is already complex, and further shifting of control points only increases the risk of confusion and erosion of trust in monetary policy.

[aquietinvestor]

@artkor

I believe that, for issuance to remain verifiable, smoothing should activate strictly halfway between the second halving (2,726,400) and the planned third halving (4,406,400), which places it at block 3,566,400, as clearly shown on this issuance graph:

That seems like a realistic option. Thank you!

[Reformed_Zcash]

with coins being custody on a CEX am I able to vote in these coinholder governance decisions?

[aquietinvestor]

Unfortunately, no, not at this time. You’d have to hold your coins in Orchard and use the Coin Voting 2.0 app or, if you held them transparently, it would have to be on something like a Trezor device that allows you to sign a transaction, similar to the process outlined here.