SOLUTIONS · USE CASE
Cryptographic Discovery for Smart Contracts
Cryptographic discovery for smart contracts is the process of finding which quantum-vulnerable cryptography a contract codebase depends on. Quantum Sentinel scans Solidity and Vyper source in your repositories and reports signature recovery, pairing-curve precompiles and hashing by name, file, line and curve.
Cryptography in a contract is hard to change
A web service can change its cipher suite with a configuration update. A deployed contract cannot be edited in place. Its signature checks, its curve operations and its hashing are part of code that may hold value for years, and changing them usually means a new deployment or an upgrade mechanism the contract already contains.
That makes the inventory the first job. Before a team can decide what to migrate, it has to know which contracts verify signatures with secp256k1, which call pairing precompiles, and where those contracts sit in the wider estate. Read the companion blog post on cryptographic discovery for Web3 for how this connects to Ethereum’s own post-quantum roadmap.
What the scanner flags in Solidity and Vyper
Solidity and Vyper share the same Ethereum Virtual Machine idioms, so one set of detections covers both. Each row below is a construct the scanner recognises, and each finding is named by the curve involved.
| Construct in the source | Reported as | Curve | Rating |
|---|---|---|---|
ecrecover( and OpenZeppelin ECDSA.recover and tryRecover | ECDSA (EVM ecrecover) | secp256k1 | High |
A literal reference to secp256k1 | secp256k1 | secp256k1 | High |
call or staticcall with gas() and a precompile address of 0x06, 0x07 or 0x08 (EIP-196, EIP-197) | BN254 (alt_bn128 pairing) | BN254 | High |
call or staticcall with gas() and a precompile address from 0x0b to 0x11 (EIP-2537) | BLS12-381 | BLS12-381 | High |
keccak256( | Keccak-256 | None | Low |
The precompile detection matches the standard inline-assembly form: call or staticcall with gas() as the first argument and the address written in hexadecimal. Requiring that context keeps an ordinary numeric constant from being reported as a curve operation. Other spellings of the same call, such as a decimal address or an adjusted gas argument, are not matched, so treat precompile findings as a minimum rather than a complete count.
Named correctly, not generically
Two details matter to a team that knows its own stack.
secp256k1 is not a NIST curve. It is a SECG curve that NIST never adopted. Quantum Sentinel reports it as secp256k1, with the reasoning attached: elliptic-curve discrete-log schemes are broken by Shor’s algorithm, and CNSA 2.0 does not list secp256k1, or any classical elliptic-curve scheme, as approved.
Keccak-256 is not SHA3-256. Solidity’s keccak256 uses the same sponge construction as NIST SHA-3 with different padding. It is reported as Keccak-256 and rated as a secure hash, so it does not show up as an elliptic-curve finding.
BN254 and BLS12-381 are pairing-friendly curves. BN254 is the curve behind Ethereum’s zk-SNARK precompiles, and BLS12-381 is used for Ethereum consensus signatures and the EIP-2537 precompiles. The discrete log on their pairing groups is broken by Shor’s algorithm in the same way, and both are rated High.
Findings you can act on
Each finding records the repository, the file, the line, the enclosing function, the algorithm and the curve. The finding lands in the same Enterprise CBOM as every other source of cryptography, so a contract that verifies signatures with secp256k1 sits in the same inventory as a certificate on a listener and a key in a key manager.
CycloneDX 1.7 exports name secp256k1, BN254 and BLS12-381 with the CycloneDX curve identifiers, so the inventory is readable by other tooling without translation. Discovery feeds the six-stage ECEM lifecycle: Discover, Inventory, Assess, Prioritise, Transition, Monitor.
How it connects
Smart contract scanning is part of source code assessment. Quantum Sentinel connects to GitHub, GitLab, Bitbucket and Azure DevOps over HTTPS with a read-only credential, clones the branch you select for the duration of the scan, and records the finding rather than the source. Files with the .sol and .vy extensions are picked up alongside the other fifteen languages. The full mechanics are on the code repository discovery page.
What this does not cover
It is worth being precise. This is inventory of what the source states, not a smart contract audit. It does not look for reentrancy, access control flaws or other contract vulnerabilities, and it does not read deployed bytecode, on-chain state, wallets, custody systems or validator infrastructure. Where a contract is deployed without published source, the source has to be brought into a repository for it to be assessed. Detection is pattern-based on source text, so it reports what the code states, and precompile calls written in unusual forms need a manual check.
Frequently asked questions
Which smart contract languages does Quantum Sentinel scan?
Solidity and Vyper, identified by the .sol and .vy file extensions, as part of source code assessment across GitHub, GitLab, Bitbucket and Azure DevOps repositories.
What cryptography does it find in a smart contract?
Signature recovery through ecrecover and OpenZeppelin’s ECDSA.recover and tryRecover, references to secp256k1, calls to the BN254 (alt_bn128) pairing precompiles and the BLS12-381 precompiles in the standard inline-assembly form, and use of keccak256. The standard weak-primitive patterns, such as MD5 or SHA-1, apply to contract source as they do to any other language.
Why is secp256k1 reported separately from the NIST curves?
secp256k1 is the Bitcoin and Ethereum signing curve. It is a SECG curve that NIST never adopted, so it is reported under its own name rather than as a NIST curve.
Is keccak256 a quantum-vulnerable finding?
No. Keccak-256 is the native hash of the Ethereum Virtual Machine. It uses the same sponge construction as SHA-3 with different padding, and it is reported as Keccak-256 with a low rating rather than as an elliptic-curve finding.
Does it read deployed contracts or on-chain data?
No. It assesses source code in repositories. Contracts deployed without published source, wallet and custody systems, and validator infrastructure are outside this scanner. Endpoints such as RPC nodes that expose TLS are assessed like any other network service.
Why does this matter before a chain adopts post-quantum signatures?
Contract code is difficult to change once it is deployed. Knowing which contracts depend on which curves lets an owner plan an upgrade path before a chain-level decision forces one.
How do the findings reach the CBOM?
Each finding records the repository, file, line, enclosing function, algorithm and curve, and lands in the same CBOM as network and key management findings. CycloneDX 1.7 exports name secp256k1, BN254 and BLS12-381 using the CycloneDX curve registry.
See which curves your contracts depend on.
Point Quantum Sentinel at one contract repository and see the inventory it produces. Request a demo.