How to Audit a Smart Contract for Quantum Vulnerabilities

The Three Quantum Attack Surfaces in Smart Contracts

Most quantum security discussion focuses on wallet-level ECDSA keys. Smart contracts introduce additional attack surfaces that are less commonly discussed but equally important for any protocol that intends to operate beyond the quantum computing threshold.

The three surfaces are:

1. On-chain ECDSA signature verification via ecrecover()
2. Signature-based access control that inherits the wallet-level quantum vulnerability
3. Address-derived identifiers that treat EVM addresses as cryptographic security boundaries

Each of these surfaces has a different risk profile and a different remediation approach. This audit guide walks through each one systematically. For broader context on why ECDSA is the underlying issue, see our post-quantum cryptography guide.

Attack Surface 1: ecrecover() Calls

ecrecover() is a Solidity precompile that recovers the Ethereum address that signed a given message hash. It is the on-chain equivalent of ECDSA signature verification. Contracts use it to implement meta-transactions, gasless signatures, permit functions (EIP-2612), EIP-712 typed data signing, and off-chain order books.

The quantum vulnerability: ecrecover() outputs an Ethereum address derived from an ECDSA public key. If a quantum attacker can compute the private key corresponding to the signing address, they can produce valid signatures for any message, including the messages your contract will accept. Every contract that uses ecrecover() for authentication or authorization is vulnerable to this if the signer's ECDSA keys are compromised.

How to Find ecrecover() Usage

1. Run a recursive grep across your contract source: grep -rn "ecrecover" ./contracts/
2. Also search for EIP-712 patterns, which typically wrap ecrecover(): grep -rn "DOMAIN_SEPARATOR|domainSeparator|_hashTypedDataV4|EIP712" ./contracts/
3. Check imports of OpenZeppelin's ECDSA library: grep -rn "ECDSA|SignatureChecker" ./contracts/. These libraries wrap ecrecover() with additional checks but do not change the underlying algorithm.
4. Search for web3.eth.sign and eth_sign patterns in any off-chain signing code that feeds into on-chain verification.
5. Flag every location where a recovered address is compared to a stored address or checked against an access list. These are your authorization boundaries.

For each ecrecover() call, assess: what does a valid signature authorize? Fund transfers, ownership changes, and parameter updates are critical. View functions with no state changes are lower priority.

Attack Surface 2: Signature-Based Access Control

Ownership and access control patterns in Solidity typically rely on msg.sender, which is the Ethereum address that submitted the transaction. This address is derived from the ECDSA public key of the signer. If a quantum attacker derives the private key from the public key, they can submit transactions as that address.

This means that any access control pattern that ultimately depends on "only this ECDSA key can call this function" is quantum-vulnerable, even if it does not use ecrecover() explicitly.

How to Audit Ownership Patterns

1. Search for OpenZeppelin's Ownable: grep -rn "Ownable|onlyOwner|transferOwnership" ./contracts/. Every onlyOwner modifier is a quantum attack surface if the owner's ECDSA key is compromised.
2. Search for AccessControl patterns: grep -rn "AccessControl|hasRole|grantRole|DEFAULT_ADMIN_ROLE" ./contracts/. Role-based access control still depends on ECDSA addresses as role holders.
3. Check for multisig integrations. Gnosis Safe and other multisig contracts also use ECDSA signing. A contract "secured" by a multisig is only as quantum-safe as the least-exposed signer key in that multisig.
4. Look for timelock controllers and governance contracts. These often have admin addresses or executor addresses that are ECDSA wallets.
5. Map the privilege hierarchy: which addresses can upgrade the contract, pause it, withdraw funds, or change critical parameters? Each of those addresses is a quantum attack surface.

The assessment question for each: what is the worst-case impact if this address is compromised? A contract where quantum compromise of the owner address enables full fund drainage is critical priority. A contract where compromise enables only parameter tweaks within bounded ranges is lower priority.

Attack Surface 3: Address-Derived Identifiers as Security Boundaries

EVM addresses appear throughout smart contract state as identifiers: keys in mappings, entries in access lists, comparison targets in require statements. Some of these uses treat the address purely as a label (no security assumption). Others treat the address as a security boundary, meaning the assumption is that only the holder of the corresponding private key can perform certain actions.

Distinguishing between these two uses is essential for a quantum audit.

How to Identify Sensitive Address Usage

1. Search for mappings from address to balance or permission: grep -rn "mapping(address =>" ./contracts/. Flag every mapping where the value represents a financial balance, a privilege level, or an access right.
2. Review every require(msg.sender == ... check. Each one is an address-based security boundary.
3. Check state variables of type address that are used in security-sensitive comparisons: contract owner, fee recipient, governance address, oracle address, and similar roles.
4. Look at events. If the contract emits events that index addresses in security contexts, those addresses are part of the trust model.

The key distinction: balances[msg.sender] in a token contract is a security boundary because only the ECDSA key holder for that address can call functions that modify it. A pure label like creator[tokenId] = msg.sender used only for metadata display is lower risk.

Tools for Automated Scanning

General-purpose smart contract security tools can help locate the patterns described above, though none currently have quantum-specific rule sets:

• Slither (Trail of Bits): Static analysis tool that can identify ecrecover() usage and flag dangerous patterns. Run slither . --detect ecrecover as a starting point. Slither's detector library is extensible; a custom detector for quantum-sensitive patterns is buildable by teams with Slither familiarity.
• Mythril (ConsenSys): Symbolic execution tool useful for tracing execution paths that depend on signature verification. Can help map what an attacker with a valid signature could execute.
• 4naly3er: Lighter-weight static analyzer that generates reports useful for identifying modifier and access control patterns.

None of these tools will tell you "this contract is quantum-safe." They help you find the code patterns; the quantum risk assessment is a manual step on top of the automated scan results.

What Quantum-Safe Alternatives Look Like

For each attack surface, there is an architectural alternative that reduces quantum dependence:

Replacing ecrecover()

On chains that support it, replace ecrecover() with an ML-DSA signature verification precompile. The function signature and calling convention differ, but the pattern is the same: verify that a message was signed by the holder of a specific key, where the key is now an ML-DSA key rather than an ECDSA key.

On chains without a native ML-DSA precompile, a hash-commitment pattern is an alternative for some use cases: instead of signing a message with ECDSA and verifying on-chain, commit a hash of the authorization off-chain and verify the pre-image on-chain. This does not provide equivalent security properties in all contexts but avoids ECDSA signature verification entirely.

Post-Quantum Access Control

Access control that is quantum-safe ultimately requires quantum-safe signing at the wallet level. Contract-level changes are insufficient if the controlling wallet is still ECDSA. The migration path here is: (a) deploy contracts that accept both ECDSA and ML-DSA signatures during a transition period, (b) migrate admin keys to post-quantum wallets, (c) remove ECDSA acceptance after migration is complete.

Address Identifiers

Where addresses are used as security boundaries rather than labels, consider whether the security assumption can be grounded in a hash commitment rather than ECDSA key ownership. For example, a protocol that uses addresses as identifiers for locked funds could be redesigned to use the hash of a post-quantum public key as the identifier, with verification happening at spend time against the presented public key.

QuanChain's Channel 2 Approach

QuanChain's Channel 2 provides native ML-DSA support at the protocol level. Smart contracts deployed on QuanChain's EVM-compatible environment can use the ML-DSA precompile for signature verification without any of the above migration complexity. The ecrecover() equivalent on Channel 2 verifies ML-DSA signatures, not ECDSA signatures.

This means contracts written for Channel 2 from the start do not inherit the quantum vulnerabilities described in this guide. Access control patterns based on msg.sender are secured by the sender's ML-DSA key, not their ECDSA key. The three attack surfaces exist at the protocol level only if a developer explicitly imports ECDSA verification libraries and uses them alongside the native ML-DSA infrastructure.

For developers auditing existing Ethereum contracts with an eye toward QuanChain deployment, the audit process described here identifies which components need to be rewritten for the Channel 2 environment versus which components can be ported with minimal changes. Consult the quantum-safe smart contracts guide for the full development framework and the NIST PQC standards overview for the cryptographic context underlying these recommendations.

2026 Quantum Smart Contract Audit Checklist

The following checklist translates the three attack surfaces into a structured audit procedure. It is organised into four phases: discovery, risk classification, remediation planning, and verification. Each item has a specific pass/fail criterion. An item fails if the answer is "unknown" or "partially."

Common ECDSA Vulnerability Patterns Found in Production Solidity Code

The following patterns represent the most frequently encountered quantum-relevant vulnerabilities in production Ethereum smart contracts. Each pattern is shown with a concrete code example and its quantum risk classification.

Pattern 1: Direct ecrecover() with no replay protection. This is the most basic form. A contract calls ecrecover(msgHash, v, r, s) and compares the result to a stored address. The quantum risk: once the signer's public key is derivable from the r and s components of any prior signature — which it always is, as ECDSA public keys are embedded in signatures — a quantum adversary can forge any message. The secp256k1 curve means the public key can always be recovered from (v, r, s). No additional information is needed.

Severity: Critical. Found in: early gasless meta-transaction relayers, permit-style approvals, and off-chain order book settlement contracts that predate EIP-712.

Pattern 2: OpenZeppelin ECDSA.recover() wrapping ecrecover(). The OpenZeppelin ECDSA library adds signature malleability protection and input validation, but the underlying algorithm is still secp256k1 ECDSA. Contracts that import @openzeppelin/contracts/utils/cryptography/ECDSA.sol and use ECDSA.recover() or ECDSA.tryRecover() have the same quantum exposure as those calling ecrecover() directly. The OpenZeppelin library solves classical security problems; it does not change the underlying algorithm.

Severity: Critical if the recovered address controls funds or access. Found in: the majority of DeFi protocols deployed between 2020 and 2024. ERC-2612 permit functions, Gnosis Safe signature verification, and most meta-transaction frameworks use this pattern.

Pattern 3: EIP-712 typed data with secp256k1 signing keys. EIP-712 standardises the encoding of structured data before signing, which prevents certain cross-domain replay attacks. The signing key is still ECDSA. The _hashTypedDataV4() function from OpenZeppelin's EIP712 base contract produces a message hash; the actual signing and verification are still performed by the underlying ECDSA key. Contracts using EIP-712 must have their signing keys migrated to post-quantum schemes before the scheme provides quantum protection.

Severity: Critical for authorization functions. Found in: Uniswap V3 permit, Compound governance signatures, most modern DeFi approval flows. This pattern is extremely widespread because EIP-712 is considered best practice for classical security.

Pattern 4: Multisig threshold signatures where one or more signers have exposed keys. A 2-of-3 multisig requires signatures from any two of three designated ECDSA keys. If any of those keys has ever signed a transaction — meaning its public key is on-chain — a quantum adversary can derive its private key and construct valid signatures from it. A 2-of-3 multisig where all three signing addresses have prior transaction history is effectively a 0-of-3 multisig against a quantum attacker, because the attacker can generate valid signatures from any two derived private keys without physical access to any hardware.

Severity: Critical. Found in: protocol governance contracts, DAO treasuries, admin keys for upgradeable contract proxies. This is the highest-value target in the ecosystem because protocol treasuries are controlled by multisigs, and multisig signers routinely use keys with prior transaction history.

Pattern 5: secp256k1 key recovery from the r value of existing signatures. Less commonly discussed but important: the r component of an ECDSA signature is the x-coordinate of an elliptic curve point. Given the (r, s) values from a signature and the message hash, a verifier can recover the public key. This means that for any address that has ever sent a transaction, the full public key is publicly known and on-chain, even if the address itself only shows a hash of the public key. Shor's algorithm operates on the public key, not the address. Any address with prior outbound transactions is fully exposed regardless of whether the current displayed address format reveals the public key directly.

Severity: Informational for understanding exposure scope, but the implication is Critical: the set of vulnerable keys is every address with prior send history, not just those that explicitly published their public key. For a broader view of the signature migration pathway, see the NIST PQC standards implementation guide and the explanation of ML-DSA (CRYSTALS-Dilithium) as the replacement scheme.

Additional Frequently Asked Questions

How many Ethereum smart contracts are estimated to use ecrecover() in production?

Precise figures are difficult to obtain because contract source code is not always published, but analysis of verified Solidity source on Etherscan suggests that a large majority of non-trivial DeFi contracts use ecrecover() directly or through the OpenZeppelin ECDSA library. ERC-2612 permit functions, which use ECDSA signature verification, are included in the ERC-20 standard extension used by most modern tokens. Meta-transaction relayers, gasless approval flows, and off-chain order books all depend on the same underlying pattern. The realistic estimate is that more than 80% of DeFi TVL is protected by access control that ultimately depends on ECDSA signature verification.

What is the gas cost difference between ecrecover() and a hypothetical ML-DSA precompile on Ethereum?

The current ecrecover() precompile costs 3,000 gas. An ML-DSA verification precompile, if one were added to Ethereum, would need to be priced proportionally to its computational cost relative to ecrecover(). ML-DSA-65 verification takes approximately 0.06ms; ecrecover() takes approximately 0.05ms. The verification time ratio is roughly 1.2x, but ML-DSA inputs are larger — a 3,309-byte signature versus a 65-byte ECDSA signature — which adds calldata cost. A rough estimate for a future ML-DSA precompile is 15,000 to 50,000 gas, accounting for both verification compute and calldata overhead. On chains like QuanChain with native ML-DSA support at the protocol level, this overhead is absorbed in the base transaction fee rather than charged as a precompile call.

Can existing Solidity contracts be audited for quantum safety without access to the source code?

Partially. Deployed bytecode can be decompiled to identify known function selectors and precompile calls. The ecrecover() precompile at address 0x01 can be detected in bytecode through its CALL opcode pattern. The presence of a call to 0x01 indicates ECDSA verification is occurring somewhere in the contract. However, bytecode analysis cannot determine the full security context — what the recovered address controls, whether replay protection exists, or whether the owner key has prior transaction history. Source-level analysis provides significantly more useful audit data than bytecode analysis alone.

What is the safest approach for a DeFi protocol to transition governance keys to quantum-safe addresses during migration?

The safest sequence for governance key migration is: (1) generate a fresh post-quantum key pair using ML-DSA; (2) use the existing ECDSA governance key to sign a transaction that adds the new ML-DSA key as a co-owner in a timelocked upgrade; (3) wait out the timelock with the ECDSA key in a hardware wallet that has never submitted a transaction, keeping the public key unexposed; (4) after the timelock, use the ML-DSA key for all subsequent governance operations; (5) after a second timelock confirming the ML-DSA key is operational, remove the ECDSA key from all access control roles. The critical constraint is step 3: the ECDSA governance key must not have been used to sign any prior on-chain transaction, because doing so exposes the public key. If existing governance keys already have exposed public keys, the migration must be treated as an emergency rotation rather than a standard procedure, with a shorter timelock and additional multisig verification.

Does migrating to account abstraction (EIP-4337) on Ethereum solve the quantum vulnerability in smart contract wallets?

Account abstraction separates the signature verification logic from the Ethereum protocol, allowing contracts to define their own signature schemes. A smart account wallet implementing EIP-4337 can replace its verification function with ML-DSA verification rather than ECDSA, which makes it quantum-resistant at the wallet level. However, this only addresses the wallet itself. Any smart contract that the wallet interacts with that uses ecrecover() or ECDSA access control remains quantum-vulnerable. Account abstraction is a necessary component of Ethereum's post-quantum migration path, but it addresses only the entry point, not the contracts downstream. The full evaluation framework for quantum-resistant blockchains covers how to assess whether a given chain's account model addresses the full quantum attack surface.