IonQ just dropped a pretty significant paper on arXiv (arXiv:2608.25027) by Min Ye, Andrii Maksymov, and Nicolas Delfosse. They demonstrated an end-to-end real-time Quantum Error Correction (QEC) decoding pipeline running entirely on a standard commodity chip—a single Apple M4 Max CPU (using 12 cores).

Here is a quick breakdown of why this matters and what they actually achieved:

The Problem: The Classical Decoding Backlog

Quantum hardware is naturally noisy. To run reliable, fault-tolerant circuits, you need QEC to constantly measure syndrome data, identify errors, and correct them.

The issue? Large-scale quantum workloads generate a massive firehose of error data. If your classical hardware can't process (decode) those errors faster than the quantum hardware generates them, you get a decoding backlog. The quantum computer literally has to pause and wait for the classical processor, causing operational delays ("stretch") that degrade the entire computation.

Until now, most scaling solutions relied on expensive, specialized hardware like custom FPGAs, GPUs, or ASICs just to handle small error-correction windows.

What IonQ Accomplished

• Hardware: Ran the entire pipeline on a single off-the-shelf Apple M4 Max CPU (12 cores).
• Workload Scale: Handled "MegaQuOp" scale workloads—up to 408 logical qubits, 1M+ T gates, and 1.3 million logical measurements across 11,680 physical qubits.
• Near-Zero Delay (<0.3% Stretch): Assuming standard trapped-ion syndrome extraction cycle times (1–5 ms), the classical decoder kept pace effortlessly.

How They Optimized It (Engineering Highlights)

1. Dual-Decoder Setup: Used two concurrent sliding-window decoders. An Error Decoder (5-cycle window) continuously tracks background Pauli errors, while a low-latency Outcome Decoder (2-cycle window) triggers only during measurement steps.
2. On-the-Fly Priors: Instead of constantly rebuilding parity-check matrices, they used a static Tanner graph and updated probability priors dynamically on the fly.
3. Memory Optimization: Stored log-likelihood ratios (LLRs) per error node rather than raw edge messages.

Classical processing bandwidth won't be the bottleneck for fault-tolerant trapped-ion systems. As IonQ scales its Walking Cat Architecture (WCA) toward 10,000+ physical qubits, they won't need massive supercomputer clusters or custom hardware just to handle error decoding—a heavily optimized commodity CPU gets the job done in real-time.

https://quantumcomputingreport.com/ionq-demonstrates-real-time-qec-decoding-at-megaquop-scale-on-a-single-apple-m4-max-cpu/

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

Generate deposit-cli seed mnemonic from crypto/rand

Added several upstream fixes such as 13329, 14413, 17052 and many more

Prevent uint64 overflow in correlation slashing penalty under QRL balance constants

Fix: Return after the first per-item error in SubmitContributionAndProofs

Fix: Restore pre-genesis guard in initDepositCaches (nil GenesisState panic)

web3.js

Align typed-data encoding with go-qrl

Use distinct QRL addresses in remaining fixtures

qrl-tests

Use Docker APIs for E2E runtime metadata

https://www.youtube.com/watch?v=ETxiYblAp_U
https://www.youtube.com/watch?v=jaYw33DVkEU

Ryan Malinowski & Michael Strike from the QRL Core Team are hosting an upcoming QRL Show Live AMA with Kaushal to answer questions around QRL development + progress on the road towards Mainnet. If you want to build on QRL, want to ask a question around what developers can do today in Testnet, have specific testing/setup/terminal questions, or maybe something else entirely that's related to QRL development, we’re here to help answer those questions (only submit questions that relate to this). Submit your questions below ⬇️

https://docs.google.com/forms/d/e/1FAIpQLSelOw0pdESvkNbg3rtB9gbJWtbxDu78ufdoaztGI6lBYhNVrQ/viewform?pli=1

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

UPDATED Aug 27, 2026

The original winner of the ECDSA.fail bounty did not respond within 5 days, so the 500 QRL prize was awarded to the next eligible participant on the leaderboard.

Congratulations, moscowchill!

Original post

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.

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?