The Aevum Thesis
Three problems with blockchains today, and why fixing all three at once — not one at a time — is the only version of this worth shipping.
A note first. This isn't a whitepaper written to sound inevitable. It's the reasoning that got me from "there are enough chains" to "no, actually, there aren't enough of the right one." Read it, disagree with parts of it, tell me where it's wrong.
Why I'm doing this
Every few months another layer one launches promising to be faster, cheaper, or more composable than the last one. Almost none of them need to exist. I didn't want to add to that pile, so before writing a line of consensus code I tried hard to talk myself out of it. I couldn't, for three specific reasons — not vibes, not "the market is big enough for one more." Three concrete problems that the chains I actually use haven't solved, and that compound if you leave them unsolved for another cycle.
Aevum exists because those three problems share one fix, and building three separate patches felt like a worse use of a decade than building one chain that starts from the fix.
Problem 1 — Quantum
The problem
Almost every chain in production today signs transactions with ECDSA or Ed25519. Both rely on the discrete-log problem being hard for a classical computer. It isn't hard for a large enough quantum one — a sufficiently large quantum computer can solve that problem in polynomial time, via Shor's algorithm. That's not a fringe worry; it's the reason NIST ran an eight-year standardization process to replace the primitives your chain is using right now.
The evidence
NIST finalized FIPS 204 (ML-DSA) in August 2024. Federal systems already have migration deadlines attached to it. Major TLS libraries ship hybrid post-quantum handshakes today, not as a research flag but as a default. The infrastructure the rest of the internet runs on is already moving. Public blockchains — which publish every public key forever, and which a "harvest now, decrypt later" attacker can farm today for a payout in fifteen years — are moving slower than almost anything else that touches a signature.
The fix
Aevum signs every account, block header, and transaction with ML-DSA-65 (Dilithium3) from block zero. There's no classical-signature history to protect, no bolt-on migration path, no "eventually we'll add a quantum-safe address format." The chain simply never has a pre-quantum era to defend.
Problem 2 — Developers
The problem
Smart contract development is still a specialist skill a decade after Solidity shipped. That's not because the ideas are hard — reentrancy, access control, upgradeability — it's because the tooling asks mainstream developers to learn a new language, a new mental model, and a new set of footguns before they can ship anything.
The evidence
Depending on the survey, there are on the order of 22 million people who write JavaScript. Estimates for active smart-contract developers across every chain combined land closer to 24,000. That's roughly a thousand-to-one gap between the language the industry already knows and the language its contracts are written in.
The fix
Contracts on Aevum are written in native JavaScript and run inside a deterministic, Hardened-JavaScript sandbox — same syntax, same tooling, same debugging instincts your team already has, with the non-determinism (Date.now, Math.random, network access) removed at the runtime level instead of policed by convention.
Problem 3 — Centralization
The problem
"Decentralized" networks increasingly run on a short list of cloud providers, operated by validators who can afford server-class hardware and a stable six-figure stake. That's not a moral failing on any single operator's part — it's what the hardware and capital requirements select for by default.
The evidence
Running a competitive Ethereum validator effectively means server-class hardware and reliable high-bandwidth connectivity. Solana's realistic hardware floor prices out most home operators entirely. The result on both networks is stake concentrated in a handful of data-center regions — the opposite of what "anyone can run a node" was supposed to mean.
The fix
Aevum targets a 4-core laptop with 8GB of RAM as the reference validator spec, with a Raspberry Pi 4 as the supported floor. Participation is permissionless after genesis, installation is a single binary, and there's no minimum-viable data center hiding behind the marketing.
What we built
Put together, that's: a layer-1 JavaScript blockchain using Tendermint-style BFT consensus across a rotating ~100-validator committee; ML-DSA-65 signatures with BLAKE3 hashing over a Sparse Merkle Tree state; JavaScript smart contracts with async cross-contract calls; an EIP-1559-style fee market with base-fee burn; Cosmos-style delegation with shared slashing between validators and delegators; and JSON-RPC compatibility so MetaMask, ethers.js, and viem work against Aevum with no custom SDK required for basic reads and writes.
Where we are
The public incentivized testnet is the current milestone — validators run on real, unremarkable hardware, proposals go through on-chain governance, and every signature on the network is already the post-quantum one, not a placeholder waiting to be swapped later.
- Single-binary CLI installer for validators, no cluster required
- Contract playground with plain-JavaScript deploys
- Live on-chain governance for parameters and approved libraries
- Published SDK with MetaMask / ethers.js / viem compatibility
- Mainnet is Phase 4 of the rollout, gated on testnet stability
The ask
If you write JavaScript and have ever bounced off blockchain tooling, this is the on-ramp that was supposed to exist already. If you work in cryptography and want to find the hole in a young ML-DSA implementation before mainnet does, that's exactly the kind of scrutiny this needs. And if you have a spare laptop and want to run a piece of consensus instead of just reading about it, the testnet is live now, not "coming soon."
We're building a chain that's meant to last decades, not a cycle. That only works if the people who show up early stay opinionated about what we get wrong.