We voted For: In favor of this 12 month protocol and network development allocation for Matter Labs, with monthly capped minters staggered from July 2026 through June 2027 at roughly $1M USD equivalent per month. The 5/7 Program Admin Multisig structure spanning Foundation, ZKGPS, and Security Council signers, alongside the Security Council pauser role and the Token Assembly’s independent per-minter revocation rights, gives the DAO the right combination of oversight and emergency controls. We would expect ongoing transparency on how the monthly allocations are deployed, but the per-minter capping and revocation surface keep this in a structure where the DAO retains meaningful pull-back capability throughout the year.
We voted For: This is a straightforward technical upgrade with a clear user-protection upside, so the reasoning is simple. Its headline addition, Priority Mode for ZKsync OS chains that settle directly on L1, gives users a permissionless withdrawal path if a sequencer stops processing or starts censoring, since once the oldest unprocessed priority transaction passes the four-day expiration anyone can call activatePriorityMode and open a restricted settlement path to exit. That is exactly the kind of censorship-resistance and liveness guarantee an L2 should have, and it is opt-in per chain rather than forced, so it adds a safety valve without imposing new risk on chains that do not enable it. The rest of the release, bringing ZKsync Era and ZKsync OS onto a shared protocol codebase and upgrading Era directly from v29 to v31, is sensible engineering hygiene that avoids an unnecessary intermediate mainnet upgrade while reducing long-term divergence between the two stacks. With the implementation in the public draft-v31 branch and Matter Labs sponsoring a standard protocol version bump, we see no downsides and support the upgrade.
We voted For: This is a terminology and classification cleanup from the Security Council rather than a change to the upgrade mechanism. It renames the fast-track “Emergency Upgrade” path to “Instant Upgrade” and splits it into Category 1 Security Patch, for proactive preventative fixes, and Category 2 Emergency Response, for active incidents, so a routine security patch is no longer signalled as an emergency. Since the existing governance process, authorities, and security controls are explicitly preserved and the change only affects how these upgrades are communicated, and given it reflects the shift toward continuous, AI-assisted security work, we see no downside and support it.
We voted For: This puts the unspent 5,799,091 ZK left over from the TPP-8 Community Activation pilot back to work with the team already delivering against it, rather than leaving the balance idle in the Token Governor Timelock. ZKnomist’s Season 2 record is the basis for that, with 609 posts across 23 tracked weeks producing roughly 9.75 million impressions and 81,899 engagements against principal deliverables the team met or exceeded. The structure keeps the downside contained, since this is a spending ceiling rather than a commitment to disburse, payments are monthly and only for services delivered at the same $10,000 per service month rate Season 2 ran on, ZK is priced at the seven-day moving average on the final day of each service month, and anything unused returns to the Timelock. Our one note is that the expected four to six month runway is a function of the ZK price rather than a defined term, so the engagement’s length is uncertain in a way a normal budget is not, and we would want the Foundation to flag clearly when the balance is approaching exhaustion so the Token Assembly can decide whether to continue rather than discovering the engagement has quietly ended.
We voted For: The Security Council is the independent technical check on protocol upgrades during the Risk Review period and the responder on time-sensitive security matters, so keeping it funded and staffed is not optional infrastructure. The request is 32,714,286 ZK, about $229,000 at the $0.007 reference price, moving from the Token Governor Timelock to the Council multisig for the six months from 1 August 2026 to 31 January 2027, and it is worth being explicit that this approves no capped minter, grants no minting rights and mints no new ZK. The budget is disclosed line by line, $144,000 in member fees for eight members at the rate already approved under ZIP-15, $60,000 in director fees and $25,000 in entity costs, and the proposal expands neither the mandate, the membership nor existing member terms. The one asymmetry worth naming is that entity fees were prorated to the six month window while director fees are carried in full, which the proposal explains as covering the entity’s ongoing governance and oversight obligations but does mean a half year request carries a full year line. We are comfortable supporting it on a six month rather than annual cadence given the token resource constraints the Council itself cites, and would expect the next renewal to reconcile the director fee basis against the period actually funded.
We voted For: This deploys an updated ValidatorTimelock, at 0x556DdC1617D7620f56317d2F2002FE440EA9Ad35, that lets each EraVM ZK Chain’s own ChainAdmin raise its execution delay above the current 3 hour default up to a 30 day ceiling, with 24 hours recommended and no change at all for chains that take no action. Making the control per chain rather than global is the real improvement, since raising the delay previously meant a governance action that moved it for every chain at once, and a chain wanting a longer security response window should not need the whole network to agree. The delay is the window between a batch being committed and executed on Ethereum, which is the period in which monitoring and responders can spot anomalous state transitions or withdrawals and reach for the Instant Upgrade path before the affected batch is final, and lengthening it is a reasonable answer to vulnerability discovery and exploit development getting faster. The cost should be stated plainly rather than buried: a longer delay pushes out L1 finality for withdrawals and other L2 to L1 messages, it applies to batches already committed and sitting in the queue rather than only to new ones, and in a stressed market that is a genuine liquidity and operational risk each chain has to weigh for itself. We support it because it only adds an option, it ships with its own audit against the draft-v31 branch, and the maximum is bounded, but any chain that adopts a longer delay owes its users, bridges, exchanges and integrators notice before it changes the parameter rather than after.