# Vision for January 2027 **URL:** \ **Category:** Technology\ **Created:** [November 9, 2026, 8:29pm UTC](https://forum.zcashcommunity.com/t/vision-for-january-2027/59124 "2026-11-09T20:29:45Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![str4d](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/str4d/32/64_2.png) [@str4d](https://forum.zcashcommunity.com/u/str4d)\ **Post date:** [November 9, 2026, 9:06pm UTC](https://forum.zcashcommunity.com/t/vision-for-january-2027/59124/3 "2026-11-09T21:06:02Z")
> [@ValarDragon](#): > > - Release of the Tachyon shielded pool 2.5 months is not much time, and I haven’t seen any updates from Project Tachyon in the ZIPs repo proposing either ZIPs or updates to the Zcash Protocol Spec. The [Tachyon Roadmap](https://tachyon.z.cash/roadmap/) says “Once community consensus is reached and the proposal meets Zcash’s ZIP requirements, we will activate on mainnet” - how close is Tachyon to the latter? > [@ValarDragon](#): > > - An extensible TX format to avoid adding extra distinguishability to unupgraded HW wallets with every new shielded pool. I agree, we should get [ZIP 248](https://zips.z.cash/zip-0248) deployed ASAP. Its design has been stable for well over half a year, and I’ve been cleaning the ZIP itself up over the past week (mainly updating it to take into account other consensus changes that have been deployed in the interim). > [@ValarDragon](#): > > On raising the max block size, we currently have this ZIP open for an increase to 3MB: [Draft ZIP: Increase the block size limit to 3 MB by evan-forbes · Pull Request #1448 · zcash/zips · GitHub](https://github.com/zcash/zips/pull/1448) . Our belief is that this, and 4MB, are already safe for deployment on the network at 20s blocks, and was originally written with an expedited NU7.1 in mind. With the ongoing work in both Zakura and Zebra-Andele, we actually think 8MB is a reasonable proposal for a late January upgrade, and plan propose 8MB or higher depending on implementation status at NU8 polling time. Your rationale both here and in the linked ZIP draft solely focus on the impact on full nodes. The ZIP draft alludes to in future using OOB / PIR for wallets, but given that there are still no specifications for either of these, and thus I expect most wallets won’t have deployed solutions for this within 2 months, any proposal to raise the block size will need to analyse the impact on as-deployed wallets using the light client protocol. > [@ValarDragon](#): > > - Removal of “consensus branch ID” updates, to cease breaking wallets every NU Any proposal to remove this needs to also propose a replacement mechanism for preventing transaction replays across forks. That was the original rationale for including this mechanism in ZIP 200, as replay protection was a hard requirement by various cryptocurrency ecosystem players at the time. It would also be nice for any replacement mechanism to also handle malicious forks (i.e. a fork solely intended on disrupting the main Zcash chain, rather than the friendly forks we designed ZIP 200 to enable and protect Zcash users against). I noted elsewhere that once ZIP 248 is active, it will be pretty easy to define a sighash variant that doesn’t commit to the consensus branch ID (and other fields that prevent pre-authorization, which seems to be the main issue I’ve heard about), which users who are willing to lose replay protection could opt into. --- _[View the full topic](https://forum.zcashcommunity.com/t/vision-for-january-2027/59124)._