1/3 PropAMM liquidity is now fully operational on Ethereum mainnet! Three makers are live in every Titan block, and quotes are already consistently beating Binance VIP9 taker fees for retail orders (trades <$1k).

Happy 25,000,000 Ethereum 🥳 etherscan.io/block/25000000

Ethereum produces the highest-grade blockspace on the planet today. PBS has been criticised a lot, but it’s actually done a great job alleviating centralisation pressure on the core protocol. The job isn’t done yet though, let’s keep pushing the status quo forward 🫡 Post Below 👇

Ethrex @ethrex_client is already slightly faster than Reth on the @ethereum mainnet. Several pull requests that meaningfully improve speed are about to be merged, so performance will continue to climb. Even so, performance is not the main focus of the project. The real work is in building a client that is minimal, clear, and modular. That foundation makes higher performance almost trivial once the fundamentals are right, even if the industry tends to fixate on benchmarks first. Audits are being worked on. We're already talking with multiple stakers that want to start using ethrex in the L1 and we got multiple clients that are about to use it in it's L2 mode. Ethrex is on its way to becoming the strongest Rust SDK for building on @ethereum. If you want to support us, it would be of great help if you can give us a star in github. Thanks!

Ethereum transaction fees are dirt cheap and have been for all of 2025 Due to client optimizations and hard drives becoming cheaper, the gas limit ("block size") will continue to go up and keep tx fees cheap Return To Mainnet!

While this is difficult to appreciate from the outside, a major decision is at stake behind the Forkcast rankings published over the last week: Adding FOCIL to Glamsterdam or not. In my view, it would be a short-sighted decision to add FOCIL, either as a definite commitment and even more so as a conditional one (“we’ll add it to the scope and see if we can ship it”). Were no lessons learned from Pectra? The headliner process was supposed to offer ACD a format to keep the fork scope manageable. It was already a process error to keep FOCIL in consideration after it was turned down as Glamsterdam’s CL headliner. Now ACD intends to add months of delay and a complex (even if well-understood) feature on top of ePBS, itself already a significantly complex change to the block construction pipeline. This is not about the merits of FOCIL. People know well its importance and the necessity of a mechanism like FOCIL to ensure inclusion in a world of provers and high scale. Including FOCIL later is fine, and in my view FOCIL 6 second slots for H* is a very attractive option, that we should be working towards as ePBS-only Glamsterdam approaches deployment. Credible estimates give FOCIL 6s slots H* a possible deployment in early 2027, while ePBS FOCIL in Glamsterdam would possibly delay 6sec slots-only H* to the middle of 2027. This is at least 4 months of delay to ship the same package of things! This should tell you everything about the compounding testing and deployment complexity of ePBS FOCIL. In addition, we do not get to enjoy the massive scaling benefits of ePBS BALs until much later in 2026 too. This is an opportunity cost that is too often discounted. The ability to plan and make forward commitments on future forks is increased if ACD is able to protect itself from append-only decisions while increasing its cadence of forks. The positive flywheel disappears if we fail to do this, and in my view this simply does not serve our values or the interests of our community over the long run. More discussions are expected on this Thursday’s ACD.

While this is difficult to appreciate from the outside, a major decision is at stake behind the Forkcast rankings published over the last week: Adding FOCIL to Glamsterdam or not. In my view, it would be a short-sighted decision to add FOCIL, either as a definite commitment and even more so as a conditional one (“we’ll add it to the scope and see if we can ship it”). Were no lessons learned from Pectra? The headliner process was supposed to offer ACD a format to keep the fork scope manageable. It was already a process error to keep FOCIL in consideration after it was turned down as Glamsterdam’s CL headliner. Now ACD intends to add months of delay and a complex (even if well-understood) feature on top of ePBS, itself already a significantly complex change to the block construction pipeline. This is not about the merits of FOCIL. People know well its importance and the necessity of a mechanism like FOCIL to ensure inclusion in a world of provers and high scale. Including FOCIL later is fine, and in my view FOCIL 6 second slots for H* is a very attractive option, that we should be working towards as ePBS-only Glamsterdam approaches deployment. Credible estimates give FOCIL 6s slots H* a possible deployment in early 2027, while ePBS FOCIL in Glamsterdam would possibly delay 6sec slots-only H* to the middle of 2027. This is at least 4 months of delay to ship the same package of things! This should tell you everything about the compounding testing and deployment complexity of ePBS FOCIL. In addition, we do not get to enjoy the massive scaling benefits of ePBS BALs until much later in 2026 too. This is an opportunity cost that is too often discounted. The ability to plan and make forward commitments on future forks is increased if ACD is able to protect itself from append-only decisions while increasing its cadence of forks. The positive flywheel disappears if we fail to do this, and in my view this simply does not serve our values or the interests of our community over the long run. More discussions are expected on this Thursday’s ACD.

Base, the most successful Ethereum L2 by far, spends about $4K/day to inherit the security of Ethereum. That's $1.5M/year to a $460B asset (0.03 bps). The L2 roadmap has Ethereum maxis selling their virtuous alignment for less than pennies. Ethereum should focus on scaling the L1 and stop selling security and alignment for zero.

how can we properly scale blobs if top builders are censoring, artificially pushing down max throughput and pricing? cc @ralexstokes @fradamt h/t @bertcmiller for the dashboard

Truth. My latest PR removed 2.6MB of practically unreachable Reth code from our sequencer binary. Another recent one rewrote a payload service that is more explicit, leaner, faster, and yet is shorter than using Reth's API ( 121 −153)! Given the recent Reth bug(s) and npm supply chain attacks, my futuristic "smart" toolchain would constantly police the dependency tree to suggest: - Removing listed but unused dependencies. - Removing technically reachable but practically dead code from built binaries (suggesting required source changes accordingly). - Deduplicating features (if two dependencies provide the same things, maybe keep one). - Moving trivial code from dependencies to source. People keep selling "new code" as readers (especially non-technical) tend to equate "additions" to "stonks", but "subtractions" are equally if not even more crucial, especially when it comes to correctness and performance. Finally, before generating even more slop you don't understand, understand your code, your dependencies, your binary, your database, everything, please!