Berlin is knocking at the door and kept us occupied. We had a [VM v5.2.0](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fvm%405.2.0) release out mid March with full Berlin support and a [VM v5.3.0](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fvm%405.3.0) soon after adding EIP-2930 Access List generation functionality. Ethers became Berlin-ready with the [v5.1.0 release](https://github.com/ethers-io/ethers.js/releases/tag/v5.1.0) with the addition of typed tx support being the major change (and challenge). On the sideline Chris put some significant effort to help HardHat on the [VM v5 upgrade](https://github.com/nomiclabs/hardhat/pull/1337). While HardHat should have a Berlin-ready release out soon after integration, we generally realized that the overall dev ecosystem readiness for upcoming HFs is a systemic weak spot (where we take our share). We will give this some additional thinking if we can help here on coordination in the future.
Speaking about the future: what's going on with our client? To make it short: we will still play modest here. We will likely be able to do a first alpha release within the next 2-3 weeks being capable to do passive full-syncing on the major networks. Major role of this client will nevertheless remain for now to help us internally on development. We have started with the [EIP-1559](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1148) implementation (actually this progressed already pretty well 😀) and our client will help us significantly to test this under real world conditions early on.
We'll also start preparing for "The Merge" [tm] relatively soon (weeks), you will be able to follow the progress [here](https://github.com/ethereumjs/ethereumjs-monorepo/issues/1193). And while we'll likely not quite make it to join the [Rayonism](https://rayonism.io/) hackathon our client will enable us to connect to an ETH2 node via RPC early on and test our tech stack against the merge requirements.
Last but not least: our client significantly helped to harden our [devp2p](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/devp2p) implementation and a first *really* production-ready release is imminent (also: few weeks at most). We will continue to evolve here and next tackle a `wit/0` protocol implementation for witness syncing recently [announced](https://snakecharmers.ethereum.org/beam-sync-in-80-seconds-using-meta-witnesses/) by Jason Carver from the Python team which particularly excited us and which we can then integrate along our own [Beam Sync](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1171) experiments.