← Back to Blog

Building Shell Chain: The Tech Choices Behind a Post-Quantum EVM L1

·Shell Chain Team
engineeringdesignpost-quantumfounders

Why a new L1 at all?

The first question every serious investor asked us was the right one: why not fork Geth, swap in Dilithium, ship?

The honest answer is that the post-quantum upgrade is not a swap — it is a re-architecture of every layer the signature touches:

  • Address derivation changes shape (a Dilithium3 public key is ~1,952 bytes; you cannot just keccak256 it and call it an EOA).
  • Mempool gossip has to handle 50× larger transactions without amplification attacks.
  • Block storage explodes from kilobytes to megabytes per block; if you do not solve compression, you have a chain that costs $10k/month per node to operate within five years.
  • EVM precompiles for ECDSA (0x01 ecrecover) become dead code; new precompiles for Dilithium3 and SPHINCS+ have to be specced, gas-priced and hardened.
  • Account abstraction has to be native — without it, every account needs a wrapper contract just to do basic key rotation, because PQ algorithms are expected to evolve.

Every one of those changes is locally reasonable. The combination is a different chain. We chose to admit that up front instead of carrying ten years of EVM compatibility hacks into a problem they were never designed to solve.

Why Rust

We are old enough to remember the cost of every memory-safety bug in Bitcoin Core, Geth and OpenSSL. For a chain whose entire value proposition is security over a 10–30 year horizon, the language has to make memory-unsafety impossible at compile time.

Rust gave us:

  • No segfaults in production. Every unsafe block in the workspace is individually justified in a // SAFETY: comment that has to pass code review.
  • A real type system. The WorldState is a &mut reference whose lifetime is bound to the executor — you literally cannot read state while a write is in flight, because the compiler refuses to build.
  • A workspace model that scales. 19 crates, each with its own test suite, sharing dependencies through a single Cargo.toml. Adding a new milestone means adding a crate, not refactoring a monolith.
  • Mature crypto. dilithium, sphincsplus, kyber-rs and the Winterfell prover all have well-maintained Rust implementations, often by the original authors.

The cost was an honest 6-month onboarding ramp for any contributor coming from Go or TypeScript. We accepted that. The product would not survive a Solidity-tier bug surface.

Why post-quantum first, not post-quantum additionally

A common alternative path is "ECDSA today, PQ later." It looks pragmatic. It is a trap.

Three reasons we rejected it:

  1. Address commitment. Once an ECDSA address holds value, you cannot silently upgrade it — the user has to migrate to a new address, paying migration friction at exactly the moment the migration is most urgent.
  2. Harvest now, decrypt later. Every transaction signature published on chain in 2026 is a piece of evidence an adversary will try to crack in 2030 with a CRQC. There is no way to redact it.
  3. Audit surface. A dual-stack chain has both code paths to audit and both to maintain. Single-stack is half the audit surface.

So Shell Chain is single-stack, post-quantum, from the genesis block. There is no migration path because there is nothing to migrate from.

Why EVM compatibility

A common counter-argument: "if you are starting from scratch, why not pick a better VM?"

The answer is the developer market. There are ~5 M Solidity developers, billions of dollars of audited Solidity contracts, and a tooling ecosystem (Hardhat, Foundry, ethers, viem, MetaMask) that took a decade to mature. Replicating that for a non-EVM chain is a decade we do not have.

By preserving the EVM at the execution layer — Cancun spec, full opcode coverage, standard 20-byte address surface to msg.sender — every existing Solidity contract deploys unchanged. The post-quantum machinery lives below the EVM line of sight, in transaction validation. From a Solidity developer's perspective, Shell Chain is "Ethereum that survives Q-Day."

Feature-Driven Development as a discipline

Seventeen milestones in twelve months would not have been possible without process discipline. We adopted Feature-Driven Development (FDD) as the default workflow:

  1. Feature spec — a short Markdown doc per milestone in docs/features/, reviewed before implementation starts. It declares the public API change, the storage shape change, and the migration path from the previous version.
  2. Implementation — branch off main, work in PRs that link back to the spec.
  3. Integration tests — every milestone ships its own integration test crate. The test must run as part of cargo test --workspace in CI.
  4. Review record — every PR has a REVIEW.md artifact recording the issues raised and how each was resolved. Read-only after merge.
  5. Tag — only after CI is green and the multi-node soak passes.

This is slower than "move fast and break things." It is also why we have shipped seventeen tagged versions, each runnable, each documented, each auditable from the outside.

Audit-driven hardening

After M5, we ran a comprehensive external security audit. It surfaced 69 findings — from critical (one consensus liveness corner case) to informational (better error messages on a misconfigured node). Every finding was resolved before tagging v0.6.0, and the entire fix log is public at docs/AUDIT_FIXES.md.

We are publishing it not because we are proud of every finding — some of them were embarrassing — but because the only audit signal you can trust is one you can reproduce. Every closed finding links to the commit that closed it. You can git log the entire investigation.

We will run a second external audit before mainnet genesis, and we will publish that too.

What we did not do

For the same reasons we said yes to certain things, we said no to others:

  • No proof-of-stake. v0.17 ships with a permissioned weighted PoA (wPoA) for the testnet phase. Switching to delegated PoS is on the post-mainnet roadmap. Shipping PoS now would have meant launching validator economics before the chain was audited — a sequencing mistake we have watched other projects make.
  • No sidechains, no rollups, no L2s. Shell Chain is a base layer. The STARK aggregation work pulls some L2 ideas (proof-then-discard) into the L1 itself, which is a more interesting problem and a more durable moat.
  • No premined treasury. Token economics are still being designed, and will be published as a draft for community review before any token generation event.

What this signals

If you are evaluating Shell Chain as an investor: every claim on the marketing site has a code link in lib/chain-facts.ts. The chain-facts file is the single source of truth — when shell-chain ships a release, we update that file and the site rebuilds.

If you are evaluating Shell Chain as a researcher: the cryptographic choices, the architectural justifications and the audit log are all in the open. We welcome adversarial scrutiny — that is precisely why we are building this in the open.

The next operational milestone is the public incentivised testnet. The underlying engineering is already where it needs to be.