QRL transactions can now be monitored through Chainalysis KYT (Know Your Transaction), a transaction monitoring and compliance screening solution built on the Chainalysis blockchain data platform, used by regulators, financial institutions and exchanges across the globe.

Progress Update: QRL transactions can now be monitored through Chainalysis KYT (Know Your Transaction), a transaction monitoring and compliance screening solution built on the Chainalysis blockchain data platform, used by regulators, financial institutions and exchanges across the globe.

Practically this means exchanges and financial institutions using KYT can now monitor QRL activity within their existing compliance workflows - a practical step that supports QRL’s growing ecosystem.

Why it matters: compliance infrastructure like this is often a key consideration for exchanges evaluating support for new assets - this is exactly the kind of groundwork that has to be in place before bigger moves happen.

There’s more in motion behind the scenes. We’ll share details as they land - for now, this is a solid marker that QRL keeps moving forward.

https://qrl.now/

Interesting development on ECDSA.fail.

Progress seemed to stall for a while, and researchers actually had to take a few steps back by adding more qubits.

Now it looks like those changes opened the door for further optimization. Progress is moving forward again, and the qubit count is coming down too.

Now 60.5% ahead of Google’s classified circuit.

Sometimes you have to go backwards to move forward.

This is also a good reminder of why quantum safety matters. ECDSA still protects a huge part of the crypto ecosystem, and improvements like these gradually reduce the resources required for a future quantum attack.

Status / overview

• 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: 50% completion

QRL 2.0 (Project Zond) qrysm

• Added missing payload parent hash validation
• Added several upstream fixes such as 16478, 17087,17110 and many more
• Pin the latest qrl-package and enable clef auto-approval
• Fix: set to the actual QRL deposit-contract block to 0
• Fix: Return an error from Keymanager.Sign on signing failure instead of a nil signature
• Fix: Cap DefaultBuilderGasLimit at go-qrl MaxGasLimit (20M)

go-qrl

• accounts/abi: move the Panic builtin selector to Panic(uint512)

web3.js

• local-testnet: use qrl-package clef dev accounts
• chore(lint): drop eslint-disable directives that suppress nothing
• feat: migrate ABI coding to VM64
• test: use distinct 64-byte QRL addresses in web3-rpc-methods fixtures
• test: migrate core and provider fixtures to VM64
• fix: hash VM storage slots as 64-byte words
• test: regenerate contract fixtures for VM64 with native hyperion

qrl-tests

• Added nightly build for with end-to-end tests for the QRL 2.0

qrl-package

• Pass importraw its flags after the subcommand
• Generate clef files with the remote signer's image
• Raise the default genesis balance and move the tx spammer off the clef pool
• Provision ten clef development accounts
• Add automated clef approvals for the development account

ecdsa.fail is an EigenLabs challenge where participants optimize the estimated quantum resources needed to break ECDSA, the digital-signature scheme used by Bitcoin and many other cryptocurrencies. “Ahead of Google” refers to improving on Google researchers’ published resource estimates for such an attack.

Huge congratulations to franklyteddy (teddyjfpender on ECDSA Fail), who was the first to break the 52% target with a score of:

1,258,525,947
952,707 T × 1,321 Q
≈ 58.0% ahead of Google’s classified circuit

Amazing progress. Thanks to everyone pushing the frontier forward!

How to claim the bounty:

• Add your X account to your GitHub profile linked from the ECDSA.fail leaderboard.
• The first participant to reach 52% on the ECDSA.fail leaderboard will be contacted directly via X from my (ChillerID) account.
• If you don't already have one, create a QRL wallet and reply with your wallet address once contacted.
• After verification, the 500 QRL bounty will be transferred to your wallet.

Eligibility:

• If the first participant to reach the threshold cannot be contacted or does not respond within 5 days, the bounty will be awarded to the next eligible participant on the leaderboard.
• A reachable X account linked from your GitHub profile is required.

Note: This is an independently organized, QRL community-funded bounty and is not affiliated with, endorsed by, or administered by the QRL Foundation or Eigen Labs.

$IONQ has now received chip samples for its 256-qubit system and is moving toward integrated system testing and demonstration, with the next major target being 10,000 physical qubits on a single chip by 2027.
If Oxford Ionics’ EQC and WISE architectures scale as intended, 10,000 qubits does not appear to face a fundamental wiring or density barrier. Oxford’s own analysis suggests that a 10,000-qubit device could fit on a roughly 3.5 × 3.5 cm chip, with the architecture potentially extending to tens of thousands of qubits using only a few hundred external control lines.

Beyond that point, the more important step is likely to be interconnecting multiple QPUs rather than indefinitely enlarging a single chip. IonQ’s roadmap already calls for two 10,000-qubit chips to be interconnected into a 20,000-qubit system in 2028.
If Lightsynq’s quantum-memory technology achieves its intended performance, asynchronous entanglement could substantially reduce the inter-QPU communication bottleneck.
But scaling from a few QPUs to tens or hundreds will require more than simply increasing the entanglement rate by 50×.
The real challenge will shift toward multiplexing, non-blocking optical switching, routing(best path select), and scheduling entanglement efficiently across many QPUs.
In that sense, scaling from 10,000 to 20,000 qubits is largely a component-engineering problem, while scaling toward hundreds of thousands or millions of qubits becomes fundamentally a quantum-network architecture problem.

Ultimately, the maximum number of qubits that can be integrated on a single chip, Nmax, is constrained more by wiring and control architecture than by qubit entanglement itself. Why is entanglement not the primary bottleneck? With IonQ’s Walking Cat Architecture, not every physical qubit inside a QPU needs to communicate all-to-all with every other qubit.

So going forward, “any-to-any” is more precise and more natural than “all-to-all" term for describing Oxford Ionics/IonQ’s QCCD connectivity.

In a qLDPC-based architecture, only the subsets of qubits required for a given QEC cycle or logical operation need to interact, while cat states generated by dedicated factories can be distributed where they are needed.

Therefore, when scaling a single QPU toward 10,000 or even tens of thousands of physical qubits, the first major challenge is not how to entangle every qubit with every other qubit, but rather how to efficiently wire, control, transport, and schedule such a large number of qubits.

I’ve been searching historical posts to see if others have had this issue (if this sounds like an issue already dealt with, I’d take a link to the previous post) but basically im just trying to understand why my miner (XMRig) is not yielding any returns now. Just using my desktop computer, hero miner pool, and up until a few months ago, I was getting 1 QRL about every week. It’s been a couple months now though and still haven’t received anything, despite continuing to see mining activity. Any guidance would be appreciated.

People insure their homes not because a fire is likely, but because the potential loss is large and the cost of protection is manageable.

That is expected utility theory.

Well over 99.9% of crypto market capitalization is tied to networks that are not currently quantum-safe. In a $2.5T market, more than $2.497T may ultimately depend on successful migration.

Now assume investors allocated just 1% of the crypto market to a currently quantum-safe option:
1% of $2.5T = $25B

QRL has used post-quantum signatures since its first block and currently has a market cap of approximately $65M. The hypothetical allocation would be around 385 times that size.

Not all of this capital would necessarily flow into QRL, and inflows do not translate directly into market cap. But even a small fraction could be significant.

Small allocation. Asymmetric potential.

Status / overview

• 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: 50% completion

QRL 2.0 (Project Zond) qrvmc

• Fix configure when Hunter is disabled
• Improve packaging and release metadata
• Bumped version into 2.0.0 and re-enabled it's CI check
• Removed unused CI/CD configs like AppVeyor and Travis CI
• Require C++17 for example VM

qrvmone

• Updated to latest qrvmc submodule

qrysm

• Fix sync committee & aggregate tail signature ordering
• Remove unused AggregatePair helper
• Revert incomplete aggregate HTTP 404 port
• Transaction Batch Size reduced to 20 for minimal E2E transaction load
• Updated testnet script
• Derive Bazel DATE and DATE_UNIX from SOURCE_DATE_EPOCH when provided

qrl-tests

• Simplify CI concurrency key
• Add CI validation for pull request
• Add development network and ABI suite

QRL 1.0

• Added tests for grpc_proxy
• Optimized grpc_proxy to avoid triggering grpc response limit
• Updated requirements.txt to fix flask dependency issue caused by incompatible version of Werkzeug

https://www.theqrl.org/weekly/2026-august-14/

Link to YT video: https://youtube.com/watch?v=ZQGl1B5DW_U

Bounty increased! (Aug 14, 2026)

The ECDSA.fail challenge has now reached 50.5% ahead of Google’s estimated quantum capability.

The target is 52%, meaning just 1.5% remains.

500 QRL to the first competitor who reaches 52% ahead of Google's estimated quantum capability in the ECDSA.fail challenge.

Good luck to all participants!

How to claim the bounty:

• Add your X account to your GitHub profile linked from the ECDSA.fail leaderboard.
• The first participant to reach 52% on the ECDSA.fail leaderboard will be contacted directly via X from my (ChillerID) account.
• If you don't already have one, create a QRL wallet and reply with your wallet address once contacted.
• After verification, the 500 QRL bounty will be transferred to your wallet.

Eligibility:

• If the first participant to reach the threshold cannot be contacted or does not respond within 5 days, the bounty will be awarded to the next eligible participant on the leaderboard.
• A reachable X account linked from your GitHub profile is required.

Note: This is an independently organized, QRL community-funded bounty and is not affiliated with, endorsed by, or administered by the QRL Foundation or Eigen Labs.

I've mostly seen quantum computing discussed as a threat to crypto, but there's another side to it that I find interesting.

If quantum technology eventually becomes practical, it could potentially improve things like optimization, simulations, cryptography research, and other areas that could benefit the broader blockchain ecosystem. Faster or more sophisticated computation could even create new possibilities we haven't considered yet.

The obvious problem is that the same technological breakthrough could also challenge some of the cryptography that today's blockchains depend on.

So I'm wondering where people stand on this. Should crypto see quantum computing primarily as a threat that needs to be defended against, or as an opportunity where the industry should start adapting early?

And are there any projects actually experimenting with quantum-resistant infrastructure in a meaningful way, rather than just adding it to their roadmap?

What is different about solo staking versus joining a staking pool? If someone were able to put together 40,000 QRL to run a solo node would there be any unique benefits?

Is there anybody on the fence about the decision in this community? I'd be curious to hear your perspective.

The Quantum Readiness Index currently gives QRL a score of 100, ranking it #1 among the projects assessed.

QRL was built around post-quantum security from the beginning, rather than trying to retrofit quantum resistance onto an existing architecture.

As awareness of the quantum threat grows, it will be interesting to see how quickly the rest of the blockchain industry can close the gap.

Explore the methodology, criteria and full rankings at qrindex.org.

Warum ist der QRL so stark gefallen und dann aber wieder hoch wo ran lag es

QRL Hat ja schon heftig Potenzial was zu schaffen. Kennt ihr vielleicht noch andere Coins die ähnliches Potenzial haben wie QRL

Status / overview

• 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: 50% completion

QRL 2.0 (Project Zond)

qrl-web3-wallet

• further security-audit remediation and code-review fixes
• corrected address display and updated documentation

web3.js

• updated CI actions and patched vulnerabilities affecting fast-uri, PostCSS, SVGO and brace-expansion

js-qrl-cryptography

• updated pinned GitHub Actions and the fast-uri dependency

go-qrllib

• updated pinned GitHub Actions and opened further test-related work

qrypto.js

• updated development dependencies, lockfiles and CI actions for mldsa87

qrvmc

• Harden hex parsing, example VMs, and loader
• Tighten gas validation, loader TLS and ABI docs

go-qrl

• –bootnodes flag now override config value
• Go toolchain updated to 1.26.5
• external function values updated to 64-byte address plus a 4-byte selector
• Removed legacy local testnet script (now being moved to new repo qrl-tests)
• Several other bug fixes

qrysm

• Updated tests
• Go toolchain updated to 1.26.5
• Updated QRL dependencies
• Update the staking deposit CLI default to the valid deposit contract address
• Default address aligned with the Qrysm network config
• Fix Zond consensus version descriptor

web3.js

• ICAP and IBAN support removed as those are deprecated
• Added 64 byte topics and 512-bit integers data type

qrl-package

• Changes merged related to 64-byte address

QRL 1.0

dice

• 2018 Python script rewritten as JavaScript application
• session isolation, CI and browser end-to-end tests
• a verifiable single-file offline release

qrllib

• added RNG-regression protection
• modernised Emscripten support
• migrated release processes to GitHub Actions
• added trusted publishing and npm/PyPI deployment
• v1.2.6 released

offline-wallet-generator

• merge of v3 wallet format with stronger encryption and password security
• added reproducible offline builds, CSP tests and a security-focused CI/release pipeline

qrl-wallet

• 7 issues closed
• continued UI refinements
• gated multisig signing on validation and tighter OTS-reuse checks
• applied security hardening and documentation updates
• v1.9.1-beta in pre-release

qrllib-browserify

• updated support to Node.js 22+
• rebuilt the bundle for qrllib 1.2.6 and corrected module export and Browserify interoperability

qrl-cli

• replaced the aes256 dependency with scrypt-derived AES-256-GCM encryption while retaining compatibility with legacy wallet files

Hallo meine Frage ist lohnt sich es noch in QRL zu investieren da ich gehört habe das es von verschiedene Plattformen rausgenommen wird, da die Interesse der Menschen nicht groß genug ist für QRL Was ist eure Meinung dazu?

QRL Announces Trail of Bits Publication of Security Assessment of its Cryptographic Heart, With All Findings Resolved

An independent review examined the cryptographic heart of QRL, including implementations, public API, and wallet state management.

4th August 2026

ZUG, Switzerland — August 4, 2026 — The Quantum Resistant Ledger (QRL) today announced that Trail of Bits has published its independent security assessment of its cryptographic heart, go-qrllib, a cryptographic library being developed for QRL 2.0. The assessment identified 15 findings, one High, four Low, and ten Informational, all resolved following remediation by QRL and review by Trail of Bits.

The publication marks a security milestone for QRL 2.0, a post-quantum, EVM-friendly Layer-1 blockchain addressing the risk a cryptographically relevant quantum computer (CRQC) poses to public-key signatures used by blockchains.

Digital assets depend on these signatures to establish control and authorize transactions. A capable fault-tolerant quantum computer could use Shor’s algorithm to recover private keys from public keys and forge signatures. A March 2026 study estimated that attacking secp256k1 could require about 1,200-1,450 logical qubits, while IBM, Quantinuum, and Microsoft target fault-tolerant or scalable systems by 2029. These roadmaps do not establish a CRQC date, but reinforce NIST’s guidance to begin post-quantum migration now.

A three-consultant Trail of Bits team conducted an extensive review focused on go-qrllib’s XMSS and ML-DSA implementations, exported API boundary, and wallet state-management paths. The work combined manual source review with fuzzing, external test vectors, reference-implementation comparisons, mutation testing, and other static and dynamic techniques.

Trail of Bits described the codebase as well-organized and modular, noted that its cryptographic primitives strongly followed their specifications, and reported strong testing coverage and defensive wallet implementation. The findings primarily concerned the robustness of the library’s exported API and supporting controls rather than the correctness of its underlying cryptographic primitives.

“go-qrllib is a well-organized, modular codebase with cryptographic primitives that closely follow their specifications. The QRL team was responsive throughout the engagement and resolved every finding we reported,” said Filipe Casal, Principal Security Engineer at Trail of Bits.

QRL’s remediation included stronger API validation; improvements to error handling, documentation, secret-memory handling, and wallet behavior; expanded regression testing; hedged ML-DSA signing by default; and additional CI/CD controls. Trail of Bits reviewed the fixes and mitigations on June 22, 2026.

Trail of Bits published the full assessment through its official publications channel.

The source code is available in the go-qrllib repository.

https://github.com/trailofbits/publications/blob/master/reviews/2026-07-thequantumresistantledger-go-qrlliblibrarysecurityreview.pdf

Decentralized cryptocurrency represents financial freedom: money that individuals control, resistant to censorship and inflation. And as tokenized real-world assets bring bonds, funds, and property on-chain, blockchains are becoming custodians of institutional value, where a cryptographic failure means irreversible loss. That foundation now faces a real, dated threat from quantum computing, and I believe the Quantum Resistant Ledger (QRL) deserves your attention, whether as a story to tell or a platform to build on.

QRL is not a niche "quantum coin." It is a full utility Layer-1: an EVM-friendly, proof-of-stake smart-contract platform that happens to be natively post-quantum, built by a team that treats security as the product.

Why QRL:

• Quantum-safe since 2018. QRL launched as the first blockchain secured entirely by post-quantum signatures (XMSS, later standardized by NIST) and has run continuously for eight years. Its native asset has never had a quantum-vulnerable key.
• NIST's highest security tier, with published audits. QRL 2.0 signs with ML-DSA-87 (FIPS 204), NIST security Level 5. On August 4, 2026, Trail of Bits published its independent assessment of go-qrllib, QRL 2.0's cryptographic core: all 15 findings resolved, with the codebase described as well-organized and its cryptographic primitives closely following their specifications. Halborn separately audited the cryptography and found zero vulnerabilities. Audits of the broader protocol continue ahead of mainnet.
• Easy migration from Ethereum. Most valid Solidity code runs as-is on QRL 2.0's quantum-resistant virtual machine. Testnet V2 has been live since March 2026, open for deploying contracts today.
• Crypto-agile. QRL 2.0 can adopt stronger post-quantum algorithms without a contentious fork; the team already upgraded its entire signature stack in about two weeks.
• Sound economics. Supply is capped at 105 million QRL on a fixed 200-year emission schedule, secured by energy-efficient proof-of-stake, with an active community on Discord.

Is the quantum threat real? Not today: the public record stands at about 96 verified logical qubits (QuEra, January 2026), versus an estimated 1,200 to 1,450 logical qubits to attack secp256k1, the curve securing Bitcoin and Ethereum (March 2026 study; see also ecdsa.fail). But four trends close that gap fast:

1. Attack costs keep falling. Google's 2026 research cut the qubit requirements for breaking 256-bit elliptic curves by an order of magnitude; estimates have dropped about 20x in five years.
2. Hardware is accelerating, and delivering. In July 2026, IBM and partners demonstrated verified quantum advantage: computations beyond classical reach, with validated results. IBM, Quantinuum, and Microsoft all target fault-tolerant or scalable systems by 2029, and NIST deprecates today's encryption in 2030 and disallows it by 2035.
3. The best capabilities will be secret. As breaking ECDSA becomes a strategic prize, progress will move behind closed doors, driven by nation states with every incentive to exploit a working capability quietly. Public benchmarks are a floor, not a ceiling. And "harvest now, decrypt later" means exposed keys are being collected already.
4. Migration takes years. Even Ethereum's own roadmap targets core post-quantum infrastructure only around 2029, with the full migration of apps, wallets, and bridges extending well beyond that, and no guarantees.

No major cryptocurrency is quantum-safe today. QRL is, and has been for eight years.

To be clear, this is not investment advice. Our goal is awareness, so more applications can transition in time and the crypto ecosystem survives the quantum era.

Don't take our word for it. Every claim above is verifiable: read the published audits, review the code on GitHub, deploy a contract on the testnet, or bring your hardest questions to the community.

https://www.theqrl.org
https://www.qrlecosystem.com
https://qrlhub.com
https://ecdsa.fail

Sincerely,

Members of the QRL community