DEV Community: takundanashebmuchena-pixel

Hybrid Classical-Quantum Cryptography — What It Is and How quantum-audit Handles It

takundanashebmuchena-pixel — Tue, 21 Jul 2026 05:40:49 +0000

Hybrid Classical-Quantum Cryptography — What It Is and How quantum-audit Handles It

Part 4 of the quantum-audit series. Part 1 | Part 2 | Part 3

After Part 1 dropped, a reader asked:

"How does quantum-audit handle hybrid classical-quantum systems? I'm curious if it can audit both types simultaneously."

This is the right question. And it's more nuanced than it looks.

What is a hybrid classical-quantum system?

A hybrid system uses both classical cryptography and post-quantum cryptography simultaneously — typically during a migration period.

The most common pattern looks like this:

// Classical signing (vulnerable to Shor's algorithm)
const classicalSig = secp256k1.sign(message, privateKey);

// Post-quantum signing (quantum-resistant)
const pqcSig = dilithium.sign(message, pqcPrivateKey);

// Send both — verifier checks both
const payload = { classicalSig, pqcSig, message };

The idea: a verifier that understands both can validate the PQC signature. A legacy verifier that only understands ECDSA can still validate the classical one. You get backwards compatibility while adding quantum resistance.

This is called hybrid key encapsulation or hybrid signing and it's the approach recommended by NIST during the transition period.

Why hybrid instead of just switching?

Because the ecosystem doesn't switch overnight.

Consider Ethereum: wallets, nodes, smart contracts, hardware signers, exchanges — all rely on ECDSA/secp256k1. You can't flip a switch. Even if a new post-quantum standard is chosen tomorrow, the migration would take years.

Hybrid is the bridge. You add PQC without breaking existing systems.

The same pattern applies to:

TLS — hybrid key exchange (X25519 + Kyber)
JWT — HS256 (symmetric) alongside RS256 (classical asymmetric)
SSH — hybrid key algorithms in OpenSSH 9.0+

The problem with hybrid systems

Hybrid systems introduce a subtle security question: which signature do you actually trust?

If an attacker can selectively strip the PQC signature and present only the classical one to a legacy verifier — you've gained nothing. The system is only as strong as its weakest link.

This is called a downgrade attack. Good hybrid implementations defend against it explicitly.

// Vulnerable — verifier accepts classical-only
function verify(payload) {
  if (payload.classicalSig) {
    return secp256k1.verify(payload.message, payload.classicalSig);
  }
}

// Secure — verifier requires both
function verify(payload) {
  const classicalValid = secp256k1.verify(payload.message, payload.classicalSig);
  const pqcValid = dilithium.verify(payload.message, payload.pqcSig);
  return classicalValid && pqcValid; // BOTH required
}

How quantum-audit v0.2.3 handles hybrid systems

quantum-audit now detects hybrid setups automatically.

When it finds both a vulnerable classical library and a post-quantum library in your project:

⚡ Hybrid Mode: Post-quantum library detected (@noble/post-quantum,
   sphincs) — hybrid transition in progress.
   Critical penalties reduced by 50%.

🔒 Multi-layer PQC detected (@noble/post-quantum + sphincs)
   — +10 bonus applied.

What this means in practice:

A project with ethers (ECDSA — critical) and @noble/post-quantum (Dilithium — safe) would normally score:

100 - 40 (ethers ECDSA weight) = 60/100 — Grade C

In hybrid mode:

100 - 20 (50% reduction) + 0 = 80/100 — Grade B

The tool recognises you're actively migrating, not ignoring the problem.

What quantum-audit does NOT yet do

Full transparency — there are things v0.2.3 doesn't cover yet:

1. Downgrade attack detection
We don't yet check whether your hybrid implementation requires both signatures or accepts classical-only as a fallback. That's source-level analysis that requires understanding your verification logic, not just your dependencies.

2. Protocol-level hybrid awareness
If you're using OpenSSL 3.x's provider system or a custom TLS stack with hybrid key exchange — quantum-audit won't understand the protocol context. It sees the libraries, not how they're composed.

3. Smart contract hybrid patterns
Solidity scanning is new in v0.2.3 — we detect ECDSA imports in .sol files but don't yet understand hybrid signing patterns at the contract level.

These are on the roadmap.

The right way to think about hybrid migration

Step 1 — Audit first

npx quantum-audit . --json > audit.json

Know exactly what you're dealing with before planning migration.

Step 2 — Add PQC alongside classical
Don't replace — add. Keep existing ECDSA signing, add Dilithium on top.

npm install @noble/post-quantum

Step 3 — Require both in verification
Make sure your verifier requires both signatures. No classical-only fallback.

Step 4 — Monitor the ecosystem
Ethereum's PQC migration is tracked via EIPs. Bitcoin via BIP-360. Watch these for when the ecosystem is ready to drop classical.

Step 5 — Eventually deprecate classical
When the ecosystem catches up, drop the classical layer. You're now fully post-quantum.

Real-world hybrid: OpenSSL 3.x

OpenSSL 3.x introduced the provider system that allows hybrid key exchange in TLS. The OQS (Open Quantum Safe) provider adds post-quantum algorithms:

npm install liboqs-node

This is the most mature hybrid implementation available today for Node.js projects.

Install quantum-audit

npx quantum-audit .
npx quantum-audit . --json
npx quantum-audit . --threshold=70

GitHub: takundanashebmuchena-pixel/quantum-audit
npm: npmjs.com/package/quantum-audit

Are you running a hybrid system already? Drop your setup in the comments — especially interested in hearing from anyone using OpenSSL's OQS provider or building hybrid signing into a Web3 project.

quantum-audit v0.2.3 — Hybrid Detection, Migration Guides, and 50+ Libraries

takundanashebmuchena-pixel — Sun, 19 Jul 2026 21:50:06 +0000

quantum-audit v0.2.3 — Hybrid Detection, Migration Guides, and 50+ Libraries

Part of the quantum-audit series. Part 1 | Part 2 | Part 3

🌐 quantum-audit-site.vercel.app

v0.2.3 of quantum-audit is live. Here's everything that changed.

npx quantum-audit .

1. Migration suggestions per finding

The biggest request after the series launched. Previously, quantum-audit told you what was broken. Now it tells you what to do about it.

Every critical finding now includes a migration path:

[CRITICAL] ECDSA (secp256k1) — package.json
  ↳ Migration: Replace with @noble/post-quantum (Dilithium) for signatures

[CRITICAL] BLS12-381 (pairing-based) — package.json
  ↳ Migration: Pairing-based crypto broken by quantum. Monitor for PQC replacements.

[MEDIUM] SHA-256 (crypto.createHash) — src/utils/hash.js:14
  ↳ Migration: Consider SHA-3 for stronger quantum resistance

2. Hybrid detection

A question from the community after Part 1:

"How does quantum-audit handle hybrid classical-quantum systems?"

v0.2.3 now detects hybrid setups. If your project has both a quantum-vulnerable library and a post-quantum one, quantum-audit recognises you're mid-transition and reduces critical penalties by 50%:

⚡ Hybrid Mode: Post-quantum library detected (@noble/post-quantum)
   — hybrid transition in progress. Critical penalties reduced by 50%.

This means a project actively migrating gets scored fairly — not penalised as heavily as one that hasn't started.

3. Multi-layer PQC bonus

Inspired by DAC Chain's approach to quantum security — using multiple post-quantum algorithms stacked together rather than relying on a single one.

If your project uses two or more post-quantum libraries:

🔒 Multi-layer PQC detected (@noble/post-quantum + sphincs)
   — +10 bonus applied.

This rewards the most security-conscious projects and encourages defence in depth.

4. 50+ libraries in the detection database

v0.2.2 covered 20 libraries. v0.2.3 covers 50+. New additions include:

BLS signatures (Ethereum 2.0 consensus):

@chainsafe/bls
@noble/bls12-381
noble-bls12-381
mcl-wasm

BLS12-381 is pairing-based cryptography — broken by quantum computers. This is used in Ethereum's Proof of Stake consensus mechanism.

JWT libraries:

jsonwebtoken — flags RS256/ES256 signing
jose
passport-jwt

New ECDSA packages:

tiny-secp256k1
@noble/secp256k1
@noble/curves
eth-sig-util

Classically broken (flagged as critical):

md5 — broken without quantum, dangerous with it
rainbow-sig — multivariate signature scheme broken in 2022

New safe/PQC libraries:

ntru — lattice-based encryption
falcon-sign — NIST alternate standard
sphincsplus — hash-based NIST standard
liboqs-node — Open Quantum Safe bindings

5. New CLI flags

--threshold — fail CI if score drops below a custom value:

npx quantum-audit . --threshold=70
# exits 1 if score < 70

--ignore — skip specific packages:

npx quantum-audit . --ignore=ethers,web3

--html — generate a full HTML report:

npx quantum-audit . --html
# writes quantum-audit-report.html

--csv — export findings to a spreadsheet:

npx quantum-audit . --csv
# writes quantum-audit-report.csv

6. Solidity file scanning

.sol files are now included in the source scan. Solidity contracts that import or use ECDSA libraries directly will be flagged.

Install / upgrade

npm install -g quantum-audit
# or
npx quantum-audit .

If you already have it installed:

npm update -g quantum-audit

What's next

Part 4 — Hybrid classical-quantum systems in depth
VS Code extension — surface findings inline while you code
GitHub Action — publish quantum-audit as a marketplace action

Drop your v0.2.3 score in the comments. Has anything changed from your v.0.2.2 scan?

How to Gate Your CI Pipeline on Quantum Vulnerability — with quantum-audit

takundanashebmuchena-pixel — Fri, 17 Jul 2026 03:20:20 +0000

Part 3 of the quantum-audit series. Part 1 | Part 2*

🌐 Tool: quantum-audit-site.vercel.app

Most security tools tell you there's a problem. Then you close the tab and forget about it.

The only way to actually fix that is to make the problem block your deployment.

quantum-audit exits with a non-zero code when it finds critical quantum-vulnerable cryptography. That means you can drop it into any CI pipeline and have it fail the build automatically.

Here's how.

The exit code behaviour

npx quantum-audit .
echo $?   # 0 = no critical findings, 1 = critical findings found

Exit 0 — no critical findings (safe to deploy)
Exit 1 — critical findings detected (block the build)

Medium findings (SHA-256, AES-128) don't fail the build — they appear in the output as warnings but don't block deployment. Only CRITICAL findings (RSA, ECDSA, secp256k1) cause a non-zero exit.

GitHub Actions

Add this to your .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  quantum-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Run quantum-audit
        run: npx quantum-audit .

If your project uses ethers, web3, elliptic, or any other ECDSA/RSA library — the step will fail and your PR cannot be merged until the finding is addressed.

JSON output for custom reporting

Need to parse the results programmatically? Use the --json flag:

npx quantum-audit . --json

Output:

{
  "project": "my-dapp",
  "score": 60,
  "grade": "C — Moderate Exposure",
  "findings": [
    {
      "algorithm": "ECDSA (secp256k1) signing",
      "risk": "critical",
      "weight": 40,
      "file": "package.json",
      "line": null,
      "source": "ethers"
    },
    {
      "algorithm": "SHA-256 (crypto.createHash)",
      "risk": "medium",
      "weight": 8,
      "file": "src/utils/hash.js",
      "line": 14
    }
  ]
}

You can pipe this into a Slack notification, a dashboard, or a custom reporting step.

Slack notification on failure

Here's a GitHub Actions step that posts to Slack when critical findings are detected:

- name: Run quantum-audit
  id: audit
  run: npx quantum-audit . --json > audit-result.json || true

- name: Check for critical findings
  run: |
    SCORE=$(cat audit-result.json | python3 -c "import sys,json; print(json.load(sys.stdin)['score'])")
    echo "Quantum readiness score: $SCORE"
    if [ "$SCORE" -lt 70 ]; then
      echo "CRITICAL: Quantum exposure score below threshold"
      exit 1
    fi

Soft mode — warn without blocking

If you're not ready to hard-fail on critical findings yet, use this pattern:

- name: Run quantum-audit (warn only)
  run: npx quantum-audit . || echo "⚠️ Quantum vulnerabilities detected — review before next release"
  continue-on-error: true

This surfaces the findings in your CI logs without blocking the build. Good for teams that need a transition period before enforcing the gate.

What to do when the build fails

If quantum-audit fails your build, you have three options:

Option 1 — Accept the risk temporarily
Use continue-on-error: true in your CI step to warn without blocking while you plan a migration.

Option 2 — Migrate to a post-quantum library
NIST standardized the replacements in 2024:

CRYSTALS-Dilithium — drop-in for ECDSA signatures
CRYSTALS-Kyber — for key encapsulation
SPHINCS+ — hash-based signatures (most conservative choice)

Option 3 — Scope the scan
If the vulnerable dependency is isolated to a specific non-critical part of your codebase, you can scope the scan:

npx quantum-audit ./src/critical-path

Only scan the directories that matter most.

Full workflow example

Here's a complete GitHub Actions workflow with quantum-audit integrated alongside your existing checks:

name: Security checks

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install

      - name: npm audit (classical vulnerabilities)
        run: npm audit --audit-level=high

      - name: quantum-audit (quantum vulnerabilities)
        run: npx quantum-audit .

      - name: quantum-audit JSON report
        if: always()
        run: npx quantum-audit . --json > quantum-report.json

      - name: Upload quantum report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: quantum-audit-report
          path: quantum-report.json

This runs both npm audit (for classical CVEs) and quantum-audit (for quantum exposure) side by side, and uploads the full JSON report as a build artifact for review.

Install

npm install -g quantum-audit
# or
npx quantum-audit .

GitHub: takundanashebmuchena-pixel/quantum-audit
npm: npmjs.com/package/quantum-audit

Are you running quantum-audit in CI? Drop your setup in the comments — I'd love to see how others are integrating it.

How I Built an AST Scanner to Detect Quantum-Vulnerable Cryptography in JavaScript Projects

takundanashebmuchena-pixel — Mon, 13 Jul 2026 02:45:03 +0000

`Part 2 of the quantum-audit series. Part 1 here

🌐 Tool: quantum-audit-site.vercel.app

When I published quantum-audit — a CLI that scans npm projects for quantum-vulnerable cryptography — I got a question immediately:

"How does it actually detect crypto calls in source code?"

The answer is AST scanning. In this post I'll break down exactly how it works, with real code from the scanner.

What is an AST?

AST stands for Abstract Syntax Tree. It's a tree representation of your source code that a parser produces after reading it.

Think of it like this. When you write:

js crypto.createSign('RSA-SHA256')

To you, that's a function call. To a parser, it's a tree:

plaintext CallExpression ├── callee: MemberExpression │ ├── object: Identifier (name: "crypto") │ └── property: Identifier (name: "createSign") └── arguments: └── StringLiteral (value: "RSA-SHA256")

Instead of using regex — which would miss edge cases and produce false positives — we walk this tree and look for specific patterns. That's the core idea.

Why not just use regex?

You could try:

js const hasRSA = code.includes('createSign') && code.includes('RSA');

But this breaks immediately on:

js // createSign is used for RSA-SHA256 const comment = "createSign";

Regex doesn't understand code structure. An AST does.

The tools: @babel/parser and @babel/traverse

quantum-audit uses two packages:

@babel/parser — reads JavaScript/TypeScript and produces an AST
@babel/traverse — walks the AST and lets you hook into specific node types

bash npm install @babel/parser @babel/traverse

Reading the file and parsing it

The first step is reading the source file and converting it into an AST:

`js
const fs = require('fs');
const parser = require('@babel/parser');

function scanSourceFile(filePath) {
const findings = [];
let code;

try {
code = fs.readFileSync(filePath, 'utf8');
} catch {
return findings; // skip unreadable files
}

let ast;
try {
ast = parser.parse(code, {
sourceType: 'unambiguous', // handles both CommonJS and ES modules
plugins: ['jsx', 'typescript'], // supports React and TypeScript
});
} catch {
return findings; // skip files that fail to parse
}
`

sourceType: 'unambiguous' tells the parser to figure out automatically whether the file uses import/export or require(). The plugins array enables JSX and TypeScript support so the scanner works on React and TS projects.

Walking the tree with traverse

Once we have the AST, we use traverse to walk every node and check for dangerous patterns:

`js
const traverse = require('@babel/traverse').default;

traverse(ast, {
CallExpression(path) {
const callee = path.node.callee;
const line = path.node.loc ? path.node.loc.start.line : null;

// Check for: crypto.createSign('RSA-SHA256')
if (
  callee.type === 'MemberExpression' &&
  callee.property.name === 'createSign'
) {
  const arg = path.node.arguments[0];
  if (arg && arg.type === 'StringLiteral') {
    if (/RSA/i.test(arg.value)) {
      findings.push({
        algorithm: 'RSA (crypto.createSign)',
        risk: 'critical',
        weight: 35,
        file: filePath,
        line,
      });
    }
  }
}

}
});
`

CallExpression is the node type for any function call. Every time traverse finds one, our callback fires. We then inspect the node to see:

Is the callee a MemberExpression (i.e. something.method())?
Is the method name createSign?
Is the first argument a string containing RSA?

If all three are true — we've found RSA signing code. Flag it.

Detecting all the vulnerable patterns

Here's the full set of patterns quantum-audit looks for:

RSA and DSA via createSign

js crypto.createSign('RSA-SHA256') // CRITICAL crypto.createSign('DSA-SHA1') // CRITICAL

Detection:

js if (callee.property.name === 'createSign') { const arg = path.node.arguments[0]; if (arg && arg.type === 'StringLiteral') { if (/RSA/i.test(arg.value)) { findings.push({ algorithm: 'RSA (crypto.createSign)', risk: 'critical', weight: 35, file: filePath, line }); } else if (/DSA/i.test(arg.value)) { findings.push({ algorithm: 'DSA (crypto.createSign)', risk: 'critical', weight: 35, file: filePath, line }); } } }

ECDSA and RSA via generateKeyPair

js crypto.generateKeyPairSync('ec', { namedCurve: 'secp256k1' }) // CRITICAL crypto.generateKeyPairSync('rsa', { modulusLength: 2048 }) // CRITICAL

Detection:

js if (/generateKeyPair/.test(callee.property.name || '')) { const arg = path.node.arguments[0]; if (arg && arg.type === 'StringLiteral') { if (arg.value === 'rsa') { findings.push({ algorithm: 'RSA (generateKeyPair)', risk: 'critical', weight: 35, file: filePath, line }); } else if (arg.value === 'ec') { findings.push({ algorithm: 'ECDSA (generateKeyPair)', risk: 'critical', weight: 40, file: filePath, line }); } } }

SHA-256 via createHash (medium risk)

js crypto.createHash('sha256') // MEDIUM — weakened by Grover's algorithm

Detection:

js if (callee.property.name === 'createHash') { const arg = path.node.arguments[0]; if (arg && arg.type === 'StringLiteral' && /^sha256$/i.test(arg.value)) { findings.push({ algorithm: 'SHA-256 (crypto.createHash)', risk: 'medium', weight: 8, file: filePath, line }); } }

SHA-256 isn't broken by Shor's algorithm — but Grover's algorithm halves its effective security from 256 bits to ~128 bits. It's a medium risk, not critical.

Walking the entire project

The scanner doesn't just check one file. It walks your entire project directory recursively, skipping node_modules, dist, and other non-source folders:

`js
const SOURCE_EXTENSIONS = new Set(['.js', '.jsx', '.ts', '.tsx', '.mjs', '.cjs']);
const SKIP_DIRS = new Set(['node_modules', '.git', 'dist', 'build', 'coverage']);

Every .js, .ts, .jsx, .tsx, .mjs, and .cjs file gets scanned.

Two layers working together

The AST scanner is Layer 2. Layer 1 is a dependency scan — checking your package.json against a database of known vulnerable libraries:

js // known-libs.js — excerpt module.exports = { 'elliptic': { algorithm: 'ECDSA (secp256k1/p256)', risk: 'critical', weight: 40 }, 'ethers': { algorithm: 'ECDSA (secp256k1) signing', risk: 'critical', weight: 40 }, 'node-rsa': { algorithm: 'RSA', risk: 'critical', weight: 35 }, };

The dependency scan catches high-level exposure. The AST scan catches the specific lines in your source where vulnerable crypto is called directly.

Together they produce a score:

plaintext Score = 100 - (sum of weights of all findings)

With deduplication so the same finding doesn't penalise you twice.

Try it on your project

bash npx quantum-audit . npx quantum-audit . --json # machine-readable for CI

GitHub: takundanashebmuchena-pixel/quantum-audit
npm: npmjs.com/package/quantum-audit

What patterns are you seeing in your own codebase? Drop your score in the comments.`

Web3-to-viem

takundanashebmuchena-pixel — Sat, 11 Jul 2026 04:08:12 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Demo

Code

How I Built It

Prize Categories

I scanned 200 blockchain npm packages for quantum-vulnerable cryptography. Here's what I found.

takundanashebmuchena-pixel — Fri, 10 Jul 2026 04:22:49 +0000

🌐 Live: https://quantum-audit-site.vercel.app

---I scanned 200 blockchain npm packages for quantum-vulnerable cryptography. Here's what I found.
TL;DR: Most Ethereum/Web3 npm packages rely on ECDSA/secp256k1 — an algorithm that a sufficiently large quantum computer will break. I built a CLI tool to scan your project and score its quantum readiness.
The problem nobody in Web3 is talking about
Shor's algorithm — running on a large enough quantum computer — breaks RSA and elliptic curve cryptography (ECDSA, ECDH, secp256k1) completely.
Not "weakens." Breaks. As in: private keys become derivable from public keys.
Every Ethereum wallet, every Bitcoin address, every smart contract signature scheme in production today uses ECDSA on secp256k1. That's the curve. That's the algorithm. That's the exposure.
NIST already saw this coming. In 2024 they standardized the post-quantum replacements:
CRYSTALS-Kyber — key encapsulation
CRYSTALS-Dilithium — signatures
SPHINCS+ — hash-based signatures
But almost no npm packages have migrated. And almost no developer tools tell you which of your dependencies are at risk.
What I built
quantum-audit — a CLI tool that scans your project's dependency tree and source code for quantum-vulnerable cryptography, then gives you a 0–100 readiness score.
Bash
Output:
Code
How it works
Two scanning layers:
Layer 1 — Dependency scan
Checks your package.json against a curated database of 20+ crypto libraries mapped to their underlying algorithms. ethers, web3, elliptic, secp256k1, node-rsa, jsrsasign — all flagged with their actual risk level and weight.
Layer 2 — AST source scan
Uses Babel to walk your JavaScript/TypeScript source files and detect direct node:crypto calls that dependency scanning alone would miss:
Js
Scoring
Grade
Score
Meaning
A
90–100
Quantum ready
B
70–89
Low exposure
C
40–69
Moderate exposure
D
15–39
High exposure
F
0–14
Critical exposure
CI integration: exits non-zero on critical findings so you can gate your pipeline.
What I found scanning blockchain packages
Out of the top blockchain/Web3 npm packages:
ethers — CRITICAL (ECDSA/secp256k1 signing)
web3 — CRITICAL (ECDSA/secp256k1 signing)
bitcoinjs-lib — CRITICAL (ECDSA/secp256k1)
elliptic — CRITICAL (the underlying curve library everything else uses)
ethereumjs-util — CRITICAL (secp256k1 key operations)
Not a single one of the top 10 Ethereum npm packages has a post-quantum migration path documented.
"Quantum computers aren't a threat yet"
True — today. IBM's current largest quantum processor has ~1000 qubits. Breaking 256-bit elliptic curve keys requires an estimated 2,000–4,000 logical (error-corrected) qubits, which translates to millions of physical qubits with current error rates.
But:
"Harvest now, decrypt later" attacks are already happening — adversaries are collecting encrypted traffic today to decrypt when quantum computers are ready
Migration takes years — the SSL/TLS ecosystem took over a decade to move from SHA-1 to SHA-256
NIST already standardized the replacements — there's no reason to wait
The time to audit is now, not when the threat is imminent.
Install and use
Bash
GitHub: https://github.com/takundanashebmuchena-pixel/quantum-audit
npm: https://www.npmjs.com/package/quantum-audit
What's next
Solidity contract scanning (flag on-chain ECDSA-only signature schemes)
Per-finding migration guidance (suggest the Dilithium equivalent)
Integration with Chain Audit — a broader blockchain dependency risk intelligence platform
If you're building anything on Web3, run npx quantum-audit . on your project right now and drop your score in the comments. Curious what the distribution looks like across the community.
Tags: #javascript #security #blockchain #ethereum #webdev

eth-rpc-errors is abandoned (850K+ weekly downloads) — here's the drop-in replacement

takundanashebmuchena-pixel — Thu, 18 Jun 2026 04:11:06 +0000

The Problem

If you're using eth-rpc-errors in your project,
you might not have noticed something concerning —
the package hasn't been maintained in over 5 years.

Yet it still gets 850,000+ weekly downloads.

That means hundreds of thousands of Ethereum projects
are depending on an abandoned package. No bug fixes.
No security patches. No responses to issues.

Even MetaMask — the original creators — have moved
away from it to @metamask/rpc-errors.

The Solution

I forked it and have been actively maintaining it as:

👉 eth-rpc-errors-maintained

Migration: One Line

This is genuinely the easiest migration you'll ever do.

Uninstall the old package:


bash
npm uninstall eth-rpc-errors
npm install eth-rpc-errors-maintained

Fix: node-sass is end-of-life — migrate to Dart Sass in one command

takundanashebmuchena-pixel — Tue, 09 Jun 2026 03:57:55 +0000

node-sass has been officially deprecated since 2022 and is now end-of-life. It breaks on every new Node.js version upgrade with the error:

"Node Sass does not yet support your current environment"

Yet it still gets 3 million+ downloads per week from legacy projects.

The fix

I published an automated migration CLI:

npm install -g node-sass-migrate

Or just run it directly:

npx node-sass-migrate .

What it does automatically

Replaces node-sass with sass (Dart Sass) in package.json
Fixes /deep/ → ::v-deep in SCSS files (Vue projects)
Updates webpack.config.js, vite.config.js, and gulpfile.js references
Warns about @import deprecations and division operator issues

Why not just swap manually?

Dart Sass is stricter than node-sass. These things break silently:

/deep/ selector throws parse errors
Division operator ($var / 2) is deprecated — need math.div()
@import is deprecated — will be removed in Dart Sass 2.0
sass-loader needs to be version 13+

The CLI handles the safe fixes automatically and warns you about the rest.

After running the CLI

Just run npm install and your project should build. If you hit errors, the full migration guide is at https://nodesassmigrate.netlify.app

npm: https://www.npmjs.com/package/node-sass-migrate
GitHub: https://github.com/takundanashebmuchena-pixel/node-sass-migrate

Fix: babel-plugin-transform-flow-strip-types broken in Babel 7 and 8

takundanashebmuchena-pixel — Sun, 07 Jun 2026 15:24:45 +0000

The original babel-plugin-transform-flow-strip-types hasn't been updated in 9 years and breaks silently in Babel 7 and 8 environments.

The fix

I published a maintained fork that works as a drop-in replacement:

npm install --save-dev babel-plugin-transform-flow-strip-types-maintained

Then update your .babelrc:

{
"plugins": ["transform-flow-strip-types-maintained"]
}

That's it. No other changes needed.

What's fixed

Babel 7 and 8 peer dependency conflicts
Missing syntax plugin declaration
Deprecated visitor patterns
allowDeclareFields support

Automated migration

If you want to update your entire project automatically:

npx flow-strip-migrate .

This updates your package.json and babel config in one command.

More info: https://flowstrip.netlify.app
npm: https://www.npmjs.com/package/babel-plugin-transform-flow-strip-types-maintained

Fix: babel-plugin-transform-flow-strip-types broken in Babel 7 and 8

takundanashebmuchena-pixel — Sun, 07 Jun 2026 15:03:04 +0000

The original babel-plugin-transform-flow-strip-types hasn't been updated in 9 years and breaks silently in Babel 7 and 8 environments.

The fix

I published a maintained fork that works as a drop-in replacement:

npm install --save-dev babel-plugin-transform-flow-strip-types-maintained

Then update your .babelrc:

{
"plugins": ["transform-flow-strip-types-maintained"]
}

That's it. No other changes needed.

What's fixed

Babel 7 and 8 peer dependency conflicts
Missing syntax plugin declaration
Deprecated visitor patterns
allowDeclareFields support

Automated migration

If you want to update your entire project automatically:

npx flow-strip-migrate .

This updates your package.json and babel config in one command.

More info: https://flowstrip.netlify.app
npm: https://www.npmjs.com/package/babel-plugin-transform-flow-strip-types-maintained