Smart Contract Cryptography and Quantum Risk: Finding ecrecover, BN254 and BLS12-381 in Solidity and Vyper

Cryptographic discovery for Web3 is the practice of finding every place a smart contract codebase depends on quantum-vulnerable cryptography, so that owners can plan changes before the chain forces them. In Ethereum-style contracts that dependency is concentrated in a small number of constructs: signature recovery with ecrecover, calls to precompiled contracts for the BN254 and BLS12-381 curves, and the keccak256 hash.

This post covers where Ethereum’s own documentation says its cryptography is exposed, what those constructs look like in a contract repository, and what a discovery scan of Solidity and Vyper source reports. It also covers what such a scan does not do, because the boundary matters as much as the coverage.

Where Ethereum’s cryptography is exposed to quantum computers

The post-quantum page on ethereum.org lists four areas of the protocol that rely on cryptography a large quantum computer would break:

• Consensus-layer BLS signatures, which aggregate validator votes and rely on elliptic-curve pairings.
• KZG commitments, used to show that rollup data is available.
• Account signatures, which are ECDSA on secp256k1. An account that has sent a transaction has exposed its public key onchain.
• Application-layer zero-knowledge proofs, many of which use pairing-based curves.

The same page describes the Lean Ethereum roadmap, which targets 2029 for full post-quantum protection through phased milestones. Roadmaps move, so check the page itself for the current position. The point for a contract owner is narrower: those four areas are protocol decisions, and they belong to the chain. What a contract does with the same primitives is a separate dependency, and it belongs to the team that wrote the contract.

What a contract repository contains

Contracts call cryptographic primitives that the chain provides. Three appear again and again.

• Signature recovery. ecrecover, or OpenZeppelin’s ECDSA.recover and tryRecover wrappers, verifies a secp256k1 signature. Permits, meta-transactions and multi-signature approvals commonly rely on it.
• Curve precompiles. Precompiled contracts at fixed addresses perform pairing-curve operations. The BN254 operations are defined in EIP-196 and EIP-197, and the BLS12-381 operations in EIP-2537, which reached Ethereum mainnet with the Pectra upgrade on 7 May 2025. They are usually called from inline assembly with staticcall.
• Hashing. keccak256 is the native hash of the Ethereum Virtual Machine. It is not a quantum concern in the way the curves are, but it needs to be recognised for what it is.

Why the inventory comes first

A web service can change its cipher suite with a configuration update. A deployed contract cannot be edited in place. Changing a signature check usually means a new deployment or an upgrade mechanism the contract already contains, and either route needs a decision made well before the change is urgent.

A contract that verifies permits with ecrecover has secp256k1 written into its logic. If a chain later offers post-quantum signature options, that contract needs an owner, a plan and a date. None of that can start until someone knows the contract is there, which is the same problem every other part of the estate has.

What a discovery scan of Solidity and Vyper reports

Solidity and Vyper share the same Ethereum Virtual Machine idioms, so one set of detections covers both. Quantum Sentinel reads .sol and .vy files as part of source code assessment and reports each construct by name, file, line, enclosing function and curve:

• ecrecover and the OpenZeppelin recover wrappers are reported as ECDSA on secp256k1, rated High.
• A literal reference to secp256k1 is reported as secp256k1, rated High.
• Calls to the BN254 precompiles, in the standard inline-assembly form, are reported as BN254 (alt_bn128 pairing), rated High.
• Calls to the BLS12-381 precompiles, in the same form, are reported as BLS12-381, rated High.
• keccak256 is reported as Keccak-256, rated Low.

Two details matter to a team that knows its own stack. secp256k1 is a SECG curve that NIST never adopted, so it is reported under its own name and not as a NIST curve. And Keccak-256 uses the same sponge construction as SHA-3 with different padding, so it is kept distinct from SHA3-256 and does not appear as an elliptic-curve finding. The precompile detection matches the standard inline-assembly form, a call or staticcall with gas() and a hexadecimal address, so an ordinary numeric constant is not reported as a curve operation. Other spellings of the same call are not matched, so treat those findings as a minimum rather than a complete count.

Each finding lands in the same Enterprise CBOM as a certificate on a listener or a key in a key manager. CycloneDX 1.7 exports name secp256k1, BN254 and BLS12-381 with the CycloneDX curve identifiers. The full detail is on the smart contract discovery page.

How this maps to the ECEM lifecycle

The six ECEM stages are Discover, Inventory, Assess, Prioritise, Transition, Monitor. For a contract codebase they read as follows.

• Discover the repositories that hold contract source, including ones outside the security team’s view.
• Inventory every signature check, curve operation and hash by contract, file and line.
• Assess each construct against the classification. Elliptic-curve schemes are broken by Shor’s algorithm, and CNSA 2.0 lists no classical elliptic-curve scheme as approved.
• Prioritise by what the contract controls. A signature check that gates funds is not the same as one in a test fixture.
• Transition by choosing between redeployment, an existing upgrade path, or waiting for chain-level support.
• Monitor by rescanning as contracts and libraries change, so new dependencies do not arrive unnoticed.

What discovery 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 precompile calls written in unusual forms need a manual check. The scanning described here applies to Solidity and Vyper.

Beyond Ethereum

Other chains make different choices, and the details change often. On Bitcoin, for example, BIP-360 proposes a Pay-to-Merkle-Root output type that removes the key path spend, the part of a Taproot output that reveals a public key. At the time of writing it is a draft. The chains differ, but the inventory question is the same: which parts of your code and keys depend on elliptic curves, and who owns each one.

Frequently asked questions

What is cryptographic discovery for Web3?

It is the practice of finding every place a smart contract codebase depends on quantum-vulnerable cryptography, such as signature recovery with secp256k1 or calls to pairing-curve precompiles, so that owners can plan changes before a chain forces them.

Which parts of Ethereum’s cryptography need post-quantum upgrades?

Ethereum’s own documentation lists four areas: the BLS signatures that aggregate validator votes, the KZG commitments used for data availability, the ECDSA signatures on secp256k1 that protect accounts, and the elliptic-curve pairings that many zero-knowledge proof systems rely on.

Does Quantum Sentinel scan deployed contracts or on-chain data?

No. It assesses Solidity and Vyper source in code repositories. Contracts deployed without published source, wallets, custody systems and validator infrastructure are outside this scanner.

Which constructs does Quantum Sentinel flag in Solidity and Vyper?

Signature recovery through ecrecover and OpenZeppelin’s ECDSA.recover and tryRecover, references to secp256k1, calls to the BN254 and BLS12-381 precompiles in the standard inline-assembly form, and use of keccak256. Each is named by curve, and Keccak-256 is rated as a secure hash rather than reported as an elliptic-curve finding.

Further reading: Cryptographic Discovery for Smart Contracts, Cryptographic Discovery for Code Repositories and Cryptographic Discovery & CBOM.