Brian, I appreciate the technical depth here, but I want to bring the business reality perspective because I think there is a disconnect between how researchers frame this problem and how startup founders and product teams experience it.
The “PQ Migration Plan” Problem for Startups
You said every team should have a post-quantum migration plan. I run a pre-seed Web3 startup with a 5-person team. Here is my honest reaction to that recommendation:
We are currently focused on:
- Shipping a working product
- Getting to 1,000 users
- Raising our seed round
- Not running out of money
Adding “design for post-quantum migration” to that list is like telling someone who is trying to not drown to also consider their retirement portfolio. It is technically correct and practically impossible given our constraints.
And I suspect we are representative of 90% of Web3 startups. The teams that will actually implement PQ migration plans are large, well-funded protocols with dedicated security teams. The long tail of smaller projects will either migrate reactively (when there is a concrete hard fork deadline) or die.
The Business Case for PQ Investment
That said, your cost comparison table (EF’s $2M vs. China’s $15B) is genuinely alarming. And it made me think about this differently.
For investors, the quantum threat creates an interesting dynamic. If you are evaluating two competing protocols and one has started PQ migration work while the other has not, the PQ-prepared protocol has a meaningful competitive advantage. Not because quantum computers will arrive tomorrow, but because:
- It demonstrates long-term thinking and technical depth
- It reduces future migration risk and cost
- It signals to institutional investors that the team takes existential risks seriously
I have seen this play out in other industries. Companies that started Y2K preparations early had a competitive advantage over those that scrambled at the last minute, even though the actual risk turned out to be minimal.
So maybe the right framing for startups is not “build for PQ now” but rather “make architectural choices today that do not lock you out of PQ migration later.” Use account abstraction patterns, keep your cryptographic dependencies modular, and choose STARK-friendly proof systems when there is a choice.
That is a much more actionable recommendation than “have a PQ migration plan,” and it does not require dedicated PQ engineering resources that most teams simply cannot afford.
One question for the group: are there any PQ-aware smart contract templates or starter kits being developed? A Foundry template that uses abstract signature verification would go a long way toward making PQ-readiness the default rather than an afterthought.