TL;DR
The Quantum Virtual Machine (QVM) is the execution layer of Quantum Chain. It runs the same bytecode, opcodes, and gas accounting as upstream Ethereum, but the cryptographic primitives that authorize transactions and recover senders are post-quantum. Most contracts and tooling work unchanged. Anything that relied onecrecover or secp256k1-derived addresses needs migration.
What’s identical
- Bytecode and opcodes — Berlin, London hard fork sets. Solidity and Vyper produce the same artifacts.
- Gas table — gas costs per opcode are unchanged.
- Address format — 20 bytes, derived as
Keccak256(publicKey)[12:32]. The formula is the same; only the public key shape changes. - Toolchain — Hardhat, Foundry, ethers.js, viem, web3.py compile and ABI-encode the same way. Read calls and contract interactions work without modification.
- Block, receipt, log, and event schemas — identical.
- JSON-RPC namespaces —
eth_*,net_*,web3_*,debug_*,txpool_*, plus theqc_*alias. - Transaction envelopes — legacy, EIP-2930, and EIP-1559 are all supported.
- Standard precompiles at addresses
0x02through0x0a: SHA-256, RIPEMD-160, identity, modexp, BN-256 add/mul/pairing, blake2f. - Consensus — Clique Proof-of-Authority on mainnet today.
What’s different
| Area | EVM (Ethereum) | QVM (Quantum Chain) |
|---|---|---|
| Transaction signature algorithm | secp256k1 ECDSA | Post-quantum signature scheme |
| Signature size | 65 bytes (v, r, s) | ~3 293 bytes |
| Public key in transaction | Recovered from the signature | Carried alongside the signature, ~1 952 bytes |
| Transaction RLP tail | …, v, r, s | …, signature, publicKey |
| Sender recovery | ecrecover(digest, v, r, s) | Read the publicKey field, hash it: Keccak256(publicKey)[12:32] |
Precompile 0x01 (ecrecover) | secp256k1 recovery | Removed |
Precompile 0x0b | N/A | New — verifies a post-quantum signature given (digest, publicKey, signature) |
| HD wallets (BIP-32 / BIP-44) | Supported | Not applicable — post-quantum keys do not fit the BIP-32 derivation algebra. Use the project’s mnemonic-to-keypair tool. |
| Hardware wallets (Ledger ETH app, Trezor ETH) | Supported | Not supported — they only sign secp256k1. Use Qustody, Clef, or a quantum-aware wallet. |
| EIP-712 typed-data signing | Standard | Same digest construction; verifying contracts must call 0x0b instead of ecrecover. |
| EIP-1271 contract signatures | Standard | Same interface; the inner verification must call 0x0b. |
Cross-chain bridges using ecrecover | Work as designed | Will fail without contract changes. |
| Account abstraction (EIP-4337) | Works | Works, but validateUserOp must call 0x0b instead of ecrecover. |
Migration checklist
Audit your contracts
Search your codebase for
ecrecover and any library that calls it: OpenZeppelin’s ECDSA.sol, EIP-712 verification helpers, multisig wallets, meta-transaction relayers, EIP-2612 permit code, EIP-4337 account-abstraction validators. Each call site needs to be replaced with a call to the 0x0b precompile.Replace ecrecover with the 0x0b precompile
See the drop-in helper below. Update every verification path to pass
(digest, publicKey, signature) instead of (digest, v, r, s). Off-chain code must learn to send the publicKey alongside the signature.Update key generation
Use the project’s
keygenerator binary or the equivalent SDK function (see Accounts and keys). Do not feed Ethereum mnemonics into BIP-32 derivation — the resulting bytes are not valid Quantum Chain keys.Update wallet integrations
Standard MetaMask, Ledger ETH app, and Trezor ETH paths produce ECDSA keys and will not work. Integrate via Qustody, Clef, or a custom wallet that supports the post-quantum scheme.
Re-test EIP-712 / EIP-1271 flows
Anything that verifies a user signature on-chain — permit, meta-transactions, multisig, account abstraction — must be re-pointed at the
0x0b precompile.Re-budget gas
Transaction-level signature verification is more expensive than ECDSA, and the post-quantum signature is larger, so calldata costs are higher. Calls to the
0x0b precompile have a fixed gas cost defined in the genesis config. Re-run gas snapshots before mainnet migration.Update RPC clients
ethers.js, viem, and web3.py work for read calls and contract interactions. They cannot produce a valid Quantum Chain signature on their own — defer signing to Qustody, Clef, or a quantum-aware library.
Smoke-test on devnet
Spin up the development network and replay your contract suite end-to-end before promoting to mainnet.
Drop-in ecrecover replacement
Solidity helper that calls the 0x0b precompile and returns the recovered address, mirroring the shape of the old ecrecover. Sizes are illustrative; check the genesis config for the canonical values used on your network.
ecrecover call:
Where this matters most
EIP-2612 permit workflows must be updated. The off-chain code that produces the signature and the on-chain
permit() function that verifies it both depend on ecrecover. Expect to fork your token contracts.Related
Quantum Chain overview
Network properties, components, and high-level architecture.
Accounts and keys
Generate and manage post-quantum keypairs.
Signing transactions
Three signing models: local keystore, Clef, Qustody.
Quantum safety
Why post-quantum cryptography, and what it protects.