Just shorted ETH to try to help push us over 5k, you’re welcome.

As calls for fusaka to ship this year intensify - knowing that this may or may not be realistic - imo it's important for us to remember that eth's value proposition depends not just on zero downtime but also on credible neutrality and risk minimization for users. Ethereum is on track to grow to global ubiquity and ETH into a multi-trillion-dollar asset. Giving the public any reason to doubt eth's distinctiveness is now one of the only practical ways to potentially derail our success. It's wonderful to see the consistently rising level of ambition and dedication in our core dev community to ship the best things as fast as possible. Ongoing blobspace capacity increases are particularly urgent - we are already using about half the new capacity added in pectra three months ago. Yet, maximizing eth's safety and long term reputation must come first. Our forks must not only execute flawlessly but have the credible appearance of flawlessness and risk minimization - as we have always succeeded in doing. Personally, it always felt to me like fusaka was likely to land in Q1. I had successful contrarian predictions for the launch dates of the merge and dencun, and, to a lesser degree, pectra. If fusaka launches this year, I'll be left wondering if it was actually ready or rushed. I'm glad we're feeling the urgency to increase blobspace for our incredible customers that are growing insanely fast. Eth is in a new era of customer centricity. But, credible neutrality and risk minimization must come first - none of us wants to wake up to a world where ethereum has suffered a disaster and has become seen as a watered down commodity public chain instead of a unique global hub.

Glamsterdam may be getting some attention (it is a fork for Q1/Q2 2026). In the meantime, we should be more concerned about any potential delays to Fusaka (Q4 2025). As I have said many times, no amount of talking about Ethereum's roadmap and vision matters if we cannot achieve coordination levels that consistently meet goals on schedule. I know that some extremely talented people are now working on resolving the issues that caused teams to suggest moving the dates. I would love to see a broad agreement that the timelines matter a lot. A lot.

Amazing to see so many major L2s now at stage 1. The next goal we should shoot for is, in my view, fast (<1h) withdrawal times, enabled by validity (aka ZK) proof systems. I consider this even more important than stage 2. Fast withdrawal times are important because waiting a week to withdraw is simply far too long for people, and even for intent-based bridging (eg. ERC-7683), the cost of capital becomes too high if the liquidity provider has to wait a week. This creates large incentives to instead use solutions with unacceptable trust assumptions (eg. multisigs/MPC) that undermine the whole point of having L2s instead of fully independent L1s. If we can reduce native withdrawal times to under 1h short term, and 12s medium term, then we can further cement the Ethereum L1 as the default place to issue assets, and the economic center of the Ethereum ecosystem. To do this, we need to move away from optimistic proof systems, which inherently require waiting multiple days to withdraw. Historically, ZK proof tech has been immature and expensive, which made optimistic proofs the smart and safe choice. But recently, this is changing rapidly. is an excellent place to track the progress of ZK-EVM proofs, which have been improving rapidly. Formal verification on ZK proofs is also advancing. Earlier this year, I proposed a 2-of-3 ZK + OP + TEE proof system strategy that threads the needle between security, speed and maturity: * 2 of 3 systems (ZK, OP) are trustless, so no single actor (incl TEE manufacturer or side channel attacker) can break the proof system by violating a trust assumption * 2 of 3 systems (ZK, TEE) are instant, so you get fast withdrawals in the normal case * 2 of 3 systems (TEE, OP) have been in production in various contexts for years This is one approach; perhaps people will opt to instead do ZK + ZK + OP tiebreak, or ZK + ZK + security council tiebreak. I have no strong opinions here, I care about the underlying goal, which is to be fast (in the normal case) and secure. With such proof systems, the only remaining bottleneck to fast settlement becomes the gas cost of submitting proofs onchain. This is why short term I say once per hour: if you try to submit a 500k+ gas ZK proof (or a 5m gas STARK) much more often, it adds a high additional cost. In the longer term, we can solve this with aggregation: N proofs from N rollups (plus txs from privacy-protocol users) can be replaced by a single proof that proves the validity of the N proofs. This becomes economical to submit once per slot, enabling the endgame: near-instant native cross-L2 asset movement through the L1. Let's work together to make this happen.