Hardhat CLI and Solc Compiler: Default Version Selection

Question

Goal: Identify the Solidity compiler version that Hardhat employs when no explicit `solidity` field is present in `hardhat.config.js`, and understand how this implicit choice influences plugins that rely on matching compiler versions for TypeChain artifact generation.

Constraints: Hardhat ships with a bundled solc version that may differ between releases, and certain plugins assume the compiler used to compile contracts matches the one used to generate their typings. This creates uncertainty about which solc version will be active after a Hardhat upgrade, potentially causing silent mismatches in generated code.

Questions: What solc version does Hardhat use by default in a given release? How can a team guarantee that the default compiler remains stable across Hardhat updates without explicitly locking a version? Which verification approach confirms the actual solc version invoked during a default compile?

Tasadduq Burney · Answer

Direct Answer
Hardhat uses the solc version bundled with the installed Hardhat release when hardhat.config.js lacks a solidity field. That version is fixed per Hardhat release (for example, Hardhat 2.22.x bundles solc 0.8.24) and can change between minor releases. There is no separate "default" that persists across upgrades; the compiler version follows the Hardhat package version.

Why This Matters for Plugins
Plugins such as @typechain/hardhat read the compiler version from the build-info artifacts (artifacts/build-info/*.json). If you upgrade Hardhat and the bundled solc changes, the next compile uses the new version, but previously generated typings may have been produced with the old one. This mismatch can cause silent type errors or missing types because the plugin assumes the compilation and type-generation steps share the same compiler.

Guaranteeing Stability Without an Explicit solidity Config
Two practical approaches keep the compiler stable across Hardhat updates:

Pin the Hardhat version in package.json (e.g., "hardhat": "2.22.0") and avoid automatic minor/patch upgrades. This is the most reliable method because the bundled solc is part of the Hardhat release.
  Set the SOLC_VERSION environment variable to the exact version string shipped with your pinned Hardhat release (e.g., SOLC_VERSION=0.8.24). Hardhat respects this variable for the bundled compiler only; it does not download arbitrary versions.

Both methods avoid adding a solidity block to the config while preventing surprise compiler changes.

Verification: Confirm the Compiler Actually Used
Run one of the following to see the exact solc version invoked during a default compile:
npx hardhat compile --verbose 2>&1 | grep -i "solidity compiler version"
Or inspect the generated build-info files:
cat artifacts/build-info/*.json | jq -r '.compiler.version' | sort -u
Both commands reveal the compiler version Hardhat actually executed, independent of what the release notes claim.

One Diagnostic Detail That Changes the Recommendation
Does your project already commit artifacts/build-info/ or rely on a CI cache that might serve stale build-info from a previous Hardhat version? If yes, clear the artifacts (npx hardhat clean) before verifying, otherwise the compiler.version field may reflect an older run.

Hardhat CLI and Solc Compiler: Default Version Selection

1 answer

Direct Answer

Why This Matters for Plugins

Guaranteeing Stability Without an Explicit `solidity` Config

Verification: Confirm the Compiler Actually Used

One Diagnostic Detail That Changes the Recommendation

Your perspective belongs here.

0 question comments