Login

u/Successful_Ad8583

r/QuantumEconomy r/QRL
▲ 7 r/QRL

QRL Weekly, 2026-October-02

​

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

reddit.com
u/Successful_Ad8583 — 13 days ago
▲ 12 r/QRL

QRL Weekly, 2026-September-18

Weekly Development Snapshot

Status

September 18th: QRL Release Verifier audit complete

September 11th: Ledger app audit along with its remediation is 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 work:

Config parameters

Upstream bug fixes

Testnet V2 scoped audits complete

QRL 2.0

qrysm

EpochsPerSlashingsVector is now 512 - 45 days, 12 hours, 16 minutes

fix(builder): raise execution payload response limit to 32 MiB

fix(config): reject malformed YAML without partially applying overrides as well as validate values for some config parameters

fix(sync): prevent zero polling intervals for one-slot epochs

Reject empty signature groups and nil public keys, which was being accepted earlier

Remove unbounded ML-DSA public key cache, fixing memory leak

Prevent panics on malformed ML-DSA signature batches

Reject all-zero-t1 ML-DSA-87 public keys

Reject nil inputs and validate fork domain lengths

Optimization: avoid redundant sync signature checks in replay and block proposals

Wire the keymanager RPC to a beacon client so voluntary exits can sign

Optimization: reject invalid gossip before costly attester signature checks

Verify gossip signatures independently with bounded workers

Bound signature diagnostics and avoid duplicate verification

An empty execution payloads doesn’t necessarily mean empty withdrawal

More tests added

qrl-genesis-generator

Execution voting period updated to 4

web3.js

Removed deprecated RPC APIs

Replace Ethereum EC precompile gas with gqrl depositroot and mldsa87Verify costs

Set Common initialBaseFee to 100 gwei so genesis fee math matches go-qrl

Type FeeHistory.baseFeePerGas as an array because go-qrl returns one value per block

qrypto.js

Added weak public-key and invalid secret-key validation for ML-DSA-87, plus bounded signing behaviour and corresponding documentation/tests

js-qrl-cryptography

Updated @theqrl/mldsa87 to v2.2.0 to pick up the new validation behaviour

web3.js

Updated QRL cryptography/wallet dependencies and raised dependency patch floors for multiple known CVEs and security advisories

go-qrllib

Added ML-DSA-87 weak-key rejection and secret-key checks; moved verification toward validated PublicKey objects; expanded lifecycle tests/docs; updated Go security-check CI

go-qrl

Updated to go-qrllib 0.9.2 then 0.10.0 and enforced validated ML-DSA-87 public keys in the verification precompile

rust-qrllib

Added a validated ML-DSA PublicKey type and weak-key rule

actions-mldsa-sign

v2 release: GitHub Action to generate ML-DSA-87 (FIPS 204) post-quantum signatures for files, and a signed manifest binding each artifact to the release it belongs to.

reddit.com
u/Successful_Ad8583 — 27 days ago
▲ 13 r/QRL

IonQ’s CEO Shares How Long It Will Take Quantum Computers To Hack Bitcoin’s Encryption. And Argues It Will Happen Sooner Than Expected

Quick Read

  • IonQ (IONQ) CEO targets 2028 as Q-Day, when a 2,000-qubit machine could break Bitcoin's elliptic-curve encryption in under 26 days.
  • De Masi acknowledged that IonQ sells the quantum security shield while sounding the alarm, but Strategy still added $370 million in Bitcoin anyway.
  • Just released. Our analysts combed the entire stock market and named the ten best stocks to buy right now, and IonQ didn't make the cut. Enter your email to see the names that beat IONQ.

Speaking on CNBC Wednesday morning, IonQ  Chairman and CEO Niccolo de Masi put a countdown clock on the cryptography underpinning the world's largest digital asset. He said IonQ has published a paper laying out how a 2,000-qubit machine could run an elliptic-curve encryption attack in under 26 days, and he reiterated 2028 as his expectation for "Q-Day," the point at which quantum machines threaten today's public-key standards. He was careful to add the capability "is not here yet."

Why the Timeline Just Got Shorter

De Masi has been telegraphing this compression for months. On IonQ's Q2 2026 call, he told investors: "As I foretold a year ago, the timeline for cryptographically relevant machines that threaten RSA encryption is rapidly compressing. Over the past 15 years, the estimated number of qubits needed to break encryption has dropped by four orders of magnitude." He added: "A year ago, people thought that Q-Day was something happening in the 2030s. They now understand it's something happening in the 2020s."

CFO Inder Singh warned that "financial services is definitely waking up to the cold, hard reality that at some point, RSA 2048 and other encryption protocols, such as ECC 256, may all be broken." ECC 256 secures Bitcoin wallet signatures.

Roadmap Behind the Warning

De Masi said the company is "accelerating our path to 10,000 qubits in 2027," after having received first fully featured, fully integrated QPUs back from SkyWater and planning to begin commissioning 256-qubit systems in 2027. Q2 revenue landed at $80.1 million, up 287% year over year, with full-year 2026 guidance of $280M to $290M and remaining performance obligations of $485 million.

Self-Interest, in His Own Words

De Masi flagged the obvious tension himself, telling CNBC IonQ is "a huge participant, investor, and solution provider in the quantum security space." The company just launched a QKD product, ClavisXG Multiplex, aimed at protecting existing fiber networks, and de Masi called quantum key distribution something "that requires a violation of laws of physics to hack and crack." He is publishing the threat and selling the shield.

https://finance.yahoo.com/markets/stocks/articles/quantum-stocks-fall-rate-hike-165835922.html

u/Successful_Ad8583 — 1 month ago
▲ 9 r/QRL

IonQ Launches Superion Product Line: Industry-Leading, Upgradeable Platform Designed to Scale Manufacturable Fault Tolerant Quantum Computing

KEY HIGHLIGHTS 

  • Sixth-generation quantum compute product family debuts with IonQ Superion 256
  • First chips fabricated at SkyWater, demonstrating accelerated manufacturing 
  • First ions trapped in prototype system 
  • IonQ accepting orders now with customer deliveries in 2027

NEW YORK, Sep. 8, 2026 IonQ (NYSE: IONQ), the world's leading full-stack quantum platform and foundry, today announced IonQ Superion 256, its sixth-generation quantum computing platform. This system is the first in the Superion platform that all future compute products are expected to be built on. The company also plans on revealing the industrial design of IonQ Superion 256, at its 2026 Investor Day later today at the New York Stock Exchange.

Superion 256 has rapidly progressed from early design to trapping ions in under a year. IonQ has fabricated its first fully integrated 256-qubit quantum processing units (QPUs) at its subsidiary SkyWater. IonQ has trapped the first ions in prototype Superion 256 systems now being built in parallel at multiple IonQ facilities across the U.S. The chip, designed and fabricated jointly by IonQ and SkyWater, went through six tapeouts in the first half of 2026. Working closely with SkyWater’s quantum foundry, IonQ’s design cycle compressed from nine months to two, and the teams delivered 12x more wafer lots over a six-month period than at a previous foundry. 

“Superion is the result of two strategic acquisitions coming together to deliver this historic milestone. Oxford Ionics enabled IonQ to control natural, trapped-ion qubits using standard electronics, and SkyWater unlocked the ability to manufacture at semiconductor costs and scale,” said Niccolo de Masi, Chairman and CEO of IonQ. “Quantum computing, like classical computing before it, ultimately scales most powerfully on a semiconductor foundation. Superion 256 is the first quantum computer platform designed to be built by the hundreds rather than one at a time. Every generation that follows will be designed, fabricated, and packaged similarly – creating unique upgradeability in our Superion platform.”

Powering the system is IonQ's Electronic Qubit Control (EQC), which controls trapped-ion qubits with electronics integrated on the chip rather than with laser systems. The underlying qubit control is manufactured with standard semiconductor processes. At the heart of the chip is the same Electronic Qubit Control technology IonQ used to set its 99.99% two-qubit gate fidelity world record in October 2025. The system is built for data centers and occupies a standard server rack footprint without bespoke buildout. Superion draws less power than a rack of GPUs and has a cooling system that integrates into typical data center settings.  

The Superion platform scales from 256 qubits to millions of qubits. Every generation that follows Superion 256 expands use of the same ions, the same qubits, the same electronic control, and the same chip fabric. IonQ Superion 10K is well underway and integrates CMOS onto the chip, a scaling technique SkyWater already manufactures at volume.

IonQ is developing both its 256 and 10K generations concurrently. The company’s first cryo-CMOS test chips for the 10K can be seen today at the New York Stock Exchange. The 10K is the first hardware generation built to run IonQ's Walking Cat architecture. Walking Cat was the blueprint published in April 2026 for how applications compile into instructions, how errors are corrected, and how ions move across the chip. IonQ expects the shift from laser-based to semiconductor-based control to reduce cost-per-qubit by more than 300x across the roadmap.

“Superion marks the most important inflection point the quantum computing industry has yet seen. It accelerates our industry from one-off lab machines to quantum computers manufactured at scale with compelling unit economics and modest energy consumption,” said Chris Ballance, President of Quantum Computing at IonQ. “The step from 256 to 10K qubits is being delivered by integrating CMOS onto the chip – something the semiconductor industry has done many times and SkyWater does every day. CMOS integration is expected to reach full fault tolerance reality in a 2027 lab setting at IonQ, and manufacturable, commercial reality in 2028.”

Superion 256 is available to order now, with customer deliveries in 2027. In the first quarter of 2026, IonQ pre-sold its first Superion 256 system. Production-grade systems will also run and be offered on IonQ's cloud. 

IonQ has deployed five generations of quantum computers to customers since 2019, most recently IonQ Tempo. In April 2026, the company published the Walking Cat architecture, and in August 2026 it reported breakeven quantum error correction using qLDPC codes on a Tempo engineering test system, validating key elements of that architecture on hardware.

Investor Day 

IonQ will host a live webcast at 12:30 p.m. Eastern time today. It will be available live via webcast on the company’s website here, or directly here. A recording will be available shortly after the call and will remain available for one year. 

About IonQ

IonQ, Inc. [NYSE: IONQ] is the world's leading quantum platform and foundry - delivering integrated quantum solutions across computing, networking, sensing, and security. IonQ's newest generation of quantum computers, the IonQ Tempo, is the latest in a line of cutting-edge systems. Earlier systems have helped customers and partners including Amazon Web Services, AstraZeneca, and NVIDIA achieve a 20x performance increase over previous quantum solutions and accelerate innovation in drug discovery, materials science, financial modeling, logistics, cybersecurity, and defense. In 2025, the company achieved 99.99% two-qubit gate fidelity, setting a world record in quantum computing performance.

Headquartered in College Park, Maryland, IonQ has operations across North America, Latin America, EMEA, and APAC. Our quantum computing services have been available through all major cloud providers since 2021, while we also meet the needs of networking and sensing customers across land, sea, air, and space. IonQ is making quantum platforms more accessible and impactful than ever before. Learn more at IonQ.com.

Note to Investors Regarding Forward-Looking Statements

This press release contains forward-looking statements regarding IonQ’s capabilities, roadmap, and future system developments, including statements regarding the Superion platform's ability to scale to fault tolerant quantum computing, the use of the Superion platform for future compute products and the timing for customer deliveries of Superion 256. In some cases, you can identify these statements by forward-looking words such as “anticipate,” “expect,” “suggest,” “plan,” “believe,” “intend,” “estimate,” “target,” “project,” “should,” “could,” “would,” “may,” “will,” “forecast,” “confident,” “position,” “become,” “on track,” “designed,” “ongoing” and other similar expressions. These statements are only predictions based on our expectations and projections about future events as of the date of this press release and are subject to a number of risks, uncertainties and assumptions that may prove incorrect, any of which could cause actual results to differ materially from those expressed or implied by such statements, including, among others, those described under the heading “Risk Factors” in our Annual Report on Form 10-K for 2025 and our Quarterly Report on Form 10-Q for the quarter ended June 30, 2026 filed with the Securities and Exchange Commission. New risks emerge from time to time, and it is not possible for our management to predict all risks, nor can management assess the impact of all factors on our business or the extent to which any factor, or combination of factors, may cause actual results to differ materially from those contained in any forward-looking statement we make. Investors are cautioned not to place undue reliance on any such forward-looking statements, which speak only as of the date they are made. Except as otherwise required by law, we undertake no obligation to update any forward-looking statement, whether as a result of new information, future events or otherwise. 

u/Successful_Ad8583 — 1 month ago
▲ 14 r/QRL

IonQ solves real-time QEC decoding at scale using an off-the-shelf Apple M4 Max CPU (No supercomputers needed) Post:

https://preview.redd.it/27b8s9uulqmh1.png?width=1024&format=png&auto=webp&s=c53f9234dab70f771d90d65a768fd8249d003f2b

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/

reddit.com
u/Successful_Ad8583 — 1 month ago
▲ 12 r/QRL

QRL Weekly, 2026-August-28

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

reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 15 r/QRL

QRL Now Live in Chainalysis KYT

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://preview.redd.it/amnmnej8udlh1.png?width=800&format=png&auto=webp&s=e847c4e9ca865bfc4fa7da8efa888512c9d8335e

reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 8 r/QRL

QRL Weekly, 2026-August-21

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
reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 11 r/QRL

IONQ has now received chip samples for its 256-qubit system

$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.

reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 16 r/QRL

QRL Weekly, 2026-August-07

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
reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 25 r/QRL

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

https://preview.redd.it/j6a5wa8xvdhh1.png?width=800&format=png&auto=webp&s=f6d7c657b1f57b4be788d48b9f0cdf5f60395272

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

reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 14 r/QRL

New Paper from Caltech/Harvard team introduces "mitten codes": High-rate qLDPC processors with real-time decoding and massive error suppression

https://preview.redd.it/szrlg7knq5hh1.png?width=1281&format=png&auto=webp&s=7af74bda968bcd5a9432ff21197e70df3c6afd10

A really impressive pre-print just dropped by Aditya Bhardwaj, John Preskill, and a joint team from Caltech, Harvard, and AWS. They are addressing one of the biggest bottlenecks in fault-tolerant quantum computing (FTQC): making qLDPC codes practically usable on real hardware.

Here is a quick TL;DR on why this paper is generating a lot of buzz:

🚀 What are Mitten Codes?

qLDPC (Quantum Low-Density Parity-Check) codes are famous for being far more qubit-efficient than standard Surface Codes, but they usually come with huge hardware routing overheads and complex decoding pipelines.

"Mitten codes" are a new family of qLDPC processor codes based on non-abelian groups that solve a lot of these physical implementation problems.

💡 Key Highlights:

  • Insane Encoding Rate (~20%): Instead of needing thousands of physical qubits per single logical qubit (like standard Surface Codes), mitten codes yield 1 logical qubit for every 5 physical qubits.
  • Massive Parallelism: Supports high-rate lattice surgery (executing many logical measurements in parallel) and parallel magic-state injection across all logical qubits simultaneously.
  • Real-Time Decoding (Sub-millisecond latency): A huge problem with qLDPC has been decoding speed. Their decoder achieves average sub-millisecond latency per cycle—fast enough to run in real-time on hardware like neutral atoms.
  • Extremely Low Error Rates:
    • Under circuit-level noise at a 0.1% physical error rate (PER), the [[300, 60, 14]] code hits a block logical error rate of $\sim 10^{-11}$ per round.
    • In a stress test of 15 billion surgery experiments on the [[540, 108, 18]] code, they observed only 2 logical failures. That’s baseline proof for running $\sim 10^{10}$ logical operations cleanly.

🛠 How did they find them?

They built an end-to-end design pipeline powered by sQetch, a new distance estimator that is orders of magnitude faster than existing code-search tools.

Importantly, the authors highlight that mitten codes map cleanly onto near-term neutral atom arrays (with shuttling/reconfigurable connectivity) and superconducting architectures.

Definitely feels like a solid step toward bridging the gap between theoretical FTQC overheads and realistic hardware implementation!

What are your thoughts on non-abelian qLDPC implementations vs. 2D color/surface codes for the next 3–5 years?

https://arxiv.org/pdf/2607.28795

reddit.com
u/Successful_Ad8583 — 2 months ago
▲ 21 r/QRL

QuantaPool Is Preparing for QRL 2.0 Mainnet: DigitalGuards Seeks a US Operating Partner

QuantaPool is heading for QRL 2.0 mainnet under a dedicated US operating entity. DigitalGuards is in advanced discussions with a prospective US partner and remains open to further qualified candidates. Here is the role.

>

DigitalGuards has spent the past two years building the product stack for QRL 2.0: wallets for web, mobile, desktop, and browser, the ZondScan explorer, a post-quantum dApp connect SDK, the QuantaSwap atomic-swap protocol, and QuantaPool, our liquid staking protocol. Today we are announcing the next step for QuantaPool, and putting our search for its operating partner on the public record.

What QuantaPool is

Running a validator on QRL 2.0 requires 40,000 QRL and the operational skill to keep a node healthy. QuantaPool lowers that barrier: users deposit any amount of QRL, the pool funds validators, and depositors receive stQRL, a token whose QRL value grows with validator rewards. The protocol is live on the QRL 2.0 testnet at quantapool.com, fully open source under GPL-3.0, with a 200-test contract suite. Everything runs with valueless test assets today.

Why a US operating structure

Operating a staking protocol with real value is a serious undertaking: real deposits, validator uptime, user trust, and clear accountability. After reviewing the options, we consider a dedicated US operating entity under genuine, active US management the right home for QuantaPool’s mainnet operations. DigitalGuards remains the owner and builder: the copyright, the brand, and all development stay in-house, and the operating entity runs the service under license from us.

The partner we are looking for

We are in advanced discussions with a prospective US partner, and we remain open to hearing from further qualified candidates. The role, in brief:

  • Genuine, active management of the operating entity from the United States: the decisions, the operations, and the accountability
  • Validator infrastructure operations with continuous monitoring and incident response
  • Custody of operational keys and participation in the protocol’s multisig
  • Ownership of the entity’s compliance obligations, together with US counsel
  • Solid business standing: entity formation, banking, clean records

This is a working operator role, suited to someone with infrastructure experience and compliance seriousness, ideally from the staking or hosting world. Capital participation is open for discussion, and commercial terms are discussed directly with qualified candidates.

Why we are publishing this

Partly for candidates, and partly for the record. QuantaPool’s development has been public from the first commit, and the search for its operating home belongs to that same public history. When the partnership is signed, this post will get its sequel.

Get in touch

Write to info@digitalguards.nl with the subject “QuantaPool operating partner”. Tell us who you are, where you operate, and what you have run.

Any partnership is subject to definitive agreements prepared with counsel, and nothing in this post is binding.

Please, feel free to visit>

https://quantapool.com/
https://quantaswap.io/
https://qrlwallet.com/

https://digitalguards.nl/projects

u/Successful_Ad8583 — 2 months ago
▲ 10 r/QRL

QRL Weekly, 2026-July-24 Status / overview

QRL Weekly, 2026-July-24 Status / overview

  • April 3rd: Audit complete of 2 cryptographic libraries.
  • March 31st: QRL 2.0 Testnet V2 Released.
  • Audits: 50% completion
  • Network Performance Optimization: 60% completion

web3.js

  • Audit remediation; keystore cryptography hardening; removal of import cycles; coverage gates; reproducible supply-chain checks; dependency overrides; CI timeout and build-order fixes
  • 20 constituent packages released

rust-qrllib

  • Refactored the demo build, aligned documentation with go-qrllib, and updated demo dependencies and TypeScript configuration

https://www.theqrl.org/weekly/2026-july-24/

https://preview.redd.it/v32l3bwd07fh1.png?width=744&format=png&auto=webp&s=802daa214e6cd0f659dccb4ed27b22819ab1fd06

reddit.com
u/Successful_Ad8583 — 3 months ago