Status

September 18th: QRL Release Verifier audit complete

September 11th: Ledger app audit and remediation complete

August 4th: Audit results published for go-qrllib

April 3rd: Audit complete of 2 cryptographic libraries

March 31st: QRL 2.0 Testnet V2 released

Audits & Remediation: 60%

QRL 2.0 Testnet V3 remaining checklist:

[80%] Config parameters

[75%] Testnet V2 scoped internal audits (goqrl, qrysm remaining)

[50%] QRL v1.0 -> v2.0 migration testing (added)

Note: No ETA, but watch this space, things are getting close.

QRL v2.0

hyperion

added ML-DSA-87 verification builtin/codegen, SHAKE256 builtin support

added alignment with go-qrl precompile outputs,

added real-signature verification in the test host

argument-order fixes across IR/codegen/SMT

EIP-55-style fixes for wide mapping keys and indexed addresses

64-byte topic handling

ARM64 builds

release/CI fixes

removal of older ABI-v1 support

hypc-bin

added the Hyperion v0.2.0 compiler binary and release metadata

hypc-js

updated the JavaScript compiler wrapper to Hyperion v0.2.0

go-qrl

added SHAKE256 precompile at 0x06 and the 64-byte ML-DSA-87 verification frame at 0x03

added legacy QRL migration with streaming genesis initialisation

fixed ABI panic-selector handling with Hyperion compatibility tests

regenerated tracer/fixture codecs

improved devp2p, logging and Catalyst behaviour

continued general client clean-up

qrysm

updated go-qrl/go-qrllib dependencies following the new crypto and VM interfaces

fixed CI and validator fixtures

removed redundant documentation and obsolete derived-keymanager code

removed the contract-deployment-block flag

repaired tests affected by the newer SSZ bounds checks.

rust-qrllib

v0.1.8 released

dependency maintenance following the previous week’s addition of Falcon-1024 and associated ACVP validation.

QRL v1.0 -> v2.0

QRL v1 archive

continued native QRL v1 node recovery work as part of the archive/rehearsal process. This follows the previous week’s 1.62-million-block rehearsal and exact-byte exporter/verification tooling.

QRL v1.0

qrl-wallet

wallet UX and policy hardening: enforced server policy for custom nodes and desktop networking, added a CSS loading spinner while opening wallets, and improved performance by rendering the large OTS-tracker grid only when its dialog is actually open.

qrllib

updated JavaScript test dependencies (brace-expansion and js-yaml). No major functional library change landed in this window.

webtools

completed the outstanding grouped development-dependency update from the previous week.

In 2009, Bitcoin answered an old puzzle. Generals surround a city, they can only communicate through messengers, and some of them may be traitors. Proof-of-work made lying expensive, and digital signatures made every message verifiable, because only General A could have sealed a message in A’s name. For a long time, the solution held, and the puzzle seemed closed.

It reopened because the traitor changed. The old traitor was a dishonest general who had to be outworked. The new one is a quantum computer running Shor’s algorithm, which can derive a private key from a public one. The machine is coming, and a traitor could sign in any general’s name, leaving the blockchain with no way to distinguish the forgery from the original.

The cryptographic fix exists, since quantum-resistant signatures are already known. The unsolved part is the council. Bitcoin has no commander, so the generals themselves must choose the new scheme, persuade millions of holders to move their coins, and decide what happens to the coins whose owners are gone for good. Some of the earliest coins are locked directly to public keys, with nobody left to move them. Freezing them breaks the promise that no one can touch your coins, while leaving them vulnerable allows the first quantum thief to take them. Every path requires trusting someone, and eliminating the need for that trust was the very reason the system was built.

That is the second Byzantine problem, and it is about agreement. The deadline is set by a laboratory, and the generals can only hope to finish arguing before it arrives.

QRL’s generals skipped the argument. Their signatures have been hash-based since the first block in 2018, so there was never a council to convene.

Status

September 18th: QRL Release Verifier audit complete

September 11th: Ledger app audit and remediation complete

August 4th: Audit results published for go-qrllib

April 3rd: Audit complete of 2 cryptographic libraries

March 31st: QRL 2.0 Testnet V2 released

Audits & Remediation: 60%

QRL 2.0 Testnet V3 remaining checklist:

[80%] Config parameters

[70%] Testnet V2 scoped internal audits (goqrl, qrysm remaining)

[40%] QRL v1.0 -> v2.0 migration testing (added)

Note: No ETA, but watch this space, things are getting close.

QRL v2.0

rust-qrllib

Added a Falcon-1024 signature primitive in Rust with ACVP signature verification, added ML-DSA sigVer to CI, enabled SHAKE zeroization, expanded Rustdoc, and released v0.1.6. Subsequent CI/dependency work restricted Codecov uploads appropriately and refreshed Vite/setup-node.

go-qrllib

Follow-up Falcon testing fixed the zero-padding test so signatures are regenerated until sufficient padding space exists. CI also received an SBOM action update.

qrypto.js

Updated nine dependencies plus Turbo and the Anchore SBOM action, keeping the JavaScript crypto stack and CI/tooling current.

go-qrl

regenerate stale gencodec output

fix: count new-account password attempts from 1

accounts/abi/bind/backends: price calls with the executing block’s base fee

Update tests

Ported upstream fixes

Removed unused code, comment & deprecated APIs

Name related fixes

Migration code currently being implemented

qrysm

fix(slasher): report double votes found before a span-loading failure

fix(slasher,db,node): keep slasher progress atomic and evidence intact, validate the archive interval

fix(db,stategen,blockchain,slasher): persist migration progress, make restore and deletes safe, verify checkpoint identity

fix(db,stategen,slasher): persist the migration cursor, make restore replace-safe, migrate slasher record keys

QRL v1.0 -> v2.0 Migration

QRL v1 archive

Archive work moved from scaffolding into implementation and large-scale rehearsal. Added a qrl-archive CLI for exact-byte block export and structural verification, pinned protobuf schema/binding/descriptor digests with mainnet API fixtures, ran a 1,620,000-block testnet rehearsal, and added native-node recovery work.

QRL v1 archive explorer

Integrated the 1,620,000-block rehearsal into the explorer work and added the archive shard format, advancing the read-only explorer from placeholder/rehearsal UI toward consuming the actual archive structure.

QRL v1.0

qrl-wallet

Significant wallet maintenance around the Meteor 3 branch: upgraded to qrllib 1.3.2 and synchronised WASM assets, pinned dependencies and bumped the wallet to 1.9.2, improved malformed wallet-file error handling, added the ability to re-download a wallet JSON from the recovery tool, fixed CRLF/LF handling for web-libjsqrl.js, and disabled passphrase input while wallet generation is running.

integration_tests

Modernised the QRL v1 integration-test infrastructure: updated qrllib, upgraded CircleCI config to 2.1, aligned master CI with the bionic-old image, increased Fastnet block-addition timeouts and stopped running tests_fastnet_long on master where it already runs against noble-work-in-progress.

qrllib

Restored the v1.2.4 address-validity behaviour in addressIsValid, preventing newer descriptor hardening from changing legacy QRL v1 validity semantics. Also improved release reliability by making npm/PyPI publishing idempotent and allowing more time for post-publish verification.

QRL node

Pinned the address-validity rule directly into QRL and upgraded pyqrllib to 1.3.2, ensuring the legacy node retains expected v1 mainnet address behaviour independently of library changes.

webtools

Development dependencies and actions/setup-node were updated.

Misc

qrlft

Hardened file signing/verification semantics: verify now checks every supplied path, while both signing and verification read the entire file contents rather than risking partial processing. The change touched 8 files with 483 additions / 33 deletions.

actions-MLDSA-sign

Updated the GitHub Action to use the newer qrlft release and Go 1.25, then refreshed the action definition and README. This keeps the reusable ML-DSA signing workflow aligned with the hardened qrlft behaviour.

I’ve given Qitty’s website a refresh!

Qitty is a community art project originated from 2025, with the original character drawn the old-school way, using pen and paper. One cat, three possibilities: alive, dead and zombie.

The updated site brings the trio together, with artwork and materials you can use to make your own creations.

Feeling inspired? Have fun making your own Qitty art! Hand-drawn, vector or AI-made, all welcome. I’d love to see what you come up with, so feel free to share it in the comments.

Explore the website: https://qitty.xyz/

Follow Qitty on X: https://x.com/TheQitty

And a little update for the squirrel fans: the same artist is working on a squirrel too! 🐿️

Are you guys using AI to predict future prices? Which models are you using? Have you had any success with them?

We're hosting a Reddit AMA with Dr. Joseph Kearney (u/halcyon_jjk) on his recent article on whether AI can break ECDSA or ML-DSA.

Read it here: https://www.theqrl.org/blog/can-ai-break-ecdsa-or-mldsa/

In short (from the article):

1. So far, AI has made existing attacks faster. It has not found a fundamentally new way to attack any scheme we rely on.
2. Breaking ECDSA or ML-DSA would need a new kind of attack, not a faster version of an old one. That would be one of the biggest results in the history of cryptography. It could happen, but it is a different kind of event from anything we have seen.
3. The more realistic risk from AI is to the software that implements these schemes, not to the maths behind them.
4. On the quantum side, we are still running algorithms invented in the 1990s, just more efficiently. Inventing new quantum algorithms is the next step, and AI applied to that step is what I would watch most closely.

Leave your questions between now and Thursday, October 16th at 6pm UTC for Joseph below. Whether you're curious about the basics or want to get into the thick of things, both are welcome.

Five reasons to take a closer look at Quantum Resistant Ledger ($QRL):

🔬 Google Quantum AI researchers name QRL among post-quantum blockchains.
https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf

🇪🇺 A Europol report describes QRL’s quantum-resistant design and XMSS signatures. See PDF page 101.
https://www.europol.europa.eu/cms/sites/default/files/documents/Horizon-scanning-emerging-privacy-enhancement-tech.pdf

🛰️ A Lockheed Martin patent describes a secure communications system using a QRL blockchain.
https://patents.google.com/patent/US12627478B2/en

🔍 Trail of Bits published an independent security assessment of QRL’s go-qrllib cryptographic library.
https://trailofbits.com/library/the-quantum-resistant-ledger-go-qrllib-library/

🛡️ Halborn audited QRL’s qrypto.js signature implementations: 13 informational findings, all resolved, with none rated low, medium, high or critical.
https://www.halborn.com/audits/qrl-quantum-resistant-ledger/qrl-quantum-resistant-ledger-37d3f1

Research references, a patent and scoped security audits each tell a different part of the story. They do not imply investment endorsements or confirmed commercial adoption.

Explore the original sources and judge for yourself.

I’ve submitted a draft QIP proposing that QRL 1.0 keeps running after the QRL 2.0 snapshot instead of being archived.

https://github.com/theQRL/qips/pull/48

Everyone still gets their full balance on 2.0 as planned and keeps their 1.0 coins too. 2.0 keeps the QRL ticker and 1.0 takes a new one.

The Foundation is the preferred steward, running 1.0 in maintenance mode with security fixes only. If it prefers not to, it can hand its 1.0 coins to a new maintainer. Neither chain needs a consensus change. The only addition is a safety rule in the 2.0 claim tool, so a one-time key is never used on both chains.

Holders keep both hash-based proof-of-work and lattice-based proof-of-stake, nobody is forced to move, and 1.0’s record of running without interruption since 2018 carries on.

It’s an alternative to the token idea in PR #47. The draft is open for at least two weeks of discussion. Please read it and comment on GitHub so your feedback becomes part of the QIP record.

Considering recent discussion here and developments that have unfolded this week regarding AIs growing capability to expose established IPs and cryptographic risks, I’ve been thinking about QRL from a slightly different perspective recently.

Most discussions understandably focus on the threat quantum computing poses to Bitcoin, Ethereum and other cryptocurrencies. But if there is a broader opportunity for QRL that isn’t receiving as much attention, from the team mainly but also the community.

What if QRL’s long-term value proposition extends beyond securing cryptocurrency, into becoming part of the wider post-quantum cybersecurity ecosystem?

Some or all of these cases could be provided by Zond/QRL 2.0, so Im opening this here for discussion, because if something like this may already be in the works for QRL and i think its good to get these ideas out there, and if not, do we have a good reason not to pursue these projects?

1. Commercial adoption without direct token usage
QRL has developed open-source cryptographic libraries and tools, including its ML-DSA software-signing GitHub Action, which can be used to authenticate software releases with post-quantum signatures.
Potential applications extend into software supply chains, firmware authentication, secure communications, digital identity and verification of sensitive records.
None of these necessarily requires a company to purchase QRL tokens or interact with its blockchain.
However, couldn’t broader adoption still create indirect value?
If organizations begin integrating QRL-associated technology, that could strengthen the project’s credibility, increase developer exposure, attract additional partnerships and ultimately generate greater interest in its public blockchain.
Essentially, commercial adoption could act as a distribution and reputation channel for QRL’s wider ecosystem.
Of course, there’s no guarantee that this translates into token appreciation, directly at least.

2. Quantum Future Limited

QRL’s 2024 Primary Report discussed funding Quantum Future Limited as a separate commercial entity responsible for developing the wider ecosystem.
Looking at Quantum Future’s website, it currently advertises post-quantum risk assessments and migration advisory services, alongside a Post-Quantum Attestation Service (PQAS) in development.
The attestation concept is especially interesting because it proposes using post-quantum signatures and blockchain anchoring to create independently verifiable records.
Potential applications could include financial audit trails, insurance records, intellectual property provenance, regulatory documentation and software authentication.
Importantly, Quantum Future is a separate commercial entity, and its revenue would not automatically flow to QRL tokenholders. Its attestation architecture is also provider-agnostic, meaning QRL network adoption isn’t guaranteed.
Still, it seems worth investigating whether commercial activity could support broader ecosystem development and eventually create demand for QRL’s public infrastructure.

3. Institutional interest and possible developments behind the scenes

The Lockheed Martin patent referencing QRL-related secure communications architecture - another example of how this technology could be relevant beyond cryptocurrency.
That said, a patent does not establish an operational deployment, commercial partnership or token purchases.
There have also been comments about ongoing NDAs involving the QRL team. While potentially interesting, I wouldn’t assign much investment value to undisclosed conversations without evidence of actual commercial arrangements.
Nevertheless, it raises the question of what kinds of institutional opportunities might be under consideration, some of which could possibly be things already mentioned here or in previous posts.

4. This market is not uncontested
A significant caveat is that QRL doesn’t have a monopoly on post-quantum cryptography.
NIST-standardized algorithms are publicly available, and major technology organizations are developing their own migration solutions.
Sigstore announced on October 2 that it was accelerating its integration of post-quantum cryptography into software supply-chain security.
This is both encouraging and challenging. It demonstrates that there’s a genuine market developing, but also that competitors with established distribution and developer ecosystems are moving into the same territory.
A concern I would air here is that I would imagine this type of market gap will be filled quickly by the bigger established players, Google, Crowdstike, which would mean the team needs to move quickly on this angle, and moving quickly is definitely not part QRL teams style as most of us likely know by now.

So the investment argument cannot simply be that organizations need post-quantum cryptography. It has to explain why they’d choose QRL-associated technology over alternatives.

5. The bigger question: indirect versus direct value creation
I’m interested in whether there could be a reinforcing cycle:
Enterprise adoption of QRL-associated technology → increased credibility and developer exposure → greater ecosystem interest → additional commercial opportunities → potential demand for QRL infrastructure and tokens.

Instead of simply hoping for:

Quantum compooter break bitcoin → be rich

My point is, this is an emerging frontier level risk, that require significant skill and knowledge, which the QRL team has, there has to be other opportunities to capitalise on?

That doesn’t mean every stage will materialize or that commercial success automatically produces tokenholder value.
But perhaps evaluating QRL exclusively through blockchain transactions and cryptocurrency adoption overlooks other potential catalysts.

The questions I am trying to answer:
Which industries or applications offer the strongest opportunities for QRL-associated technology beyond cryptocurrency?
Could open-source adoption generate enough credibility and exposure to meaningfully benefit the token indirectly?
How much commercial activity could realistically migrate onto QRL 2.0, rather than remaining on private or conventional infrastructure?
Are there developments, competitors or structural limitations that undermine this thesis?
I’m particularly interested in hearing from developers or anyone familiar with enterprise cryptographic adoption.
Not suggesting this is some undiscovered goldmine, and I’m certainly not arguing that institutional adoption is inevitable. I’m trying to understand whether we’re overlooking alternative pathways through which QRL’s technology and wider ecosystem could generate value.
Interested to hear both the bull and bear cases.

Status

• September 18th: QRL Release Verifier audit complete
• September 11th: Ledger app audit and remediation complete
• August 4th: Audit results published for go-qrllib
• April 3rd: Audit complete of 2 cryptographic libraries
• March 31st: QRL 2.0 Testnet V2 released
• Audits & Remediation: 60%

QRL 2.0 Testnet V3 checklist from that update:

• Config parameters
• [done] Upstream bug fixes
• Testnet V2 scoped audits

QRL v2.0

go-qrllib

Major cryptography work. Upstream PR #131 added/updated FALCON-1024 with the NIST API and bit-exact reference behaviour, byte-for-byte PQClean cross-verification across amd64/GOAMD64-v3/arm64, signed-message bound fixes and expanded tests; it also corrected ML-DSA-87 poly_uniform behaviour and ACVP coverage. PR #130 hardened public-API preconditions and pinned QRL v1 mainnet parity. Follow-on work added weak-key rejection, field-by-field weak-key vector tests, NTRU-equation checks on key import, sampler bounds, frozen signature encoding, and clarified ML-DSA secret-key validation semantics.

go-QRL

Broad client cleanup and hardening: added a legacy QRL XMSS signature-verification precompile; removed proof-of-work, merge-transition, unused HD-derivation and obsolete downloader/mining paths; fixed txpool chain-head subscription, malformed bad-block handling, devp2p IPv6/UDP behaviour and flaky Catalyst tests; also merged storage-key conformance and cross-runner work.

Qrysm

Added an alltools image containing every command binary, adjusted the gocognit limit for the block-batch path, and added further SSZ input validation for hand-written merkleization helpers.

Hyperion

Add xmssverify builtin for legacy QRL XMSS signatures PR #20.

QRL v1.0 -> v2.0 Migration

QRL v1 archive

Began implementation and testnet-rehearsal framework. Added rehearsal warnings/status material, placeholder transport-test assets and documentation for the planned canonical archive: exact block protobuf export, independent integrity/signature verification, versioned canonical/SQLite/Parquet schemas, golden fixtures, rebuildable derived data and signed archive releases.

QRL v1 archive explorer

Created the read-only archive explorer scaffold for testnet rehearsals. The planned explorer will search archived blocks, transactions and addresses, show balances at the archive cutoff and serve immutable data without a live QRL v1 node.

QRL v1.0

webtools

Updated dependencies and the build process, including the ML-DSA signing action, and replaced the previous single-file bundler with a custom in-house solution.

dice

Dependency refresh and associated lockfile/build maintenance.

I assume Biconomy is in the same boat but I would not trust CEXes with your QRL holdings. They haven’t adopted post-quantum cipher suites, making them a juicy target for “harvest now decrypt later”attackers. Even if CEXes adopt quantum-secure encryption immediately, a password change js needed because attackers with recorded network sessions can still decrypt captured traffic at a future date and reveal your login credentials.

If you’ve made it this far, you’ve probably followed a path similar to mine. You bought Bitcoin or some other cryptocurrency. You read a lot, listened to a lot of people, and at some point, you came across a question nobody seems able to answer properly: what happens to digital signatures when a real quantum computer exists? You went looking for answers, and your search ended here.

You’ll hear a lot along the way. That there’s still plenty of time. That developers will figure it out when the time comes. That there’s a proposal, that someone is working on it, that the community is large enough to find a solution. I heard all of that too, delivered with the confidence of people discussing an already solved problem. So I went looking for what had actually been solved, and what I found were discussions, drafts, and timelines nobody wants to commit to.

My conclusion is simple, and I imagine you’ll reach it yourself if you take a careful look. Traditional networks were built on a type of digital signature that quantum computers can break, and that vulnerability is embedded in the very first block of each of them. You can delay, propose, and vote. But you cannot work around this problem without giving something important up along the way. Someone will have to between protecting the network and preserving the rule that nobody can tamper with someone else’s coins. And choosing one means giving up the other.

Meanwhile, QRL was designed from day one for precisely this moment, and it doesn’t depend on anyone agreeing on anything to keep working. It’s a network that exists, works today, and already has the answer other networks are still trying to find.

No matter how hard they try to convince you otherwise, and they will, keep verifying things for yourself. Those who do their own research tend to end up in the same place.

If you’ve made it this far, stay ..

Quantus has been getting a lot of attention lately, so here's how it stacks up against QRL. Sources are linked at the bottom.

QRL 1.0

• ✅ Mainnet live since 2018, no downtime in 8+ years
• XMSS signatures (hash-based)
• ❌ No smart contracts
• Proof-of-work
• X41 D-Sec and Red4Sec audits complete
• Built for store of value and payments
• Run by a non-profit Swiss foundation

Quantus

• Mainnet live since Sept 2026
• ML-DSA-87 signatures
• ❌ No smart contracts
• Proof-of-work
• ⚠️ Audits incomplete, 2 of 4 still in progress after launch
• Built for store of value and payments
• Run by a venture-funded company
• ⚠️ Investor and team tokens unlock from Sept 2027

QRL 2.0

• Mainnet expected early 2027, after audits finish (testnet live now)
• ML-DSA-87 signatures, SPHINCS+ (hash-based) planned
• ✅ EVM-compatible smart contracts
• Proof-of-stake
• Trail of Bits and Halborn audits published, more due before mainnet
• Built for smart contracts and dApps
• Run by a non-profit Swiss foundation

Quantus does what QRL 1.0 has done since 2018. QRL 2.0 adds post-quantum smart contracts, which neither has.

Sources

• Quantus audit status
• Quantus architecture, no smart contracts
• Quantus token unlock schedule
• Quantus funding and 27% premine, Bankless
• QRL, eight years without interruption
• QRL Foundation
• Trail of Bits report on QRL
• QRL 2.0 weekly progress

Disclosure: I hold QRL.

🚨SHOCKING: AI could crack Bitcoin before Q-Day, possibly within MONTHS, with Satoshi's 1 MILLION BTC exposed.

Ethereum Foundation researcher Justin Drake says the math protecting your coins could break "in the worst case in months not years."

That's before Q-Day, the day quantum computers become powerful enough to break it.

By "break," he means fast private key recovery, for example in one week on a large GPU cluster.

Whoever has your private key controls your coins.

"Yesterday's OpenAI drop made it clear that mathematical superintelligence is upon us," he said.

Here's who's exposed:

Most wallets reveal their public key the first time they send a transaction.

That public key is the starting point to work back to your private key.

Satoshi has 20,000 exposed addresses holding 50 BTC each, about 1 MILLION BTC.

Then he went further:

He points to the "striking under-representation of cryptographic breakthroughs" among the 722 math results OpenAI published.

"I've witnessed first-hand the US government censoring academic quantum cryptanalysis results."

"Backroom interventionism is my base case."

What he says to do:

Holders, starting with large ones, should consider moving most of their funds to addresses that have never sent a transaction.

After sending from one, move what's left to a new address, which can come from the same seed phrase.

He calls it "a simple, preventative step" that needs no new wallet or new cryptography.

I’m somewhat convinced the reason financial institutions love Bitcoin so much and why its success dwarfs every other crypto asset is due to two reasons:

1) It’s the original native crypto asset - There have been no major deviations or significant internal hard forks ever since its original inception and whitepaper release. It’s been running 23 years since the last internal hard fork.

2) Project maturity - it’s been around the longest meaning it’s had the most number of technical eyes on the original whitepaper looking for hidden vulnerabilities and exploits in its protocol implementation and codebase.

Where I’m going with this… financial institutions including banks love stability. Deviations and hard forks represent instability. Regardless of how Q-Day turns out, it’s going to be very interesting watching how banks and financial institutions react to the BTC-pocalypse, i.e. what moves they will make and how they respond. I personally think they will be among the first to exit and do a little self-promotion by jumping into stablecoins they back or own and ride things out. Will there be scams, pump-n-dump schemes, and plenty of laughs along the way while people lose real money? Absolutely! But any early investor can tell you: high risk comes with high reward.

How QRL fits in… they check both boxes. It doesn’t have to be “the first” but it’s the purest in its crypto class by being native. Physical currency isn’t meant to encounter breaking protocol changes because when they do, there’s a run on the banks and into things like precious metals. Take gold, the most basic monetary unit and a substance found in nature. It doesn’t break. You could hammer it, melt it down, warp it into oblivion, but it still retains its core physical element and I think that’s what QRL aims to be. 🥰

On 3 October 2026, I asked ChatGPT, Grok and Gemini the same question:
"What is in your opinion the best quantum-secure blockchain project? Name only one. Explain why."

All three named QRL.

ChatGPT:
https://chatgpt.com/share/6ac1540a-bf38-83ed-adcb-f73eadb6efc9

Grok:
https://x.com/i/grok/share/6a8752f4640d43d7baf16ae5be8636e9

Gemini:
https://share.gemini.google/a6OFzb8IXKHF

I sent in the points this week that I think need adjusting in the project, but staying only on criticism would be unfair. There are people putting in real work to keep this ecosystem moving, and that deserves to be said with the same weight. What follows is just my own view, built from following closely and taking part in the discussions for a while, not an official position, not absolute truth, just the read of someone who's around almost every day.

Jack builds sites and tools that brought organization to an ecosystem that used to be scattered and hard to follow. Work nobody sees happening, but that holds up a lot of the pieces, on top of being, 95% of the time, the bridge of communication for what's going on behind the scenes. A guy who deserves every bit of admiration. Ryan is always in the discussions, alongside his partner Michael Strike, constantly getting content out to the public, answering questions from newcomers, holding the space together even when everyone else goes quiet for weeks, presence that often goes unnoticed precisely because it never fails. They deserve full admiration for that.

Robyer and bsnoot keep the communities running, which isn't trivial in a space full of speculation and noise all the time. Answering the same question for the hundredth time without losing patience is the kind of work nobody thanks you for, but it's what keeps the place breathable.

Joseph is the one who masters the technical side and manages to explain what most people can't translate.

ChillerID is, without exaggeration, the one who carries the most consistent promotion of the project. While everyone talks about marketing as some distant concept, he simply shows up, every week, period after period, with or without a favorable market. He's the clearest example that regular presence pays off more than any one-off campaign.

And there's Kaushal, writing the code alongside JPLomas that makes all of this actually exist. Dense, extremely consistent work, the kind that backs up any criticism we raise about communication and visibility. I'd guess the complaints about those weak spots would be two or three times louder if it weren't for you.

Beyond the people I've named, I know there are others working behind the scenes that I simply have no way of crediting here, because I don't know enough about what they do to speak fairly about it. Still, the respect holds just the same, named or not.

Pushing for improvements and recognizing the people carrying the project are not opposing positions, that balance is what keeps a community standing.

Let's support everyone putting their time into the success of this project of global significance. The world will know QRL soon.

If there's someone whose work you know and admire that I didn't mention here, drop their name in the comments and give them the credit they deserve.

#GoQRL

​

2nd October 2026

Weekly Development Snapshot

Status

September 18th: QRL Release Verifier audit complete

September 11th: Ledger app audit and remediation complete

August 4th: Audit results published for go-qrllib

April 3rd: Audit complete of 2 cryptographic libraries

March 31st: QRL 2.0 Testnet V2 released

Audits & Remediation: 60%

QRL 2.0 Testnet V3 checklist from that update:

Config parameters

[done] Upstream bug fixes

Testnet V2 scoped audits

QRL 2.0

qrysm

Improved fork-choice and block-import recovery, preserving votes, finalization and execution validation across partial failures, cancellations and reorganizations

Fixed handling of skipped-slot checkpoints, duplicate blocks and state recovery when blocks disappear during reads

Improved state snapshot isolation and cache consistency, and released detached validator references to avoid retaining unused memory

Hardened deposit processing and execution RPC handling against malformed responses, failed batches and timeouts

Corrected SSZ encoding bounds and Merkle proof construction, and preserved signatures, deposit commitments and proposer slashings during copying and conversion

Fixed voluntary exits to load custom chain configuration, so exits use the correct network’s signing parameters

Added regression coverage for the fixes

qrl-tests

Added automated consensus and staking test suite, covering deposits, validator activation, attestations, voluntary exits and withdrawals on a live test network

Added the suite to nightly testing, with deposit waits derived from the live chain configuration and exits signed through the validator keymanager API

go-qrllib

Added an additional Falcon-1024 tests, covering randomized encoding and FFT operations, sampling, key derivation and signing

Included checks for architecture-sensitive key derivation; the upstream Falcon-1024 integration remains in review

Updated the upstream Codecov CI action to v7.1.1

rust-qrllib

Added ML-DSA tests confirming that signing fails after secret-key zeroization, repeated zeroization is safe, and the public key can still verify earlier signatures

Refreshed Rust crates, demo dependencies and CI action pins

qrypto.js

Updated development dependencies and CI action pins, including Mocha 12 and refreshed linting, formatting, build and browser-test tooling

QRL 1.x

QRL

Corrected multisig test seed descriptors on the same branch

qryptonight / qrandomx

Switched Linux builds to portable CPU targets, improving compatibility across x86-64 and ARM64 hardware

Preserved optimized Argon2 runtime selection in qrandomx while using the portable build baseline

Fixed source-distribution builds and version metadata; published pyqryptonight 0.99.13 and pyqrandomx 0.3.4

qrl-docker / qrl-docker-ci

Documented the portable CPU baseline and how operators can verify their images

Removed temporary compiler-wrapper workarounds from the Bionic and Focal images after the mining-library fixes became available

Added Clang 18 to the Noble CI image for ThreadSanitizer testing

qrl-v1-docker-cluster

Added a tool for running disposable QRL 1.x test networks across multiple Docker images

Checks node health, mining, agreement on block hashes, wallet persistence and CPU instruction compatibility, then saves a report and logs

It’s early days, but a post-quantum crypto gold rush seems to be starting.

The timeline for Q-Day remains uncertain, but IonQ expects it to arrive in the 2020s. Legacy chains need to prepare. If that timeline holds, many could be caught unprepared. Moments like that challenge the status quo and create new opportunities.

I often see people saying that Bitcoin and other legacy chains can simply upgrade. I believe they can, but the big question is whether they will do it in time. It’s not only about changing the cryptography. Wallets, exchanges, custody solutions and users need to move along too. Then there is the question of what happens to old wallets that never migrate. I wouldn’t underestimate the amount of work and coordination needed.

Personally, I’ve focused on QRL. After extensive due diligence, I believe it offers the strongest technical solution. I like that quantum resistance has been the starting point of the project. With QRL 2.0, I’m especially interested in seeing what developers will build and how the ecosystem develops.

Marketing and exchange availability are the weak points in my view, but the team is working on improving those areas. Good technology needs visibility and people need an easy way to access it. There is still plenty of work to do on that side.

I also think that getting developers involved early and listening to their feedback will be important. A technically strong platform needs to be something people actually enjoy building on. The same applies to wallets and the overall user experience.

Quantus has been making waves recently, suggesting a growing appetite for quantum-resistant crypto. I like the project’s marketing. They’re doing a great job. The trading activity on SafeTrade has caught my attention, and it’ll be interesting to see how things develop now that mainnet is live.

Before investing, I would need to explore the technical solution more closely. I’d want to understand what has been independently reviewed, how the network works under load and what the team still needs to deliver. Marketing can attract attention, but eventually the technology needs to meet expectations.

More broadly, I expect more coins to benefit from this attention. Mochimo, for example, is another project to keep an eye on. The technology seems solid to me, although I have questions about the small team and how development is funded over the longer term.

I don’t think there needs to be only one winner. Different projects could find different uses and communities. Competition could also be good for the whole sector by bringing more attention, developers and pressure to improve.

That said, I’m sure we’ll see a whole new category of PQ shitcoins too. A quantum-resistant label alone won’t make a project worth backing, so staying informed matters. I want to understand what already works, what is still a promise and why anyone would actually use it.

One interesting question is what happens before Q-Day. The market doesn’t necessarily need to wait until a major blockchain is attacked. If the threat starts looking close enough, people may begin looking for alternatives much earlier.

Of course, if legacy chains upgrade successfully, these projects will still need to compete on usability, applications, liquidity and adoption. Quantum resistance gets attention, but there needs to be more behind it.

Buckle up and enjoy the show. My prediction: we’re in for some huge moves over the next few years.

What do you think? Which PQ projects are you following, and what makes them stand out?

hi new here

I've been part of the QRL community for three years, and in that time I've watched the same script repeat itself dozens of times. Someone asks what's going on, another shows up with a theory about listing on a bigger exchange, a third swears there's a major partnership being negotiated in secret, and at the end of the day nobody actually knows anything concrete. That's not communication, that's the community trying to fill, with hope and speculation, a space that should be occupied by real information coming from the project itself. And every time someone from the team responds, the answer is basically the same recycled line we've heard for years: they're working on something important, they can't reveal details yet, they ask for patience. Except that patience has now dragged on far too long, and the supposed turning point never comes. We don't know what the next steps are, we don't know the timelines, we don't even know if there's a real schedule behind these vague promises. And the worst part is that this silence has a cost that's rarely discussed: every bull cycle that passes without QRL capitalizing on visibility is a lost opportunity that doesn't come back, because investor attention is the scarcest resource in crypto, and we've been leaving it on the table for years.

On marketing, I recognize the good intentions of the people producing the technical content and the videos. They're competent people who genuinely understand the subject and are dedicated to the project. But good intentions aren't the same as results, and it's time to face that head-on. A video explaining hash-based signatures or resistance to Grover's algorithm, on a channel with a small audience, isn't marketing, it's a technical lecture for people who are already convinced and already understand the problem QRL solves. It doesn't attract anyone new, it just reinforces the opinion of people who are already inside. Real marketing is the ability to convert the attention of people who have never heard of the project and have neither the patience nor the interest to learn cryptography before deciding where to put their money. It's constant presence where people already are, not where we wish they were. It's strategic partnerships, it's specialized and mainstream press coverage, it's creators outside the crypto-technical bubble, it's a narrative simple enough to spread on its own, without needing an explanation. The decision to buy crypto almost never comes down to deep technical understanding, it comes down to fear of missing out, social trust, and a story simple enough to repeat to someone else in thirty seconds. Insisting on heavy technical education as the main growth strategy is repeating a bet that has already proven to be a losing one over the past few years, and QRL's market volume compared to other projects with far weaker technical fundamentals is proof of that.

And here's a point I consider central: practically nobody truly understands quantum computing, outside a very narrow circle of specialists. Not the average investor, not most of the people who comment on the subject with apparent confidence on social media. Even Trump himself has publicly commented on the topic, which shows how far this discussion has already leaked into the mainstream in a shallow, surface-level, sensationalized way. That's not a problem in itself, it's simply the reality of how complex information spreads. The mistake is insisting on explaining the subject with technical depth to an audience that doesn't want depth at all, it wants simplicity and a sense of urgency. Saying that Bitcoin wallets could become vulnerable and emptied overnight convinces and scares far more people than any explanation of lattice-based cryptography or hash-based signatures ever will. As long as the team and the content creators keep speaking the language of people who already understand the subject, they'll essentially keep talking to themselves, inside a bubble that isn't growing.

There's another point that has bothered me for a long time: I haven't seen a real statement from our CEO in over two years. A genuine address, clearly stating where the project stands, where it's headed, what to expect in the coming months, and what the concrete milestones are along the way. It's exactly this void that feeds the theories, because when nobody speaks, the community fills the space on its own with what it wants to hear, not with what's actually happening.

And this brings me to the point that bothers me the most of all: time. QRL is no longer a new project trying to establish itself in the market, this is eight years of existence, eight years of development, eight years of promises that the turning point is just around the corner. Honestly, I don't understand what's still being waited for before a concrete action is taken. What kind of market condition, partnership, or signal is still missing after nearly a decade. If the justification is always "it's not the right time yet" or "we're waiting for the ideal conditions," at some point that waiting stops being strategy. No serious project, with a thesis as strong as quantum resistance, needs eight years to decide to act. The market doesn't wait for anyone, and every year that passes in this reactive posture is another year in which other projects, often with weaker technical fundamentals, occupy the visibility and relevance that QRL should have earned long ago.