qrp-mcp

Every signature in your wallet, contract and validator rests on elliptic-curve cryptography. A large quantum computer breaks it. This tells your AI agent exactly where yours is.

An MCP server that scans a local directory for cryptography that Shor's algorithm defeats — secp256k1, Ed25519, BLS, Schnorr, RSA — plus weak primitives and CI signing commands, and classifies each one: broken by a quantum computer, post-quantum, or neither.

Everything runs on your machine. No network calls, no account, no API key, nothing uploaded. A tool that reads your keys' surroundings has no business phoning home, so this one makes zero outbound connections — enforced by a test, not promised in a paragraph.

Why this matters for chains and wallets

Bitcoin and Ethereum authenticate with ECDSA over secp256k1. Solana, Cardano and Polkadot use Ed25519. Ethereum's consensus layer aggregates with BLS12-381. Taproot adds Schnorr.

All four are public-key schemes whose security rests on discrete-log hardness — and all four fall to the same quantum algorithm. The practical consequence is specific: once a public key is exposed, the private key becomes derivable. Reused addresses, on-chain public keys, and long-lived validator keys are where that exposure already exists today.

None of this is a prediction about dates. It is an inventory question: which of my code paths sign with what? That question has an answer right now, and this tool gives it.

Quick start

Add it to your MCP client — no installation step, uvx fetches and runs it:

{
  "mcpServers": {
    "qrp": {
      "command": "uvx",
      "args": ["qrp-mcp"]
    }
  }
}

Then ask your agent:

Scan ~/code/my-protocol for quantum-vulnerable cryptography.

Tools

What it looks at

Chain and wallet code — secp256k1, ecrecover, ethers, web3, bitcoinjs, ECPair, btcec, tweetnacl, @solana/web3.js, solana_program, bls12-381, blst, @chainsafe/bls, BIP340/Taproot Schnorr. Solidity (.sol), Rust (.rs), Move and Cairo are scanned alongside Python, Go, Java, JS/TS, Ruby, PHP, C/C++/C# and shell.

Classical crypto anywhere else — RSA, DSA, DH, ECDSA and elliptic-curve usage, plus MD5, SHA-1, RC4 and DES/3DES.

CI/CD pipelines — signing commands such as gpg --sign, cosign sign, signtool, jarsigner, codesign.

Infrastructure as code — Terraform and Kubernetes key algorithms, and private key material committed by mistake.

Real run against OpenZeppelin's contracts (711 files, about five seconds):

{
  "detected_algorithms": ["ECDSA", "RSA"],
  "summary": {
    "quantum_vulnerable_count": 2,
    "pqc_ready_count": 0,
    "highest_severity": "high",
    "pqc_readiness": "classical_only"
  }
}

Why deterministic

There is no LLM inside this tool. The same input always produces the same output, and every finding points at a file and a line you can open yourself.

That is the point of handing it to an agent: the agent brings the language, the tool brings the truth. An agent guessing about your signing code is worse than nothing; an agent reading a deterministic inventory can actually reason about it.

What it is not

A free inventory tool, not a readiness assessment. It deliberately does not do:

• risk scoring or prioritisation,
• migration planning,
• network, host or certificate scanning,
• tracking change over time.

Those live in the Quantum Readiness Platform, the product this tool is extracted from. Nothing here is crippled to push you there — what it does, it does completely.

It also does not tell you that you are about to be hacked. It tells you what you are using.

License

Apache-2.0.