Quantum-Safe Treasuries: Prepping Your frfr.fun DAO for the ECDSA Migration

The cryptographic ground underneath Web3 is shifting faster than most builders expected even a year ago. For most of the past decade, "post-quantum cryptography" was a research-paper problem — real, but distant. That changed in 2026. NIST finalized its lattice-based signature standard back in August 2024, the U.S. government issued its most aggressive migration mandate yet in June 2026, and in March 2026 a joint Google/Ethereum Foundation/Stanford paper cut the estimated quantum hardware needed to break blockchain signatures by roughly 20x. Ethereum itself now has a dedicated Post-Quantum Security team and a live EIP aimed at giving accounts a native off-ramp from ECDSA.

None of this means a quantum computer is about to drain anyone's wallet next quarter. But for DAOs that graduate from a frfr.fun memecoin launch into a treasury holding real, sustained value on Base, "the cryptography we're using has a published expiration date" is no longer a hypothetical talking point — it's a documented one, with dates attached. This piece lays out what's actually been confirmed, what's still speculative, and what a DAO can reasonably do about it today without over-engineering against a threat that, by most expert estimates, is still years away.

The Ticking Clock: What's Actually Been Confirmed in 2026

NIST's algorithm standards. In August 2024, NIST finalized its first three post-quantum cryptographic standards: FIPS 203 (ML-KEM, for key exchange), FIPS 204 (ML-DSA, for digital signatures, based on the CRYSTALS-Dilithium submission), and FIPS 205 (SLH-DSA, a conservative hash-based signature scheme). A fourth signature standard, FIPS 206 (FN-DSA, based on the Falcon submission), followed later. Separately, NIST's draft guidance (NIST IR 8547, first published November 2024) set target dates for retiring classical algorithms: RSA, ECDSA, EdDSA, DH, and ECDH are slated for deprecation after 2030 and full disallowance after 2035 on U.S. federal systems. "Deprecated" doesn't mean illegal — it means new deployments need a documented risk justification; "disallowed" removes that option entirely.

The federal mandate. On June 22, 2026, President Trump signed Executive Order 14409, "Securing the Nation Against Advanced Cryptographic Attacks," directing an accelerated federal PQC migration. Two days later, OMB issued Memorandum M-26-15, "Execution of the Migration to Post-Quantum Cryptography," signed by OMB Director Russell T. Vought. It lays out a five-phase migration schedule running 2026–2035, requires civilian agencies to submit cryptographic inventories and migration plans within 120 days (roughly October 2026), and sets an objective of mitigating as much quantum risk as feasible by December 31, 2030. The U.S. military — which now uses "Department of War" as an official secondary title alongside its statutory name, Department of Defense, following a September 2025 executive order that Congress has not yet codified — is on a faster track still: its own PQC strategy calls for quantum-resistant cryptography on high-impact systems by 2030 and across the full force by 2031.

Why this matters for a public ledger specifically. None of these deadlines apply to Ethereum or Base directly — blockchains aren't federal information systems. But blockchains have a structural feature that makes the underlying threat, "harvest now, decrypt later," unusually sharp: the data is already public. Every EVM account reveals its public key the moment it sends an outbound transaction, and that key sits on-chain permanently. A quantum computer doesn't need to intercept anything; it just needs to read the chain. If Shor's algorithm — the 1994 result showing a quantum computer can solve the elliptic-curve discrete-log problem exponentially faster than any classical method — ever runs at sufficient scale against a real wallet, the private key falls out of a public key that's already sitting on Etherscan.

How close is "sufficient scale," really? This is the one place where 2026 brought a genuine, material update to the threat model, not just a policy deadline. On March 30–31, 2026, Google Quantum AI, together with Ethereum Foundation researcher Justin Drake and Stanford cryptographer Dan Boneh, published a whitepaper that cut the estimated hardware requirement to break 256-bit elliptic-curve cryptography (the exact curve family behind Bitcoin and Ethereum signatures) to under 500,000 physical qubits and as few as 1,200–1,450 error-corrected "logical" qubits — roughly a 20x reduction from the team's own 2019 estimate. The paper estimates that around 20.5 million ETH currently sits in accounts with exposed public keys, and models the top 1,000 most-exposed Ethereum accounts as crackable in under 15 hours under their attack construction. Google has adopted an internal 2029 deadline to migrate its own infrastructure off classical cryptography. To be clear about what this is and isn't: it's a reduction in the estimated resources needed, not evidence that a machine of that size exists — current largest quantum computers have on the order of a few hundred noisy physical qubits, several orders of magnitude short. Ethereum core researcher Vitalik Buterin, citing forecasting platform Metaculus, has put the odds of a cryptographically relevant quantum computer arriving before 2030 at around 20%. That's a real risk, not an imminent one — but it's exactly the kind of number that turns "someday" planning into a scheduled workstream.

Why ECDSA Breaks: The Short Version

Ethereum and Base, like almost all EVM chains, secure accounts with ECDSA over the secp256k1 curve. Its security rests on the elliptic-curve discrete logarithm problem: multiplying a point on the curve by a secret scalar (deriving a public key from a private key) is trivial; reversing that operation classically is not. A classical computer, even given unlimited time, gains no meaningful shortcut as key sizes scale up. A quantum computer running Shor's algorithm does — it turns an intractable search into a structured problem it can solve in polynomial time. Once a large enough fault-tolerant quantum computer exists, "the public key is safe to publish" — the assumption every EVM account relies on — simply stops being true.

The Post-Quantum Toolkit: Lattices, and What Else

Lattice-based cryptography is the leading replacement, but it's worth being precise about what NIST actually standardized, because the choice of which PQ algorithm matters a lot for gas costs.

A lattice is a regular, infinite grid of points generated from a set of basis vectors — trivial to navigate in two or three dimensions, but in the hundreds or thousands of dimensions used cryptographically, two problems become computationally hard for classical and quantum computers alike: the Shortest Vector Problem (find the shortest nonzero vector in the lattice) and the Closest Vector Problem (find the lattice point nearest an arbitrary target). ML-DSA builds on a related hardness assumption called Learning With Errors (LWE): given a public matrix $A$, a secret vector $s$, and a small random error vector $e$, the public key is $b = s \cdot A + e$. Strip out the error term and recovering $s$ is basic linear algebra; leave it in, and there's no known shortcut, classical or quantum, for extracting $s$ from $(A, b)$.

That's the mathematical case for lattices. The engineering case is messier, because NIST standardized more than one lattice-based scheme, and they trade off very differently:

Algorithm Standard Public key Signature Notes ECDSA (secp256k1) — 33–65 bytes 64–65 bytes Current EVM default ML-DSA-44 FIPS 204 1,312 bytes 2,420 bytes ~128-bit security; NIST's general-purpose default ML-DSA-65 FIPS 204 1,952 bytes 3,309 bytes ~192-bit security; recommended baseline for most new systems ML-DSA-87 FIPS 204 2,592 bytes 4,627 bytes ~256-bit; required for NSA's CNSA 2.0 national-security systems FN-DSA-512 (Falcon) FIPS 206 897 bytes ~666 bytes Smallest lattice signature; much harder to implement safely (constant-time Gaussian sampling is a known source of side-channel bugs) SLH-DSA-128s (SPHINCS+) FIPS 205 32 bytes ~7,856 bytes Hash-based, not lattice-based; most conservative security assumptions, largest signatures, slow to generate

(Sizes per NIST FIPS 204/205/206 and independent benchmarking writeups; see sourcing notes below.)

An ML-DSA signature is roughly 35–70x larger than an ECDSA signature, not the round "50x" figure the original draft cited. Falcon is meaningfully more compact but comes with real implementation risk. This size spread is the whole ballgame for what follows.

The EVM Problem: Bytes Cost Money, and the EVM Doesn't Speak Lattice

Every byte submitted as calldata costs gas, and the EVM has no native precompile for verifying ML-DSA, Falcon, or SLH-DSA signatures the way it does for ECDSA recovery (ecrecover) or SHA-256. Verification has to run as ordinary Solidity/Yul logic, which is slow for lattice math involving large-dimension matrix operations.

The concrete numbers here matter more than a vague "2x–5x overhead" estimate. Ethereum's own EIP-8141 design discussion — the live proposal for giving accounts a native path off ECDSA — puts standard ECDSA signature verification at roughly 3,000 gas, versus an estimate of roughly 200,000 gas for a quantum-resistant verification path using current lattice-based approaches. That's a real, sourced order-of-magnitude figure, not the original draft's rounder claim, and it's precisely why this conversation is happening at the protocol layer, not just at the wallet layer: paying 60x+ the gas for every signature verification is a serious tax if it has to be reinvented per-application in Solidity, but far more tractable if it's eventually handled by a precompile or an aggregation scheme.

Rollups blunt the raw cost problem somewhat. Since EIP-4844 (Proto-Danksharding) introduced dedicated "blob" space for L2 data, posting large amounts of calldata-equivalent data from a rollup like Base back to Ethereum L1 got substantially cheaper than posting it as ordinary L1 calldata. That does make oversized lattice signatures more tolerable on an L2 than on mainnet — but it's a mitigation, not a solution, and the on-chain computation cost of verifying the signature (as opposed to just storing it) doesn't disappear just because data posting got cheaper. Treat the "Base makes this economically viable" argument as directionally reasonable, not as a settled fact backed by a specific benchmark.

The Bigger Update: Ethereum Isn't Waiting for DAOs to Solve This Alone

This is the part of the story that's changed the most since any version of this piece could have been written even six months ago, and it changes the practical advice underneath it: Ethereum's core protocol is actively building its own path off ECDSA, which means a DAO treasury migrating today should be building toward compatibility with that path, not inventing a parallel one from scratch.

In January 2026, the Ethereum Foundation formed a dedicated Post-Quantum Security team. The following month, Vitalik Buterin published a roadmap identifying four cryptographic components that need quantum-safe replacements: consensus-layer BLS signatures (likely replaced with hash-based schemes), KZG polynomial commitments used in data availability (likely replaced with STARK-based constructions), ECDSA account signatures, and application-layer zero-knowledge proof systems. For account signatures specifically, the mechanism under active development is EIP-8141 ("Frame Transactions") — a new transaction type (0x06) that removes the protocol's hard-coded assumption that every transaction is authenticated by a single ECDSA signature, letting an account define its own validation logic, including a post-quantum scheme, natively at the protocol level rather than through third-party bundler infrastructure. EIP-8141 reached early-access draft status in January 2026 and, as of this writing, is under active consideration for inclusion in the Hegotá upgrade, expected in the second half of 2026 (following the Glamsterdam upgrade, also targeted for H2 2026, with exact mainnet dates for both still unconfirmed at the time of publication).

The practical implication for a frfr.fun DAO treasury: the multi-year hybrid architecture described below is the right immediate move, but it should be built with an eye toward EIP-8141 (or whatever ships from it) eventually absorbing this logic natively, rather than treating a bespoke Solidity ML-DSA verifier as a permanent piece of infrastructure.

Building a Quantum-Resistant Multi-Sig Treasury on Base: A Practical Roadmap

Step 1 — Move to a smart contract wallet. Native EOAs are hard-coded to ECDSA; there's no way around that without an EVM-level change. Getting custom signature logic — including a PQ scheme — into treasury validation today means operating through a smart contract wallet under ERC-4337 (account abstraction) or, once available, native protocol-level account abstraction. This part of the original draft's advice holds up well: Safe (formerly Gnosis Safe) is the dominant real-world implementation for DAO and institutional treasuries, and its Safe 4337 Module already lets a Safe act as an ERC-4337 account with fully custom validateUserOp logic — which is exactly the hook a custom PQ verification module would plug into.

Step 2 — Treat any lattice module as additive, not a replacement, for now. A hybrid design — requiring both a classical ECDSA signature and a post-quantum signature before a treasury transaction executes — is the standard recommendation from cryptographers working on this transition, and for good reason: FIPS 204 is barely two years old, and a from-scratch Solidity implementation of ML-DSA verification is far newer and far less battle-tested than ecrecover. If a bug turns up in a young lattice verifier, the ECDSA signature is the backstop; if ECDSA is broken by a quantum adversary, the lattice signature is. This is a genuinely conservative, defensible design pattern — but it is also the module most likely to need an audit-heavy custom build today, since there's no off-the-shelf, widely audited "PQ Safe module" in production yet. Treat any vendor or community project claiming otherwise with real scrutiny.

Step 3 — Plan for signer key management separately from the contract logic. This is a genuine, currently unsolved gap: mainstream hardware wallets (Ledger, Trezor) do not natively generate or sign with ML-DSA or Falcon keys as of this writing, given the much larger key sizes and different signing procedures involved. Until that changes, DAO signers adopting a hybrid scheme will need to manage PQ private key material through software-based secure enclaves or enterprise HSM setups rather than the hardware wallets they use for ECDSA today — a real operational cost, and one worth budgeting for explicitly rather than glossing over.

Step 4 — Expect the "permanent" hybrid phase to be shorter than it looks. Given how fast EIP-8141 and the broader Ethereum Foundation roadmap moved in just the first half of 2026, it's reasonable to expect that a DAO which builds a hybrid ERC-4337 module today will eventually be able to retire the custom Solidity verifier in favor of protocol-native support — likely years sooner than the "through the 2020s" framing that made sense as recently as 2025.

Risk, Regulatory, and Honesty Section

Timeline uncertainty cuts both ways. The Google/EF/Stanford paper's headline number (sub-1,500 logical qubits) is a real and material reduction in estimated requirements, but current hardware remains several orders of magnitude below that threshold, and translating "logical qubits" into physical, error-corrected hardware at scale remains an open engineering problem with its own timeline uncertainty. Treat every "Q-Day" estimate in this space, including the ~20% by-2030 figure cited above, as an informed guess, not a forecast with error bars anyone can currently validate.
Implementation risk may exceed cryptographic risk in the near term. A freshly written, unaudited Solidity ML-DSA verifier is realistically a bigger near-term attack surface for a DAO treasury than the residual ECDSA quantum risk over the next few years. Any hybrid module deployed today needs the same audit rigor — ideally more — as the multisig contract it's protecting.
None of NIST's, OMB's, or NIST IR 8547's deadlines are binding on a DAO, Base, or Ethereum. They're federal-system mandates. They matter here as a signal of where global infrastructure and vendor tooling are headed, not as compliance obligations for a crypto treasury.
frfr.fun-specific framing is platform narrative, not independent fact. Claims in this piece about frfr.fun DAOs "graduating" into treasuries, quantum-readiness as a growth or retention signal, or frfr.fun's role in any broader industry trend are self-descriptions of the platform and its incentives, not independently verified claims, and should be read as such.
This is not legal, financial, or security advice. Treasury signers evaluating a real migration should engage an experienced smart-contract auditor and, for anything above modest value, a firm with specific post-quantum cryptography implementation experience — this space is too new for "we followed a blog post" to be an adequate diligence standard.

Conclusion

The honest 2026 version of this story is more interesting than "quantum computers are coming, panic now." NIST's algorithm standards are real and final. The federal migration mandate is real, dated, and more aggressive than last year's guidance. The Google Quantum AI resource estimate is a genuine, peer-scrutinized reduction in the assumed difficulty of the attack — and it landed in the same year Ethereum stood up a dedicated Post-Quantum Security team and put a concrete EIP in front of All Core Devs. None of that means a DAO treasury is at meaningful risk of quantum compromise this year, or plausibly even this decade. But it does mean the "wait and see" posture has a shrinking runway, and that a DAO building serious infrastructure on Base today has a genuine, well-sourced reason to design its treasury architecture — smart contract wallet, modular signature validation, careful key management — so that swapping in post-quantum verification later is an upgrade, not a rebuild.

Corrections & Transparency Log

This piece is a substantially fact-checked and extended rewrite of an earlier draft. Material corrections and additions made during editing:

OMB memorandum details corrected. The original draft cited "OMB memorandum M-26-15" with an inaccurate description of its contents and timeline. M-26-15 is real, but it was issued June 24, 2026 (not earlier), implements Executive Order 14409 (not an unnamed prior order), and its actual provisions are a five-phase 2026–2035 migration schedule and a 120-day agency planning deadline — it does not itself set "2031" or "2030" as blanket deprecation dates. Those 2030/2035 dates originate from separate NIST guidance (IR 8547), which this version now cites correctly and separately.
Added the March 2026 Google Quantum AI / Ethereum Foundation / Stanford paper, the single most significant real-world update to the quantum-threat timeline since the original draft was written, with sourced figures on estimated qubit requirements and exposed ETH.
Added Ethereum's own protocol-level response (Post-Quantum Security team, Buterin's February 2026 roadmap, EIP-8141 "Frame Transactions") — this materially changes the practical recommendation from "DAOs must build this alone" to "DAOs should build toward compatibility with the protocol-level path already underway."
Replaced approximate/rounded technical figures with sourced ones: exact ML-DSA/Falcon/SLH-DSA key and signature sizes (per FIPS 204/205/206), and a sourced ECDSA-vs-lattice gas estimate (~3,000 vs. ~200,000 gas) in place of the original's unsourced "2x–5x" and "50x" approximations.
Corrected the "Department of War" reference — this is an official secondary title established by a September 2025 executive order; the department's statutory legal name remains the Department of Defense pending congressional action.
Flagged all frfr.fun-specific narrative claims (platform growth signals, "graduation path" framing) as unverified platform self-description rather than independently sourced fact, per standard practice for this blog.
Added an explicit risk/honesty section distinguishing confirmed facts (NIST standards, federal mandates, the Google paper) from genuinely open questions (hardware timelines, implementation risk of new PQ code) — largely absent from the original draft, which read as more deterministic than the underlying evidence supports.

Primary sources consulted: NIST FIPS 204/205/206 publications and NIST IR 8547 (initial public draft); OMB Memorandum M-26-15 (whitehouse.gov); Executive Order 14409 and Executive Order 14347 reporting; Ethereum Foundation (ethereum.org/roadmap/future-proofing/quantum-resistance); EIP-8141 specification (eips.ethereum.org); Google Research's "Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly" (research.google); and contemporaneous reporting from CoinDesk, IEEE Spectrum, Forbes, and CryptoSlate on the March 2026 Google Quantum AI paper.