I just finished watching the latest Arborist Call and really appreciated the tone of the discussion. It’s encouraging to see the team engage in thoughtful, constructive debate around the upcoming network upgrade. Even with differing perspectives, the dialogue stays collaborative and productive, which is exactly what helps move the project forward. Whatever direction we take, I’m sure most of us Zcashers are in for the long haul! Onwards!
14 Likes
Hi all, I wanted to chime in here after speaking at Arborist on this topic.
Appreciation
First thing’s first: I really appreciate all of you brilliant and honorable beings who are moving mountains to make Zcash better!
My heartrate, voice, mic-hogging, mannerisms, etc… were all reacting during the Arborist call because it’s challenging to disagree with a group consensus for me, and especially such a brilliant group! But that kind of “challenging feeling” is more about a kind of stage fright and not at all any negative emotions towards anyone there! (The only negative emotion I’ve noticed is “fear that delay is bad” which is just another of my “fear of the great unknown” disguises.)
I generally think strategy / logistic / technical / abstractions-not-people disagreements are healthy and good and I love disagreeing with you all which is why I’m still doing it after 10+ years. 
On This Proposal
Jason is spearheading this proposal, and he and I chat once or twice a week on this, so I’ll wait for him to decide/share what should happen to this proposal. The rest of this post isn’t really about this proposal or even NU7 per se, but more forward looking: how can we improve NU8?
Also, I didn’t take up @str4d’s well-put challenge that we’ve tried a faster upgrade cycle previously, so what will be new about any new proposals of process improvements. I hope we can all ponder that more, and I’m all ears!
The only concrete thing I propose is that I believe we should decouple “exciting new features for users and the news / celebrations about them” from “network protocol upgrades” so that we remove the “pressure for hype” when making a technical decisions, assuming that the governance has provided clear higher-level prioritizations for the community. (-And the priorities should be more about features / use cases / user stories rather than which widgets go in which upgrades.)
Celebrations vs Boring Old Maintenance
As a community I believe we should decouple celebrations of delivering new valuable improvements to users from network upgrades. The first is about users using real products to do things they need or want, and that’s where we should focus our messaging, timing, and community sentiment. Meanwhile, network upgrades, IMO, should be seen as “Boring Old Maintenance”.
Yes, a network upgrade enabling ZSAs or Crosslink or whatever may seem exciting, but I still advocate turning our focus away from that as a rallying event and more towards “just some engineering mumbo jumbo that gets us one step closer to the real magic!”
So in the thread above, I felt like the pushback on NSM being not compelling was missing the point, IMO. I also happen to think NSM is awesome, personally, so that conflates things, so let me try to outline a different proposal that I’d be like 97% as happy with: Zcash ships NU 6.2 soon which includes anything, even purely “Boring Old Maintenance” changes that no one but engineers could ever care about. So as a straw-man to illustrate my point: if NU6.2 shipped ONLY ZIP 2002 soon, I would (currently) support that proposal!
If a non-technical user asks me what ZIP 2002 or this new “Nate’s NothingBurger Upgrade” does, here’s my answer: nothing. It doesn’t change your experience of Zcash in any way except when the update happens a portion of the services and products and wallets and exchanges will have downtime for maintenance.
Even an upgrade that is that unappealing is worth shipping as quickly as possible in my book, because of my preferences for the trade-offs. So if you understand that this emphasizes my underlying beliefs and preferences, then we have some common understanding (even if you still disagree on either expectations of results or just have different preferences, which I respect).
If you don’t get how Nate’s NothingBurger Upgrade could be a good idea for a certain set of preferences and want to, then read on!
The primary focus for me is to accelerate the rate of network upgrades in general. What is the actual content of the upgrade is of secondary concern. (I know this seems impractical or even ludicrous to some of you and I respect that: we just have different preferences or beliefs about the trade-offs.)
The reason I believe it’s good, is because I believe we should shift our framing of Network Upgrades from “big amazing breakthrough newsworthy hype event” to “just a boring old maintenance update (BOMU)”.
This way, from an engineering standpoint, we can be fully free to ship Boring Maintenance Improvements as often as we have any need to do so, with as little delay as necessary. Put another way, we don’t have to block important engineering-focused upgrades on the marketing department. If we unbundle newsworthiness from upgrade scope, this is one way to alleviate pressure on scoping decisions.
Thinking about this more, this also means we should be polling community sentiment for higher-level goals than “what should go in network upgrades?”, and then for anyone who reads the Boring Old Maintenance Update fine print, they should see a rationale and trade-off description for each change (or maybe a more engaged community segment does want to opine on every change, which would be cool too, just a smaller audience).
But wait, if every network is a BOMU, how can we ship amazing things like Sapling, Orchard, ZSAs, Crosslink, Tachyon, etc… ?!
It’s because for each of those things, the big exciting newsworthy hype event is something different than the network upgrade.
For example, imagine an announcement someone in our ecosystem makes about a new regulated USD stablecoin integration to Zcash! AWESOME! (-except for Zooko and the other USD bears, which I get. ) This is big news! Let’s have parties at conferences and online calls and demo videos and stuff!
Wait! and engineer asks, how is it implemented? Just some boring old maintenance updates and then some weird regulatory thing and some institutions, but I can’t remember if it’s Circle or JP Morgan or if they’re even separate conglomerates anymore, and anyway they do some thing, and there’s a bridge to an L2, and something something finality ZSAs something. But check out my wallet, I have dollars in the shielded pool!
That is the explanation. And if the engineer digs in and finds another engineer who understands Zcash, then they explain: “Oh, yeah, Arc is Circle’s L2, and there’s a permissionless bridge using that transfers USDblah tokens to the user’s Orchard ZSA receiver.” The first questioning engineer says “Oh wow, I didn’t know Zcash could do that, how did that happen?”
THEN the Zcash engineer says: “well, we had a network upgrade that enabled ZSAs, then one that enabled Crosslink, then when the team started deploying their bridge they realized they.had to have a consensus change in Zcash to support light client safety of Crosslink finality lookups, which we never anticipated, so we did another network upgrade. We also implemented quantum resilience in a different network upgrade in the middle of those, and we realeased a v2 of Crosslink that enabled some new staking features and lowered time-to-finality from ~15 minutes to ~1 minute, but that’s still not fast enough for the USDblah users to notice, even though we think it’s cool and helpful for exchange deposits.”
If we had that mindset moving forward, then we can stop worrying about which features are “noteworthy” and focus on “what should the roadmap be, given the dependencies and the priorities coming out of governance?”
Ecosystem Disruption
I probably have a preference (aka value) for a different set of trade-offs for ecosystem disruption than some of the other devs. I think mine is much closer to the “move fast and break things” mentality from Silly Valley where I live, which probably influences me.
The highlight the trade-offs: which do you prefer?
- BOMU: Boring Old Maintenance Updates disrupt your favorite wallet/exchange/product/service/tool four times per year, and also sometimes big newsworthy events about new features or products from around the ecosystem.
- Well Designed Big-News Omnibus Updates which disrupt your favorite wallet/exchange/product/service/tool once every two years and come with a lot of attention and new features and products.
I prefer the former, because of the trade-offs as I see them, and I’ll try to describe how I see the trade-offs for both:
For BOMU, the trade-offs I imagine are:
- Products that support the protocol are used to regular disruptions. Their engineering team has the same people as last time and knows where that one devinfra file is they have to tweak to ensure the Zcash deployment uses that other internal subsystem instead of the Bitcoin-like one. The product owner knows Zcash is disrupted quarterly and includes that in their summary roadmap reports to executives, so the PO doesn’t have an upset exec calling them in the night to explain why the Zcash support is down for maintenance. The users know about this maintenance window and some of them learn to plan around it.
- Other products/services can’t keep up. It’s too much hassle and pain. Their users keep complaining. They decide to wind down Zcash support. Downside: that thing no longer has Zcash support. Upside: the less responsive, less dedicated-to-Zcash products/services stop attracting Zcash users, so the experience across the Zcash ecosystem becomes generally more smooth and well supported. (Obviously this is always a balancing act!)
- The time between a new protocol improvement being conceived and that improvement enabling users to benefit is minimized on average.
- It’s more likely different potential protocol improvements interfere with each other. It’s also more likely we discover that sooner for any issues that come up after activation and could not be plausibly or consistently identified earlier in design/implementation/testing.
- The set of code and features the dev community supports is released more often and higher quality (because the devs get vendor / end user feedback much faster) while at the same time, the Zcash dev community cannot support as wide of a range of use cases, features, and functionality in their software.
- The more engaged and responsive non-Zcash-centric product teams, by dint of grappling with more frequent disruptions is more likely to build their own Zcash tooling, and some of that may be open source. They also do more of the actual person-hours of engineering to support Zcash versus today where I believe (tentatively) Zcash devs take on too much scope.[1]
For Omnibus Upgrades the trade-offs I see are:
- For me, this is the most important downside: If a new improvement is possible to the protocol, there’s a tricky choice between wait until the next Omnibus Upgrade is out, and then deploy the new improvement OR delay the next Omnibus Upgrade to incorporate this new improvement.
- If we were to consistently choose the former, then the time-to-usability of any improvement is longer than BOMU on average, and that has compounding effects (e.g. we don’t learn how valuable improvement is until the ecosystem rolls it out and users interact with it, and the longer that delay the less responsive Zcash evolution can be).
- If we consistently choose the latter, then each Omnibus gets repeatedly delayed.[2]
- The third joke option: stop inventing brilliant new improvements so rapidly, you mad geniuses!
- The set of features are developed integratedly, so the protocol and code designs, testing, etc… can leverage the knowledge of multiple features simultaneously, in contrast to BOMU where the earlier features can’t effectively take into account later features and instead the earlier functionality has to be adjusted for both to accommodate each other, or else the new functionality has to contort itself to preserve compatibility of the old functionality.
- There’s more going on in the upgrade, so different users who want different functionality in the upgrade can be simultaneously satisfied. This means there may be more momentum/buzz/synergy/coincidence of different user populations getting activated at the same time and this might strengthen the positive feedback loop of network effects across all users. Imagine two different features shipping at different times that appeal to totally disjoint user groups. Each group gets excited for a bit around their new feature activation, then goes back to life. Their excitement doesn’t overlap, and they’re less likely to interact or notice each other. Meanwhile, in an Omnibus upgrade, both communities are activated at the same time, and they may overlap and interact.
- There’s more going on in the upgrade, so it’s can be more exciting to describe to people: “This upgrade has X and Y, and not only that but Z!”
- -and the same description may also lose people: “Awesome, I love X! Wait, what is Y again? Is that something I want? I don’t understand how Z interacts with X, can you explain that?” (This includes end users but also everyone in the dev ecosystem: marketer/influences, engineers, bizdev folks, etc…)
- There’s more going on in the upgrade, so there’s a greater chance of bugs, unexpected outcomes, etc… It’s harder for engineers to understand all of the changes at once. (In BOMU, engineers still have to understand new and old together except they are likely to implicitly rely on some “practical lessons” of the older from experience / lessons in the field, so as much as they rely on that, and as much as those lessons are not misleading, then they have a smaller scope of understanding the new functionality.)
Fin
Ok, so that’s where I’m coming from from a very high-level generic level: more rapid mundane technical upgrades with separate celebratory milestones.
-and yes, I didn’t address @str4d 's very well put challenge to propose a logistical / process change that is something we haven’t already tried and believe has a chance at working.
This also means I haven’t really addressed anything about this thread’s proposal or NU7 specifically.
I personally hope we can keep brainstorming and seeking out any roadmap improvements that could help ship faster. Meanwhile I recognize “ship faster” means different things for different trade-off affinities. For me it means more rapid upgrades regardless of content, but I know for others it means shipping NU7 faster, and sticking with high quality / integrated / news-worthy, concentrated disruption strategy.
Whichever route we take as a community, I’m honored to be taking it with you all!
I wonder if we can find good ways to assess if we “do too much” or “not enough” scope wise as a dev community. I’d love anyone’s thoughts on this. ↩︎
Note: on the Arborist call I claimed this was happening for NU7, but I’m not very confident in that claim now. In any case, I don’t think I’ve heard anyone actively advocate for this except in a few cases perceived as high value / high priority. ↩︎
13 Likes
This is all so refreshing and pure. @treasonous and @shielded-nate, I love these posts from you. I feel the same.
I am philosophically aligned with @aquietinvestor and @shielded-nate. It’s the very spirit of the post about a needed change in process to accelerate development in a decentralized context. And I love that Shielded Labs is pushing everyone else to ship more, faster.
I disagree with Nate in part, as I believe that the capabilities unlocked with a NU should warrant the time and effort needed to release and propagate them. If it doesn’t provide value, don’t ship it.
But pragmatically here, I’m most interested in the deprecation of zcashd and the proliferation of zebrad as its successor. This is a bit different than the arguments related to the timing of NU7 and what should or should not be included in any particular NU.
When we kill zcashd, everyone will be able to ship faster. In my opinion, this is of higher priority than accelerating the NU process. The NU process will benefit from the death of zcashd and the shared adoption of the new stack.
Ultimately, it is up to Shielded Labs to decide what they will do in light of the objections raised by the other core developers. But it’s my hope that we can maintain the cross-community prioritization of shedding the software that has been holding us back for so long.
14 Likes
I just jumped out of bed.. I couldn’t sleep.
I was in the Arborist call today. Which is where I first heard about this proposal, and it occurred to me that something was asserted that… couldn’t possibly be known.
In the Arborist call today @daira something like:
“The NSM won’t have much economic impact.“
My brain just realized that there’s absolutely no way that can be known a priori.
How does @daira know how much impact the NSM will have?
Isn’t it a function of how much ZEC is burned? Personally I intend to burn a significant fraction of my ZEC, and I think everyone else should too.
Sorry.. I am not only NOT excited about ZSAs, I am actively concerned that they will destroy ZEC.
@gigantes there is a use case for ZSAs where they “wrap” other currencies. If this were done to e.g. “wrap” the USD then, I believe, that ZEC could be “pegged” to the USD. This would allow asshole fat-cats with shit-tons of USD to leverage the benefits of Zcash without ever investing in it.. or at least only investing enough to extract its core value.
@conradoplg claims ZSAs are something that “everyone” wants. I think they’re an attack vector on ZEC.
I am certainly not alone in my concerns, and frankly I am surprised that people aren’t discussing how ZSAs are going to drag ZEC into the abyss with the USD when it implodes.
Of course, that the USD will implode is a non-scientific hypothesis…
People who have visceral experience of fiat abruptly losing value.. tend.. in my experience to be more concerned about their cryptocurrency being pegged to fiat.
Again @joshs seems to be making a more nuanced a defensible version of the claim @daira made, but the underlying fallacy remains… we can’t know how much value the feature has, until we ship it. Only Karl Marx was able to “predict” the future with economics.
Why are you excited about ZSAs @emersonian ?
4 Likes
I fully agree with you. Epistemic arrogance in a pure form.
interesting. where is this idea coming from?
is Ethereum or Solana for example destroyed currently? to me it seems those are the most used blockchains right now. they have millions of other assets on them and to have them tradable you got to usually have the native asset also tied to those in the liquidity pools.
also wasnt there a plan to create new ZSAs you would have to spend or burn ZEC?
8 Likes
Again, I don’t have a decided posture on this but I wanted to provide context with information from the project management tools we have at hand.
If we pay close attention, the key element that enables @aquietinvestor and @shielded-nate ‘s proposal is willingness to release new features in Zcashd (some already exist, others need to be developed).
Zcashd deprecation is, on our grand scheme of things, the most important milestone (or roadblock) of Zcash’s critical path to NU7 and future upgrades.
I crafted this critical path version of the DAG (with the help of our frenemy the AI)
Important consideration: This only has issues that depend on ECC given that we have technical limitations due to depending on ZenHub (a github based product) to generate these dependency links between github issues.
note: There’s a small inaccuracy on the NU7 part of the graph which was mentioned in yesterday’s Arborist Call by @daira, but as you see, the critical path methodology was able to prune it (not mark in yellow)
Zcashd still being around is a blocker on ZSAs, Fast Finality, Memo Bundles (which allow authenticated-safe-to-use-in-application-logic memos), Programmability (Proven feasible Research funded by ZF) and Scalability (Tachyon, Ragu, etc).
2 Likes
I had a discussion ( I think in this forum ) where “reduced volatility” (relative to the USD) was cited as a potential features of ZSA -based fiat wrapping.
Since I don’t recall (immediately) if that was a public conversation on this forum, I won’t mention the name of the party I was discussing with, but I thought they were a credible source of information on the technical properties of ZSAs.
So.. perhaps it’s worth a bit more research?
1 Like
Exactly. This kind of work should be financed by the stablecoin issuers or the US government if they are interested and certainly not by the Zcashers (same could be said for ZBTC, ZETH and so on).
Also Namada is already doing pretty much all of that already.
ERC-20 did not destroy Ethereum. They drove adoption and standardized novel new use cases for cryptocurrency.
Stablecoins are the strongest product market fit that cryptocurrency has to date.
I’m sitting on the edge of my seat to launch a ZSA. I am experiencing real financial consequences each time they are delayed. I am repeatedly disappointed by our missed deadlines and murky governance.
Zcash is not moving at “founder speed.” We need less leaders, combined teams, and stronger consequences for failures to deliver.
6 Likes
+100 for more uses cases and programmability for Zcash
3 Likes
In case you missed it, here’s a link to the discussion on the most recent Arborist Call:
4 Likes
No offence but that was my suspicion all along. People rooting for ZSA’s simply want to launch some token hoping for personal financial again. Sorry but I’m not on board for that, especially when it delays useful and critical thing like NSM.
Disagree, ZSAs have many upsides for Zcash users in general.
This is yet another thread bringing up the same old debates we have been having since 2021. I won’t copy/pasta all the threads here but the “What are the pros/cons of ZSAs” discussion has been had many times before.
Literally hundreds of thousands of $ worth of ZEC and hundreds human-hours have been spent to make ZSAs happen. No longer a question of if, but a question of when.
2 Likes
That’s a huge assumption. Maybe they want to build a real product using ZK tech secured by the Zcash network?
Of course. Probably another mysterious elusive ZSA use case that I should be really excited about even if I don’t know what it is.
On the contrary, we do know that no part of NSM will have much of a short-term economic impact. (IIRC, that’s how I qualified it on the call: specifically I was referring to the period before the NSM would otherwise activate with the existing NU7 proposal.)
The NSM has three parts:
- ZIP 233 – Adds the
zip233_amountfield to allow funds to be verifiably removed from circulation. - ZIP 234 – Issuance smoothing based on issuing a given proportion of the currently unissued balance.
- ZIP 235 – Require
zip233_amountto be at least 60% of the transaction fee for each transaction (and require coinbase transactions to be v6).
ZIP 234
ZIP 234 is proposed to only take effect at a “deployment block height” specified as follows:
[DEPLOYMENT_BLOCK_HEIGHT] is calculated to be the lowest height after the second halving at which the NSM issuance would be less than the current BTC-style issuance neglecting any ZEC removed from circulation (i.e. assuming the amount of ZEC removed from circulation is exactly 0).
According to my calculations, if ZIP 234 activates at any block height up to 3662980, which is expected on 15 February 2027, then that is the height at which the smoothing will start to take effect (assuming that the dependency on NU7 is either satisfied or removed). I created GitHub - daira/nsm-simulator: Network Sustainability Mechanism simulator as a fork of https://github.com/eigerco/zsf-simulator to calculate this, because the latter had not been updated to take account the change to the ZIP that defines the deployment block height.
The smoothing therefore has zero economic effect before mid-February 2027. Note that this height is fixed by the specification, and is independent of the funds removed from circulation before that height. It is almost certain that NU7 will deploy before mid-February 2027 anyway (if no major cryptographic flaw is found), and so it makes absolutely no difference whether it technically activates with NU7 or with a hypothetical NU6.2 — except for contributing to the overhead of an extra Network Upgrade if it is the latter.
The point where the red line diverges from the blue line in the chart above is the deployment block height. Note that the x axis shows years from the 2nd halving which was on 23rd November, 2024, coinciding with NU6 activation. Each of the subdivisions along the x axis (light grey vertical lines) is 6 months.
ZIP 235
The economic impact of ZIP 235 is estimated in the ZIP:
Over 100,000 blocks starting at block 2235515, there were 316130 transactions. 60608 of them are categorized as ‘sandblasting’ transactions. The remaining transactions have an average of 5.46 logical actions (see ZIP 317).
The total fees paid to miners from those transactions, assuming the ZIP 317 regime, would be 87.86 ZEC. 100,000 blocks is approximately 3 months of blocks. Extrapolating to a year, we would expect 351.44 ZEC in fees paid to miners over a year.
If 60% of these fees are removed from circulation, that would be 210.864 ZEC per year. [ GitHub - eigerco/zsf-fee-estimator: A simple tool to estimate Zcash transaction fees under the ZIP-317 regime ]
210.864 ZEC is USD 9092 per year at the current price of USD 43.12/ZEC. Even considering the total effect over several years, this change is probably not worth the cost of engineers’ time to implement and analyse it, frankly. Of course it could be that the actual amount is higher because of price increases or fee increases, but it would have to be a very substantial underestimate to make a difference to my opinion on this.
ZIP 233
The Motivation section of ZIP 233 describes its motivations as follows:
As already noted, point 1 does not apply at all before February 2027 (and is in any case framed as purely long-term).
I seem to remember that the reason why point 2 uses the hedging of “to the extent that this potentially …” and “it can be argued to…”, is that I insisted on it in my review. People can of course make all kinds of macro-economic arguments, some of them wrong, or at least unsupported. IIRC, the ZIP Editors tried and failed to get the ZIP owners to provide more substantive support for this argument 
As long as money in a given currency is not actually available to be bought, believing that it benefits other holders to publically “remove it from circulation” via some specific protocol-defined mechanism (rather than in any other way, like “not selling it”) seems like magical thinking to me. What causes downward price pressure is simply the availability of ZEC to be bought in exchange for fiat or goods and services. It’s just a matter of supply and demand. I am deeply skeptical that whether a whale hoards their stash, or publically removes it from circulation, makes any macro-economic difference that would affect the fiat price — because it’s not part of the available supply for other people wanting to obtain ZEC in either case. (It might make a difference to the whales’ taxes, I don’t know. I’m not a tax accountant.) Someone who wants to remove funds from circulation can already just send them to a verifiably unspendable transparent address, or make a legally binding promise to not spend the funds and use ZIP 233 to remove them from circulation once it activates.
Explicit fees
The proposed upgrade also includes the explicit fee field, but as I already noted on the Arborist call, that is just a clean-up that was going to get in whenever the next transaction format change happened. It does not justify the cost of a transaction format change unless bundled with other substantive changes.
@zancas wrote:
Again @joshs seems to be making a more nuanced a defensible version of the claim @daira made, but the underlying fallacy remains…
@zancas, seriously, when have you heard me make a claim I couldn’t defend? I make claims I know how to defend, that’s my thing. Often in excruciating detail. I forked zsf-simulator and fixed it in order to defend the above claim. It was a bunch of work. Smh.
5 Likes
The first point isn’t correct because we would have to have two format changes. That is, a hypothetical NU6.2 would have to deploy with just the NSM and explicit fee changes in tx version 6, and then NU7 would have to deploy with tx version 7.
As I argued in the Arborist call, trying to front-load tx format changes is too risky if those changes are complicated. It is already proposed to do so for the Action group changes needed to do Qedit’s ZSA asset swap proposal. If we do so for the NU7 changes as well then we would be trying to anticipate two upgrades ahead, which is a complete non-starter.
It is extra work for the ZIP Editors and node implementors to split out {zip233_amount, explicit fee} changes from ZIP 230 and what has currently been done for tx v6. But as Josh says, the main disadvantage is having to support NU6.2 for zcashd if we wanted to get any schedule benefit at all from it. (Technically, we could block NU6.2 activation on zcashd deprecation instead of NU7 activation. But that would definitely delay NU7 substantially, because it would serialize everything and take bandwidth away from NU7 review. I think NU7 would be delayed either way, with or without zcashd support for NU6.2.)
I’m curious, @aquietinvestor: why did you not float this privately with ECC and ZF first to see whether it actually would accelerate the schedule and not just delay it? I have to say it’s quite frustrating to see a public post with a graphic of a bullet train that prioritizes just the proposal that Shielded Labs wants over almost everything else in flight, and that doesn’t take into account a bunch of technical and schedule constraints that we would have been happy to explain if you’d asked.
2 Likes
I spoke to @nuttycom and @arya2 prior to posting the proposal. I should have included you in those discussions as well. That was my oversight.
The reason the proposal includes the NSM is not simply because it’s a Shielded Labs project. We developed a zcashd implementation in anticipation that zcashd deprecation would take longer than expected, so there’s less work to get it into an NU6.2.
I want to just quickly point out that, in terms of supply and demand, burning your ZEC is economically indistinguishable from holding it in cold storage. So, I mean, you do you, but I would expect this to have exactly zero impact on the ZEC price in the short term, and given that this “donation” then gets re-emitted incrementally over the next century, it probably doesn’t make much difference in the long term either.
On a somewhat unrelated subject…
I would like to understand what Shielded Labs’ proposal is for the concrete release timeline. The earliest possible date at which a NU6.2 release could activate on mainnet would be after the node software released for the NU6.1 EOS halts, which will be 16 weeks after that release. We’re probably looking at a mid-September release for NU6.1 mainnet at this point, so those nodes will then EOS halt mid-January. In order to give the network time to upgrade, NU6.2-supporting nodes would need to be released at least 8 weeks before mainnet activation, and a release supporting testnet activation of NU6.2 would need to happen at least a month or so before that. @aquietinvestor what are your proposed timelines for feature completeness in the node implementations and supporting libraries, getting the ZIPs for the release written, audits, and testnet and mainnet activation schedule?
5 Likes