Hi everyone,
I want to lay out how I see Firo’s direction from here, what is driving it, and where I think we should focus.
This is not a final roadmap. It is a strategic direction. Some parts are clear. Some involve real trade-offs. On several of those trade-offs, reasonable people can disagree. That is exactly why I’m posting this now.
What Firo Should Be
Firo has always been at its best when it stayed focused on one thing: private digital money.
That focus gave us Zerocoin, Sigma, Lelantus, and Lelantus Spark. Not feature-list padding. Not trend chasing. Actual cryptographic innovation.
I believe we should stay disciplined about that.
That means Firo should remain focused on private payments, private assets, and the supporting infrastructure around them, rather than trying to become a general-purpose privacy DeFi chain. That is not a lack of ambition. It is a recognition of both technical reality and strategic reality.
Privacy-preserving DeFi is one of the hardest things in this space to design well. Every additional moving part expands the attack surface. Every complex interaction makes auditing harder. And once you add the post-quantum problem on top of that, the case for keeping scope tight becomes even stronger. A protocol focused on transfers, assets, and identity primitives is simply more practical to harden and eventually migrate than a generalized smart-contract platform.
That does not mean Firo users should be cut off from DeFi. It means we should access DeFi through ecosystems built for it, rather than trying to reproduce that stack ourselves with privacy layered on top. Bridged representations such as rsFIRO via Rosen Bridge give Firo holders access to Ethereum, BNB Chain, Cardano, and other ecosystems without forcing Firo itself to become something it was never meant to be.
More broadly, the goal should be straightforward: censorship-resistant liquidity from multiple directions. Bridges where appropriate. DEX integrations where appropriate. Fiat ramps in jurisdictions that allow them. What we should avoid is dependence on any single exchange, bridge, or chokepoint.
Privacy Only Works If People Actually Use It
Privacy tech is only as strong as its usage.
A shielded pool containing 1% of supply is not the same thing as a shielded pool containing 30%, 40%, or 50%. If we want real practical privacy, then increasing shielded usage is not optional. It is central.
We have made good progress in Spark address adoption with several exchanges, swap services, masternode services and mining pools adopting it. But it isn’t enough as legacy infrastructure have been slow about adopting them mainly because they didn’t see a need to.
That is why I think several priorities matter more than others.
Helsing: Shielding Masternode Collateral
Helsing is one of the highest-impact things we can do.
If masternode collateral can be held in Spark addresses instead of transparent ones, a very large portion of supply moves into the shielded pool in one step. That is not just symbolically important. It materially improves the anonymity environment for everyone using Spark.
The cryptography for this has already been worked out and some fine tuning remains. From a privacy-impact perspective, this is low-hanging fruit with unusually large upside.
Spark Assets: Private by Default
Spark Assets are also strategically important, but only if we get the default right.
My view is that Spark Assets should be shielded only, except where bridging to transparent external systems makes some exception unavoidable. We should not repeat the optional-privacy mistakes that other ecosystems made. If we are going to build private assets, then we should build them on a private foundation from day one.
Minimizing Transparent Addresses
Longer term, I think transparent addresses should be minimized as aggressively as practical.
In the ideal end state, transparent addressing exists only where there is a real operational reason for it, such as miner reward consolidation or bridge-related interactions.
One model worth exploring is something conceptually similar to Zano’s Gateway Addresses: a separate transparent address class specifically for services like exchanges or bridges that need account-style tracking, clearly separated from the default private user flow. That would let us preserve operational compatibility where needed without compromising the principle that ordinary usage should be private by default.
I do not think we need to force that transition recklessly. But I do think we should start designing toward it.
Why Post-Quantum Changes the Roadmap
This is the biggest reason I think our roadmap priorities need to change.
A few years ago, post-quantum risk still felt comfortably distant. It was easy to treat as a future problem. That is no longer the right framing.
Google’s December 2024 Willow result, its October 2025 Quantum Echoes result, and especially its March 2026 whitepaper on the resources needed to attack elliptic-curve cryptography do not mean Q-Day is here. No such machine exists today, and there are still enormous engineering barriers between theory and deployment. But they do mean the technical estimates are moving faster than many people expected. The March 2026 paper argues that under favorable assumptions, breaking 256-bit elliptic-curve cryptography may require fewer than half a million physical qubits, substantially below many earlier estimates.
That point matters, but it also needs to be stated carefully. The paper’s most aggressive “minutes” framing is tied to attacker-favorable assumptions and fast-clock, primed scenarios. It is not a promise that real-world blockchain key recovery is suddenly trivial. The more important takeaway is simpler: the risk window looks less comfortably distant than it used to.
That broader shift is also reflected in the surrounding ecosystem. The Global Risk Institute’s latest survey suggests experts now view a cryptographically relevant quantum computer as quite possible within 10 years and likely within 15. NIST has already finalized ML-KEM, ML-DSA, and SLH-DSA. In other words, migration planning is no longer theoretical. It is already underway at the standards level.
For a privacy coin, there is an added problem: harvest now, decrypt later. Even before a quantum attacker can break keys in real time, they can record encrypted or linkable data today and try to exploit it later. That matters more for us than for many other systems because blockchain data is durable.
Why I Think We Should Skip the Curve Trees Upgrade
We had originally planned to upgrade Spark with Curve Trees, or what Monero refers to as Full Chain Membership Proofs, to push toward global anonymity sets.
Under ordinary circumstances, that would be a very attractive upgrade.
But I no longer think it is the right use of time.
Curve Trees still sit on elliptic-curve cryptography. If we now believe that the medium-term strategic problem is post-quantum migration, then spending major engineering effort building new infrastructure on top of a foundation we already expect to replace is hard to justify. There is also the engineering reality that wallet and client infrastructure would need meaningful rework, which increases the odds that we end up doing the hard part twice.
So my current view is: do not spend years climbing to a better classical system if we already know the real destination is a post-quantum one.
That is not because Curve Trees are bad. It is because sequencing matters.
The Hard Truth About Post-Quantum Privacy
We need to be honest about this: post-quantum privacy is hard, or rather it is hard to do it efficiently.
NIST’s standards are important progress, but they solve key exchange and signatures, not the full problem of private digital cash. Private payments need much more than that: efficient proofs, confidential values, scalable anonymity, manageable transaction sizes, practical verification, and something engineers can actually deploy and maintain safely.
It would also be wrong to say that nothing exists. There is already meaningful research on post-quantum confidential transactions and RingCT-style constructions, including systems like MatRiCT and LACT+. So the problem is not the total absence of ideas. The problem is that the post-quantum alternatives are still far less mature, far less deployment-tested, and generally much less competitive than the best classical privacy systems.
That is the real difficulty. Today’s most efficient privacy constructions in cryptocurrency often rely somewhere in the stack on elliptic-curve or pairing-based assumptions. Some newer proof systems, especially STARK-style systems, are much more post-quantum friendly because they rely on hash-based assumptions instead. But those systems usually come with heavier proof sizes and performance costs. So even where the cryptographic direction is promising, the engineering trade-offs remain serious.
So I do not think the right message is “PQ privacy is impossible.” It is not. The right message is that production-grade, efficient, user-friendly PQ privacy remains a hard unsolved deployment problem even if several important research ingredients already exist.
Other Projects Show How Hard PQ Privacy Still Is
Projects like Neptune Cash and Abelian deserve credit for taking post-quantum privacy seriously. But they also show how hard the problem still is in practice: Neptune’s stack is still young enough to have already suffered a serious inflation bug, and its own throughput figures show that production-scale PQ private cash is still far from solved. Abelian makes a different trade-off by explicitly offering a more practical semi-private mode with public amounts and traceable spending, which itself says a lot about how difficult full privacy still is to deliver cheaply and at scale.
A Note on Zcash
I also want to address a claim that often comes up: that Zcash is somehow already post-quantum private or post-quantum ready. I do not think that is a fair characterization. Even Sean Bowe’s own post says more work is still needed to fully defend against quantum privacy attacks, and Orchard today is still built on classical elliptic-curve machinery. So even if some limited anonymity properties survive in narrow cases, the broader point does not change: Zcash still needs a substantial overhaul to post-quantum primitives before it can honestly be called post-quantum secure or post-quantum ready.
What We Can Do In The Meantime
Even if a full post-quantum privacy protocol takes time, that does not mean we should do nothing.
Spark Address v2
A lightweight address upgrade that gives users a quantum escape hatch makes sense to me.
The purpose here is not to preserve privacy under quantum attack. It is to preserve ownership. If credible evidence emerges that a real quantum adversary is active, users need a ready path to move funds into quantum-resistant storage rather than waiting for us to invent one in the middle of an emergency.
That mechanism needs to exist before it is needed. This will probably take half a year to do.
Harvest-Now-Decrypt-Later Mitigations
I also think it is worth evaluating mitigations against future decryption risk now, even if they are imperfect.
That includes strict one-time diversified address usage, minimizing unnecessary memo metadata, rotating receive keys more aggressively, and potentially attaching a post-quantum KEM sidecar to current encryption paths.
I am not saying all of these should definitely be implemented. Some may not justify the engineering cost. But I do think this is the right area of focus if we are looking for useful interim protection rather than cosmetic action.
Consensus Also Has A Quantum Problem
The transaction layer is not the only concern.
Firo’s fast-finality and masternode security model relies on BLS signatures for ChainLocks and InstantSend. BLS is not post-quantum secure. That means consensus hardening has to be part of this conversation too.
By contrast, I do not think the first-order quantum risk story for Firo is on the proof-of-work side. Quantum speedups are much more threatening to public-key cryptography than to hash-based work. FiroPoW also has a GPU-oriented, memory-heavy design, which does not make mining the obvious near-term attack surface. The more urgent concern is the part of consensus that depends directly on vulnerable public-key primitives.
One direction we are considering is whether Firo should eventually move back toward a pure proof-of-work model while still finding better ways to encourage actual ecosystem participation from miners.
Right now, too much hashrate behaves like mercenary liquidity: mine, send to exchange, sell, repeat. I do not think the answer is to punish that. I think the answer is to create participation paths that naturally nudge miners into the ecosystem.
One example would be requiring a Spark Name as part of mining setup or payout registration. That is a small piece of friction, but it exposes miners to Firo-native identity and wallet flows and may convert some miners from passive extractors into actual users.
That is only one idea. The broader point is that miner engagement should be designed, not just hoped for.
Funding Still Matters
Firo enters tail emission in September 2028. Until then, the development reward gives us a finite window to get the highest-priority work done. Our biggest donor, Power Up Privacy, has gone missing.
My goal would be to use that window to complete the most important pieces of this roadmap: Helsing, Spark Assets, practical PQ mitigations, and consensus hardening.
Beyond that point, we need honest discussion about sustainability that does not rely on changing tokenomics, which I personally do not favor. That means thinking seriously about service revenue, bridge-related revenue, liquidity infrastructure, crowdfunding, or other aligned models before 2028 arrives, not after.
The Real Question
The real question is not whether post-quantum risk is immediate tomorrow morning.
The real question is whether we are going to spend the next few years polishing the best version of a system we already know we will need to replace, or whether we start using that time to prepare for the system we will actually need.
My view is that Firo should choose the second path.
That means:
-
staying focused on private digital money,
-
driving more supply and activity into shielded usage,
-
reducing transparent surface area over time,
-
skipping major classical upgrades that do not survive the next architectural era,
-
building practical interim protections now,
-
and preparing seriously for a post-quantum future at both the privacy layer and the consensus layer.
Not because it is easy. Because it is necessary.
I would especially like feedback on three things:
-
whether interim PQ mitigations are worth the engineering cost,
-
what direction consensus should move in if BLS-based masternode security becomes a dead end,
-
and what sustainable revenue models are realistic after 2028.
Firo has always been strongest when it tackled hard cryptographic problems directly instead of pretending they did not exist. I think this is the next one.
Reuben Yap
Project Steward, Firo
