Base released v0.16.1 for pruned nodes. The Azul upgrade path now runs through two clients, and the deadline is tomorrow.
Base Azul already dropped every client except two. Pruned node operators still on `base-consensus` have until tomorrow to catch up.
CryptoVibe Desk · base · node-operators · infrastructure
- →Base shipped node v0.16.1 today, bumping `base-consensus` and `base-reth-node` to 0.9.1, with the update required for pruned node operators before the May 28 Base Azul deadline.
- →v0.16.0 already dropped support for all execution clients except `base-reth-node` and `base-consensus`, making the Azul upgrade a client-consolidation event, not just a routine release.
- →Watch whether Base adds a third supported client after Azul, or whether the two-client configuration becomes the permanent operating model for Base mainnet.
- pruned node → A node that only keeps recent blockchain data, discarding old history to save disk space.
- archive node → A node that keeps every piece of blockchain data from the very first block, used for historical queries.
- execution client → The software a node operator runs to process transactions and maintain the chain state. Different teams can build different clients that all follow the same rules.
Base shipped v0.16.1 today. Per the release notes, pruned node operators running `base-consensus` must update before May 28.
The release bumps `base-consensus` and `base-reth-node` from 0.9.0 to 0.9.1. Archive node operators can skip it for now. Two supported clients on all of Base mainnet: that's the only number that matters.
The bigger story came with v0.16.0. Base dropped support for all execution clients except `base-reth-node` and `base-consensus` as part of the Azul upgrade path. That's not a footnote in the release notes. That's a client consolidation.
If you're running a different execution client on Base mainnet today, you're already out. v0.16.0 made that official. v0.16.1 tightens the requirement for operators still in the supported set.
At the contract level, this matters because client diversity is what keeps a network resilient. One bug in `base-reth-node` now hits every pruned node operator on Base simultaneously. Two clients is better than one, but the Ethereum mainnet ecosystem runs five or six. That's the gap.
The tradeoff is shipping velocity for resilience. Base is moving fast on Azul, and two clients makes coordination simpler. That's the catch: simpler for the team, riskier for the network.
If you're running Base nodes in production, check your client and your pruning mode. The window closes tomorrow.
Base's two-client consolidation for Azul trades network resilience for shipping speed, and that bet looks reckless the moment a critical bug surfaces in either client before diversity is restored.
Whether Base's post-Azul release notes announce a third supported execution client option, within 60 days of the May 28 upgrade deadline.
Primary links and supporting reads used by the desk for this story.
Forward this.
