Building Delegated Proof of Stake from Scratch

When we started building Moonbeam, we needed delegated proof of stake. It didn’t exist in Substrate. So we built it from scratch.

This wasn’t because we wanted to. Building consensus-adjacent code is risky, time-consuming, and exactly the kind of infrastructure you’d hope a framework would provide. But Parity had built Nominated Proof of Stake for the relay chain, and that was what they shipped. NPoS solved their problem, not ours.

Why NPoS Exists

To be fair, NPoS makes sense for the relay chain. The relay chain needs to support a large validator set for decentralization. It provides shared security for all parachains. The Phragmen algorithm optimizes stake distribution across validators to maximize the cost of attacking any single validator.

This is genuinely clever engineering. If you’re securing a network that other networks depend on, you want the validator set to be as decentralized and evenly-staked as possible. NPoS achieves that.

But parachains aren’t the relay chain.

Parachains Have Different Requirements

Parachains delegate finality to the relay chain. That’s the whole point of shared security. You don’t need to solve the hard consensus problem yourself. Your collators produce blocks, the relay chain validators finalize them.

This changes what you need from a staking system. You’re not securing consensus. You’re incentivizing collators to produce blocks and giving token holders a way to participate in that incentivization. Delegated proof of stake, where users delegate to collators of their choice, fits this use case much better than nomination pools optimized for validator set composition.

But NPoS was what Parity built, because NPoS was what the relay chain needed. Parachain requirements weren’t the priority.

Software Grows

Our DPoS implementation started simple. Stake tokens, delegate to collators, earn rewards. Ship it.

Then came the feature requests. Liquid staking derivatives needed hooks. Different reward distribution schemes needed configurability. Edge cases around round transitions, delayed exits, and slashing conditions accumulated complexity.

This is normal. All software grows. But looking back, I’d structure it differently.

I’d split the pallet into smaller pieces. Currency issuance should be optional. Not every chain wants inflation-based rewards. The collator selection logic should leverage Parity’s existing collator selection pallet rather than reimplementing it. Composability over monoliths.

We built what we needed when we needed it. The result works, but it’s more tightly coupled than it should be.

The Ecosystem Risk

Here’s the uncomfortable part. Polkadot’s value proposition is that teams can build on Substrate and benefit from shared infrastructure. But when that infrastructure doesn’t meet your needs, you build it yourself. And once you’ve built it yourself, you start wondering why you’re here at all.

Parity and Web3 Foundation should take parachain requirements more seriously. Not as an afterthought to relay chain development, but as first-class concerns. Because the alternative is that teams fork Polkadot’s technology and build their own ecosystems separately.

This isn’t hypothetical. The Moonbeam team moved on to build Tanssi, taking the lessons learned from years of parachain development and applying them to infrastructure that actually serves application chains’ needs.

When your most experienced teams leave to compete with you using your own technology, that’s a signal worth paying attention to.