In our previous article, we described the early days of Lean Ethereum and the PQ interop event in Cambridge where client teams first demonstrated cross-client P2P messaging. Since then the pace has accelerated. Pier Two has participated in Devnet 1 with Lantern (completed in mid-January), completed Devnet 2 last week, and is now actively participating in Devnet 3, which also launched last week. Each devnet has built on the last, progressively closing the gap between a research prototype and a protocol ready for mainnet. This article walks through what each devnet tested, what the results tell us, our progress with Lantern, and what comes next.
Devnet 1: Running Post-Quantum Signatures End to End
As covered in our previous article, Devnet 0 at the Cambridge interop was a pre-devnet focused on basic multi-client interoperability and consensus without post-quantum signatures. Devnet 1, which ran from late December 2025 through mid-January 2026, was the first sustained multi-client network running post-quantum signatures end to end.
What was tested
There were six independent client teams that participated: Zeam, Ream, Qlean, Lantern, Lighthouse, and Grandine. Each client implemented 3SF-mini, a simplified version of Ethereum’s finality model, and ran on a dedicated server. The network used four-second slots with XMSS signatures for all validator operations. XMSS is a hash-based signature scheme designed to be quantum-resistant, unlike the BLS signatures that Ethereum mainnet currently relies on.
The fundamental question Devnet 1 set out to answer was whether multiple independent implementations could run a consensus protocol using post-quantum signatures, stay in sync, and achieve finality.
Results
All six clients successfully signed attestations using XMSS, with signing times ranging from 5 to 25 milliseconds and verification averaging around 5 milliseconds, and the network achieved finality. The devnet also helped surface important implementation issues.
With only six nodes, losing even one or two clients did drop the network below the two-thirds supermajority needed to finalize, and the retrospective catalogued problems including:
- Serialization mismatches between clients, causing signature verification failures and missed votes
- Peer-to-peer connectivity challenges, including QUIC handshake timeouts and occasional disconnections
- Infrastructure issues including memory leaks and disk space exhaustion
When these issues were identified, all client teams were able to work collaboratively to resolve them.
Overall, Devnet 1 was a success: it proved that a consensus protocol using post-quantum signatures works across independent implementations, and the lessons learned directly shaped the priorities for Devnet 2.
Devnet 2: Adding Aggregation
Devnet 2 ran through late February 2026 and was the first devnet to exercise post-quantum signature aggregation under real network conditions.
Why Signature Aggregation Matters
Before describing Devnet 2, it helps to understand the problem it addresses. In Devnet 1, every validator produced an individual XMSS signature for each attestation, and all of those signatures were included in every block. An individual XMSS signature is roughly 3.1 kilobytes. For a small test network of six validators, that is manageable. For a network the size of Ethereum mainnet, it is not: thousands of individual signatures per block would consume significant bandwidth and storage.
On Ethereum mainnet today, this problem is solved by BLS aggregation. BLS signatures have an algebraic property that allows them to be added together: no matter how many individual signatures are combined, the result is always a single 96-byte value. This is elegant and efficient, but BLS relies on elliptic curve pairings, which are vulnerable to quantum computers.
Hash-based signatures like XMSS do not have this algebraic structure. Two XMSS signatures cannot simply be added together to produce a combined one. The Lean Ethereum community’s solution is leanMultisig, which takes a fundamentally different approach: instead of algebraically combining signatures, it uses a zero-knowledge proof to prove that a batch of XMSS signatures were all verified correctly. The prover executes every individual signature verification inside a small virtual machine, then produces a single compact proof that all verifications succeeded. Verifying the proof is fast regardless of how many signatures were batched.
What changed from Devnet 1
The biggest change is that blocks no longer carry individual signatures. In Devnet 1, every attestation included its own XMSS signature. In Devnet 2, the block proposer collected individual signatures as they arrived over the gossip network, then used the leanMultisig cryptographic library to aggregate them into a single compact proof before the block was published. This is the first time zero-knowledge signature aggregation has been exercised under real multi-client network conditions.
To make aggregation possible, validators now sign only the attestation data (the slot, head, target, and source checkpoints) rather than the full attestation object. Since every validator attesting to the same view of the chain signs the same bytes, their signatures become eligible for batch aggregation.
Devnet 2 also introduced checkpoint sync, a direct response to one of Devnet 1’s most painful lessons. In Devnet 1, when a node fell behind or restarted, there was no way to catch up without restarting the entire network. Checkpoint sync allows a node to download the latest finalized state from a peer and resume from there, meaning individual clients can rejoin the network without disrupting consensus for everyone else.
With aggregation now tested under real network conditions, Devnet 3 turns to the next challenge: making it scale.
Devnet 3: Decoupling Aggregation from Block Production
Devnet 3 launched last week and introduces the most architecturally significant change yet: a dedicated aggregator role that decouples signature aggregation from block production. This lays the foundation for scaling post-quantum Ethereum to much larger validator sets.
Understanding The Changes
In Devnet 2, the block proposer was responsible for collecting every individual signature from the network and aggregating them all at once. For a small devnet, this is feasible. At tens of thousands of validators, it would not be: a single node cannot receive, verify, and aggregate that many signatures within a slot.
Devnet 3 addresses this by introducing a separate aggregator role, so the block proposer no longer has to do all the work itself. Validators belong to an attestation subnet, and designated aggregator nodes within that subnet collect and aggregate signatures from their peers, then forward a single proof to the block proposer. In future devnets, validators will be split across multiple subnets, distributing the aggregation workload further as the network scales.
What changes in practice
Each slot in Devnet 2 was divided into four phases. The block proposer was responsible for collecting every signature and aggregating them all before publishing a block. With committees, that no longer works: aggregator nodes need their own window of time to gather signatures from their peers and produce a proof. Devnet 3 addresses this by adding a fifth phase to the slot, dedicated to aggregation. For validators, the aggregator role is a new operational responsibility that did not exist in Devnet 2.
The specification also adapts the node’s internal state management for larger validator sets, pruning finalized attestation data and cleaning up signatures after successful aggregation to prevent performance degradation as the network grows.
Devnet 1 proved post-quantum signatures work. Devnet 2 proved they can be aggregated. Devnet 3 will test whether that aggregation can scale.
Summary
Pier Two has contributed to each stage of this progression with Lantern, from the early interoperability testing in Devnet 1 through to real signature aggregation in Devnet 2, and is now actively participating in Devnet 3.
Lantern is running the subnet-based aggregation model described above. This is the most substantial protocol change yet, and it is the first implementation of post-quantum signature aggregation distributed across a network rather than relying on a single proposer.
Each devnet iteration has been faster to stabilize than the last, and the gap between specification and working software continues to shrink. As the Lean Ethereum community moves toward larger validator sets and more realistic network conditions, Pier Two will continue contributing the implementation work, test vectors, and operational feedback that bring Lean Ethereum closer to a mainnet-ready protocol.
We would like to thank the Lean Ethereum community and client teams for their openness and collaboration throughout these devnets. The specifications continue to evolve in the open: leanSpec, leanMultisig, and leanSig.
