We've been working quite a lot at the EF state team! You can now see Geth moving from MPT into Partial Binary Tree (eips.ethereum.org/EIPS/eip-8…) in real time in a kurtosis devnet while it handles reorgs cross-I* fork. We're now ready to integrate Erigon, Nethermind and Besu! 🫡 We're getting more and more ready to having Binary Trees in Ethereum! 🔗👇

Four hardware wallet customer data leaks this year. Three of them in the last two weeks alone. None touched a device, a seed phrase, or a private key. All of them handed someone a list of confirmed crypto holders, with home addresses attached.

🤯 it's happening guys... @OpenRouter (just acquired by @Stripe) offers *Sign in with Ethereum* alongside Google and Github @signinethereum

One of the many wonderful things about technological progress is that is it performing a via negativa on the human soul—by stripping away everything that can be automated and replicated, it is revealing us to ourselves: showing us what it truly means to be human. Of course, that's only the case for those who have eyes to see and ears to hear. For others, it's been—and going to be—devestating.

today I am releasing the ultimate, and final DEX: zSwap. The first decentralized exchange that runs 100% on the blockchain. As a complete DeFi stack that runs forever.

Always Captain-Kirk your LLMs, they do better when treated appropriately. arxiv.org/pdf/2510.04950

Now that I've joined Ethlabs I can answer my own question. We see EF as the shepherd of Ethereum's soul aka CROPS, which is what will ensure Ethereum's relevance in a 10-to-100-year timescale. Ethlabs wants to help Ethereum win the next 2-5 years. To that end, we will be very pragmatic with addressing the pain points of builders and users TODAY, both through our own engineering/research efforts and through pushing EF/core devs to allocate resources in that direction. Ethereum needs both EF and Ethlabs. Let's win together.

The core idea behind “new state types” is to stop treating all state as equal. Some initial ideas: 1. Hot-cold state separation See EIP-8188/8295/8296. The core idea is to price cold state storage significantly higher than hot state. This would enable clients to implement hot-cold database separation, improving overall state performance. Historical analysis shows that retaining roughly 3% of the state in hot storage accounts for ~94% of all updates (on a monthly basis). 2. Temporary state A new state category that is automatically pruned after a defined time period. About 55% of state slots are written once and never accessed again, so applications can make use of this feature if emphemeral slots fit their use cases (main incentive is cheaper gas). 3. Trieless contracts Replace the contract trie with some fixed size cryptographic accumulator. Not all applications require state proofs. The state hasn't been improved since genesis. So it's about time.

Enter: EthCoordinate. tl;dr: EthCoordinate is a crypto-native organization born inside the EthStaker community, bringing together separate efforts under one umbrella to help with Ethereum governance coordination, support Forkcast, increase stakeholder engagement on proposed or upcoming EIPs and, of course, continue providing software, tooling, and technical support for home stakers. EthStaker started in 2020 when a loosely connected group of Ethereum enthusiasts joined efforts to speed up the development of the beacon chain. The organization steadily evolved, incorporating as a 501(c)4 nonprofit and taking up initiatives around independent participants of Ethereum's consensus mechanism, aka home stakers. Throughout the years, it has played a decisive role in coordinating the launch and operation of devnets, testnets, and mainnet hard fork upgrades; facilitating information flows and generally connecting dots that needed connecting. This year's tectonic organizational changes in the ecosystem have opened up functional gaps in Ethereum coordination. To close these gaps and continue supporting the network, EthStaker's core members are joined by mission-aligned fresh blood to aggregate efforts under one name to produce greater results than operating independently. EthCoordinate is a natural evolution of EthStaker; as Ethereum mainnet heads to its third radical consensus protocol change at a steady pace, it’s time for EthStaker to recalibrate around what Ethereum’s evolving community needs. Our mission is to facilitate interaction between stakeholders of the ecosystem to accelerate the adoption of the Ethereum network and to provide continuity for governance operations. We believe that the Ethereum mainnet is an unparalleled bedrock for the augmentation of humanity's productivity output and that ETH, the asset, is the token that aligns the incentives of all actors involved. We stand up for our values, combining technical rigor with pragmatism for Ethereum to continue being the most accessible and credibly neutral global blockchain. The team is 10 long-tenured Ethereum professionals and currently our main work streams are: ⇥ Maintain a high-quality venue for independent stakers to remain engaged and informed ⇥ Facilitate coordination around core protocol development and adjacencies ⇥ Develop and steward Forkcast, the most popular platform to track the research and engineering initiatives around Ethereum's core protocol ⇥ Facilitate research, discussion, and coordination around protocol economics in support of Ethereum's long-term economic health ⇥ Maintain open source tools and documentation used by participants of the consensus set We're energized for this chapter in Ethereum coordination & our role in it.

👀👀👀 "a new class of yield-bearing assets to non-liquidatable ETH loans."

I updated my 2023 roadmap diagram to overlay where the items that were there sit in the current Strawmap ( strawmap.org/ ). In general, a lot of overlap, but: * Some things got reshuffled in order (eg. quantum safety up-prioritized) * Some things deprioritized (eg. VDFs; many EVM improvements) * Some things replaced with superior constructions (eg. Verkle -> unified BT -> PBT; state expiry -> new state types) What's most striking, however, is that some completely new things are in the strawmap that are NOT in this diagram, because they were not in the 2023 roadmap at all. These reflect changing priorities. Notably: * First-class attention to strong privacy. This covers: keyed nonces and recent roots, aspects of FOCIL, lean privacy pool & wormholes * Aggressive scaling in the context of post-quantum. This covers: leanSPHINCS signatures and aggregation, zkzk frames (see ethereum-magicians.org/t/eip… ) * Lean-ification of the spec, to assist in formal verification (full FV of everything is only possible because of modern AI) * Blob and gas futures (this idea just didn't exist back in 2023) * Native rollups (SNARKs were nowhere near mature enough to even consider this back in 2023) * A more open design space for the "future of the EVM". zkzk frames already implies that the protocol will expose to users some ISA that's not the EVM - current leading candidates are leanISA and RISC-V. These ISAs are more simple, modern and efficient than the EVM. Once they're there, why not expose them to developers everywhere? (And then, why not turn the EVM into being an IR on top of that ISA, instead of an enshrined feature massively complicating the base protocol?) Though much of the deeper exploration here is too early even for the strawmap. * New state types are not just a replacement for expiry, they're a fundamentally different paradigm to how Ethereum does scaling A common theme in scaling, found in both state types and zkzk frames (both new ideas), is that instead of trying to maximally scale ALL ethereum activity, we try to create specialized mechanisms that have more restrictive properties that make them more scaling-friendly, while supporting the heaviest loads incurred by users and applications today (eg. token transfers, swaps) and tomorrow (eg. privacy protocols). The other common theme is treating STARKs and AI-accelerated FV as first-class objects, that we are okay betting the technical future of Ethereum on. There are recursive STARKs in many layers of the protocol, one particular primitive (the "aggregate to union verified dependencies" primitive) is expected to be used in *three* places in the protocol: EL, CL and DL. This can only be safe with formal verification, which is itself only feasible with modern AI tools. In general, many steps forward in maturity. And a huge amount of hard work by many dozens of Ethereum researchers and developers on all of these features. Ethereum will be quantum-safe. Ethereum will put users' privacy first. Ethereum will be secure. Ethereum will be censorship-resistant. Ethereum will be highly performant and scalable while satisfying the above. And Ethereum will be Lean.

We need more home stakers, not less

1/ Privacy is often thought of as politically risky. In this guest thread by @valkenburgh, Executive Director of @coincenter, he makes the case, in his own words, that the reality is the opposite: Privacy is essential to Ethereum’s promise of financial freedom and neutrality.

Infra providers (rpc, indexers, bundlers) NEED privacy to avoid regulatory risk The opposite will never be true: - "don't process this tx" - "block access to this address" - "hand me your logs for IP" If you can log, you'll become a pressure point

The Ethereum Foundation’s Trillion Dollar Security initiative has allocated a grant to support @FreedomofPress’s continued development of WEBCAT, with the goal of bringing front-end verification to Ethereum wallets and apps. Learn more ↓ blog.ethereum.org/2026/08/05…

This could be you on the Devcon stage in Mumbai👀 The ideas shared at Devcon can shape what Ethereum builds next. Bring your work, your questions and ideas to the global Ethereum community. Only a few days left to apply - apps close Aug 6! devcon.org/en/speaker-applic…

Ethereum Mainnet turns 11 today. The next chapter is already shipping.

Today we're launching EthSystems. We build confidential systems for institutional Ethereum. Institutions want to use Ethereum, but one of the biggest problems is the lack of built-in, modular privacy tools. We were the Ethereum Foundation's Institutional Privacy Task Force (IPTF) for the past year. We had hundreds of conversations with central banks, regulators, tier-one banks, and asset managers, shipping open source work the whole time. Wall Street has found crypto as an asset class, but not yet as commercial infrastructure. Institutions want to run real flows on Ethereum: stablecoins, tokenized assets, settlement. These are businesses with billions of dollars on the line, and no bank will operate in full public view. On a public ledger, confidentiality is the hard part: each party to a transaction should see what it has a right to see, and nothing more. We have a year of proof of work: private bonds, confidential stablecoin transfers, private settlement across chains, the Ethereum Privacy Map, and more. All with protocol specs and security properties, at our website. We've spent a decade working on privacy in crypto. We know there's no silver bullet. Different use cases need different systems, each designed, specified, and hardened properly, and someone has to do that work. That's why EthSystems exists. We're an independent, for-profit company, backed by long-term Ethereum-aligned investors. This is a decade-long transition, and we aren't going anywhere. If you're an institution that wants to build on Ethereum, talk to us. We're hiring: BD in New York, protocol engineers, ops: join@ethsystems.org

We've been quietly working on this for a long time, and today we finally get to share it 🙌 Introducing Shutter Governance, a voting system for municipalities, councils, universities, unions, and cooperatives where ballots stay private and anyone can verify the results 🧵 1/6

Two weeks ago, Ethereum researchers met in Berlin to continue charting the protocol's long-term trajectory, following along discussions with client teams in Svalbard in April. The updated strawmap is at strawmap.org, and I attached a picture of it to this post. My own high-level takeaways: * "Lean Ethereum" is not a single one-shot upgrade, it is a collection of improvements that will come online to the Ethereum network over the course of three or four years. But make no mistake, this IS the third major iteration of Ethereum in the same way that the Merge was the second. Almost every major piece of the protocol will be replaced: - Verification through recursive STARKs, rather than direct re-execution. Recursive STARKs become an enshrined first-class core component of the protocol - Replacing everything quantum-vulnerable with quantum-safe alternatives - Consensus: decoupled available chain and finality, one or two-round finality. Theoretically optimal security properties, simpler than today, and faster than today - Multidimensional gas - State: not just tree structure, but what *types* of state are available - Changes to client architecture ... At the same time, simplification, cleanup and future-proofing. And this will all be done in a way that minimizes disruption to existing application. We've done this before (the Merge), we can do it again. * H-star (aka Hegota) is probably Ethereum's last thematically "pre-Lean" fork. Starting from I-star, most of everything we do will have a very strong "Lean" feel to it in one way or another. * Privacy is no longer an afterthought, it is a first class goal. When designing Frames, the mempool, additions to the state tree, we explicitly ask the question "okay, how do quantum-safe, intermediary-free privacy protocol transactions go through this, and what is the overhead?" * Formal verification of everything for security. * FV also makes us much more comfortable with canonicalization (having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language). evm-asm is being written in part to become a canonical proof system for the EVM. * Quantum safety has shifted up a LOT in priority. This adds a lot of work (eg. finalizing a quantum-safe blobs design has become urgent; this work has already been ongoing for months) * Probably the single most disruptive part of the plan is the changes to state. There is growing consensus around leaving present-day-style "dynamic state" mostly unchanged, but scaling it only a medium amount, and adding new types of state that are more scalability-friendly (eg. no need for builders to sync/store all of it) but more restrictive, and that will scale a large amount. eg. possible Ethereum in 2030: 2 TB of present-day-style (dynamic) state, and 100 TB of new-style (scalable but restrictive) state This "new-style" state would work very well for ERC20s, NFTs, many defi use cases, but not eg. highly "central" objects like Uniswap contracts, or onchain order books, or other complex things (which are crucial for Ethereum but which only take up a small percentage of state) Hence, it will not be *necessary* to rewrite any apps, but it will be *very cost-effective* to eg. rewrite an ERC20 token into a newer design that uses a new type of UTXO storage that is currently being explored, so that it will have >10x lower txfees. Design of these new state types (current ideas: keyed nonces, ring buffers, UTXOs, statically accessible state, temp state) is an area where we will need a lot of feedback from application developers (incl. privacy-friendly application developers) and probably several rounds of rethinking and iteration. * In the context of a much larger total state size, we need to figure out the incentive issues around who stores this state and what motivates them to. Even saying "each node stores 1%" is not good enough - why do they store that 1% and why are they willing to serve it? This is being elevated as a first-class research area. * Ethereum will need to have a "VM" other than EVM in one form or another - at the very least, we need something like leanISA for recursive STARKs - and the gains are large in exposing it to users so that we support programmable privacy and better scalability. Right now, the most likely contenders are leanISA and RISC-V. My own ideal is that in this world, we adjust the protocol so that the EVM becomes a high-level-language compiler-level feature, and the protocol only "sees" RISC-V / leanISA directly. But this is still far away. * Gas limit increases, blob increases and slot time decreases will happen many times over the next ~5 years. We expect a large gas limit increase with Glasterdam. Each step of increased scale or decreased slot time is a matter of getting to the point where it is safe to do it, which comes from a combination of client optimization and protocol changes. Ethereum is CROPS. Ethereum is scaling. Ethereum is reinventing itself. Onward.