Hardhat

What Is Hardhat?

Hardhat is an open-source development environment used to write, compile, test, debug, deploy, and verify Ethereum smart contracts.

It gives cryptocurrency developers a structured workspace for building applications that run on the Ethereum Virtual Machine, commonly called the EVM.

Hardhat is not a blockchain, cryptocurrency, wallet, token, or smart contract programming language.

It is a developer tool that coordinates compilers, test runners, simulated blockchain networks, deployment systems, libraries, scripts, and plugins.

The official Hardhat documentation describes Hardhat as a flexible and extensible environment for writing, testing, debugging, and deploying Ethereum software.

Developers can use Hardhat to test contract behavior locally before sending transactions to a public blockchain where mistakes may become permanent and expensive.

Hardhat is maintained by the Nomic Foundation for the Ethereum development community.

Current Hardhat Version

Hardhat 3 is the current major version of the development environment.

As of July 13, 2026, the latest tagged release is Hardhat 3.9.1, released on July 2, 2026.

The current release line includes a redesigned plugin system, Solidity-native tests, built-in code coverage, multichain simulation, typed artifacts, build profiles, and a new network manager.

Developers maintaining older projects should confirm whether their plugins and configuration files support Hardhat 3 before upgrading.

A project should pin its development dependencies rather than automatically accepting every future major release.

Why Hardhat Is Used in Crypto Development

Smart contracts can control tokens, protocol treasuries, lending positions, staking systems, decentralized governance, and other valuable crypto assets.

A programming error can freeze funds, allow unauthorized transfers, miscalculate balances, or create an exploitable economic condition.

Hardhat helps developers find problems before contracts are deployed to a live blockchain.

It can compile Solidity source code, execute automated tests, simulate transactions, display execution traces, estimate gas use, and deploy contracts through repeatable procedures.

It also helps development teams standardize project structure and automate work through scripts and continuous integration systems.

Hardhat improves the development process, but it does not guarantee that a smart contract is secure.

Independent review, threat modeling, testing, monitoring, and careful access control remain necessary for production crypto applications.

Hardhat 3 Architecture

Hardhat 3 separates much of its functionality into a core runtime and optional plugins.

The core environment loads the project configuration, manages tasks, creates blockchain connections, and makes development services available to scripts and tests.

Plugins can add contract libraries, assertion tools, deployment functions, verification services, test runners, hardware-signing support, and other capabilities.

This modular design allows a project to install only the tools it actually needs.

It also means that two Hardhat projects may behave differently when they use different plugin combinations.

Developers should document every required plugin and pin compatible versions in the project’s package configuration.

Hardhat Runtime Environment

The Hardhat Runtime Environment is the central object through which scripts, tasks, and plugins access Hardhat features.

It is commonly shortened to HRE.

The HRE can provide configuration data, network connections, artifacts, plugin extensions, and task-related functions.

Hardhat 3 can create more than one independent runtime environment programmatically.

This is useful for advanced scripts, testing systems, and applications that need isolated configurations or simultaneous network connections.

The Hardhat Runtime Environment documentation explains how the runtime connects project configuration with plugins and development workflows.

Hardhat Project Structure

A typical Hardhat project is an npm package containing a project configuration file and several development directories.

The main configuration file is normally named

.

The

directory normally contains Solidity smart contracts.

The

directory contains automated tests written in Solidity or TypeScript.

The

directory contains deployment modules used by Hardhat Ignition.

The

directory contains custom automation scripts.

The project also includes a

file that records Hardhat, plugins, libraries, and other development dependencies.

Keeping a consistent project structure makes testing, review, onboarding, and automated deployment easier.

Installing Hardhat

Hardhat is normally installed as a development dependency inside a JavaScript or TypeScript project.

The current official setup requires Node.js version 22.13.0 or later.

A new project can be initialized with the command

.

The initialization process can create sample contracts, tests, configuration, scripts, and deployment modules.

Developers should use a supported Node.js version because an unsupported runtime can cause installation failures or inconsistent behavior.

The official Node.js support policy explains which Node.js release lines are supported by Hardhat 3.

Hardhat Configuration

The Hardhat configuration file defines how the project should compile, test, connect, and deploy.

It may specify Solidity compiler versions, optimizer settings, plugins, networks, account sources, build profiles, and task options.

Hardhat 3 configuration files use ECMAScript Modules by default.

Scripts and tests can still use other module formats when supported by their environments.

Configuration should be reviewed carefully because different compiler or optimizer settings can produce different deployed bytecode.

A contract should be verified using the same compiler version and settings that produced the deployed code.

Configuration Variables and Secrets

Crypto development projects often require private keys, remote procedure call addresses, and other sensitive values.

Hardhat 3 supports lazy configuration variables that are loaded only when a task actually needs them.

These values can be stored outside the source repository to reduce the risk of accidental publication.

The Hardhat configuration-variable guide explains how values can be validated, formatted, and supplied through external storage systems.

Hardhat also provides an official keystore plugin that can store selected values in encrypted form.

Encryption does not make a weak computer or stolen password safe.

Production deployment keys should use strong access controls, limited balances, hardware signing, multisignature authorization, or another carefully reviewed key-management process.

Compiling Solidity Contracts

Hardhat compiles Solidity source code into bytecode that can run on the EVM.

Compilation also produces an application binary interface, commonly called an ABI.

The ABI describes the contract’s callable functions, events, errors, and parameter types.

Wallets, scripts, front-end applications, and other contracts use ABI information to encode and decode interactions.

Hardhat can support multiple Solidity compiler versions within one project when different source files require them.

Developers should avoid unnecessary compiler variation because it increases review and verification complexity.

The compiler should be configured explicitly instead of relying on an assumed default.

Hardhat Build Artifacts

After compilation, Hardhat creates artifacts containing information about each contract.

An artifact can include the contract name, ABI, creation bytecode, deployed bytecode, link references, and source information.

Hardhat 3 also creates TypeScript declarations for typed artifacts by default.

Typed artifacts can help development tools detect incorrect function names, argument types, and contract interactions before runtime.

The Hardhat artifact specification documents the structure of contract artifacts and build information.

Artifacts should be generated from trusted source code and reproducible compiler settings.

Old artifacts should be cleaned when compiler settings, contract names, or dependencies change significantly.

Build Profiles

Hardhat 3 supports build profiles that define different compiler settings for different workflows.

A development profile may prioritize fast compilation and detailed debugging information.

A production profile may enable the exact optimizer settings intended for deployment.

A coverage profile may modify bytecode so that executed code paths can be measured.

Build profiles reduce the need to rewrite one configuration repeatedly.

However, teams must clearly identify which profile produced each deployment.

Deploying a contract with an unintended profile can create different bytecode, gas behavior, or verification results.

Simulated Blockchain Networks

Hardhat includes simulated networks that run locally for development and testing.

A simulated network allows developers to deploy contracts and submit transactions without spending real cryptocurrency.

It can create funded test accounts, mine blocks immediately, modify timestamps, alter balances, impersonate accounts, and reset state.

These capabilities make it possible to test unusual conditions that would be difficult or expensive to reproduce on a public blockchain.

Hardhat 3 uses an EDR-powered simulated runtime written in Rust.

The simulated environment is designed for fast tests, detailed errors, execution traces, and controlled blockchain state.

A local simulation is useful, but it cannot reproduce every real-world network condition perfectly.

Multichain Simulation

Hardhat 3 was designed to support development across different EVM-compatible chain types.

A project can configure multiple simulated networks with different behavior.

Official documentation identifies first-class simulation support for Ethereum Mainnet and OP Mainnet, with a generic chain type available for other compatible environments.

The Hardhat multichain documentation explains how chain types allow simulated networks to reproduce chain-specific behavior more accurately.

Developers should test against the actual execution rules of every network on which a contract will be deployed.

A contract that works correctly under one network configuration may behave differently when gas rules, predeploys, or transaction formats change.

Hardhat Network Manager

The Hardhat Network Manager controls connections to simulated and external blockchain networks.

Hardhat 3 allows tasks and scripts to create more than one network connection at the same time.

This is useful for cross-network applications, bridge testing, deployment coordination, and applications that read from one chain while writing to another.

Network names in the configuration are connection labels rather than proof that a connection reaches the expected blockchain.

Developers should verify the chain ID, latest block, account balances, and deployment target before signing transactions.

The network-management guide explains how Hardhat connects to simulated networks and remote JSON-RPC endpoints.

Forking a Blockchain Network

Network forking allows a local Hardhat simulation to copy blockchain state from a selected public-network block.

The local environment can then interact with existing contracts, balances, accounts, and storage without changing the real network.

Fork testing is useful for testing protocol integrations, liquidation scenarios, governance changes, token behavior, and contract upgrades.

A fork should be pinned to a specific block number when repeatable results are important.

Testing against the unspecified latest block can produce different results as public state changes.

The remote data provider may also limit requests, record project activity, or temporarily return incomplete information.

Fork testing should never be confused with authorization to control real accounts or assets.

Testing Smart Contracts With Hardhat

Automated testing is one of Hardhat’s most important functions.

Hardhat 3 supports tests written directly in Solidity and integration tests written in TypeScript.

The two testing approaches can be used together in the same project.

Solidity tests are useful for focused contract-level behavior because the tests execute within the EVM environment.

TypeScript tests are useful for application workflows, multiple accounts, off-chain logic, external data, and broader integration behavior.

The official Hardhat testing overview explains the strengths of both approaches.

A strong test suite should cover successful operations, expected failures, access restrictions, extreme inputs, state transitions, and unusual transaction ordering.

Solidity Tests

Hardhat recognizes Solidity test files through supported directory and filename conventions.

Public test functions can deploy contracts, call functions, inspect state, and fail when an expected condition is not met.

Solidity tests can use cheatcodes to modify the test environment.

Cheatcodes can change the caller, advance time, alter balances, expect events, expect reverts, or inspect storage.

These controls make it easier to test conditions that would otherwise require long waits or complicated setup.

Cheatcodes affect the simulated test environment and are not functions available to ordinary users on a public blockchain.

Fuzz Testing

Fuzz testing executes a contract function repeatedly with generated input values.

It can discover edge cases that developers did not include in manually written examples.

A token calculation may work for common values but fail at zero, a maximum integer, a rounding boundary, or an unexpected state combination.

Fuzz tests should define realistic assumptions so that generated values remain meaningful.

A passing fuzz campaign does not prove that the contract is secure because it explores only the configured inputs and properties.

Important invariants should be written explicitly so that the test system knows what behavior must always remain true.

Invariant Testing

An invariant is a property that should remain true throughout many possible sequences of actions.

A lending protocol may require total recorded debt to match the sum of user debts.

A token may require total supply to equal all tracked balances under its accounting model.

An automated market system may require certain reserve relationships to remain valid.

Invariant tests can generate sequences of transactions and verify that the property survives.

They are especially valuable for stateful crypto protocols where vulnerabilities emerge only after several operations occur in a particular order.

TypeScript Tests

TypeScript tests interact with contracts through development libraries and blockchain connections.

The recommended Hardhat 3 setup uses the Node.js test runner with viem.

Official plugins also support an ethers-based setup with Mocha.

TypeScript tests can coordinate several contracts, accounts, files, APIs, and network connections.

They can also test the same workflows used by a decentralized application’s off-chain software.

Tests should avoid depending unnecessarily on live external services because unavailable services can make results unreliable.

Code Coverage

Code coverage measures which contract statements, branches, functions, and paths were executed during tests.

Hardhat 3 includes built-in Solidity code coverage.

Coverage can be requested through the

test option.

The Hardhat code-coverage guide explains that the tool instruments contracts with markers during coverage runs.

The instrumented bytecode is different from normal production bytecode and may use more gas.

High coverage does not prove that tests contain useful assertions or that the contract is secure.

A test can execute every line while failing to check the most important economic outcome.

Gas Statistics and Gas Snapshots

Hardhat can measure gas consumed by public contract functions during test execution.

The

option can display gas-use statistics for supported tests.

Gas snapshots can record expected gas values and identify unexpected changes between code revisions.

These tools help developers find expensive functions, storage-heavy patterns, and accidental gas regressions.

Gas results from simulated networks may not include every cost experienced by a user on a production network.

Layer-specific fees, data publication costs, congestion, and changing protocol rules can affect the final transaction expense.

Gas optimization should never weaken validation, authorization, or accounting safety.

Debugging With Hardhat

Hardhat can display Solidity errors, decoded logs, stack traces, and execution traces.

An execution trace shows the sequence of contract calls and operations involved in a transaction.

The Hardhat execution-trace guide explains how verbosity settings control the amount of debugging output.

Detailed traces can reveal which call reverted, which function was entered, and how nested contract interactions developed.

Tracing is particularly useful for protocols with proxies, callbacks, hooks, token transfers, and several connected contracts.

Debugging output may contain addresses, parameters, or other sensitive development information and should be handled carefully in shared logs.

Solidity Console Logging

Hardhat supports development-oriented console logging from Solidity code in simulated environments.

Developers can print values while a test or local transaction executes.

This can make it easier to inspect state, callers, balances, and intermediate calculations.

Development logging should not remain in production code without a clear reason.

Logging helpers may affect bytecode, contract size, and deployment behavior.

Automated tests and assertions should replace temporary debug statements before release.

Hardhat Tasks

A Hardhat task is a named command that automates part of a development workflow.

A task can compile contracts, inspect accounts, create reports, manage deployments, or perform a project-specific operation.

Plugins can register tasks that become available through the command-line interface.

Custom tasks should validate network identity and user input before sending transactions.

A dangerous task should not silently use the first available account or default to a production network.

Clear command names and confirmation checks reduce the risk of accidental deployment or fund transfer.

Hardhat Scripts

Hardhat scripts are TypeScript or JavaScript programs that use the runtime environment and installed plugins.

A script can deploy contracts, call functions, read state, transfer administrative roles, or generate deployment records.

Scripts are flexible but place more responsibility on the developer than a structured deployment system.

A failed script may leave several transactions completed while later transactions remain unfinished.

Scripts should be designed to detect existing state and avoid repeating dangerous operations.

Production scripts should record transaction hashes, deployed addresses, parameters, network IDs, and results.

Hardhat Ignition

Hardhat Ignition is the official declarative deployment system provided for Hardhat projects.

Developers describe the contract instances and operations they want through deployment modules.

Ignition analyzes those definitions and determines how the deployment should be executed.

It can send independent transactions in parallel, recover from certain errors, and resume interrupted deployments.

The Hardhat Ignition deployment guide explains how contracts and post-deployment calls are grouped into modules.

Declarative deployment reduces some manual scripting risks, but module logic and parameters must still be reviewed carefully.

An automated system can consistently repeat a mistake when the deployment definition is wrong.

Deploying Smart Contracts

Deployment sends contract creation transactions to a blockchain network.

The transaction contains compiled creation bytecode and constructor parameters.

Once confirmed, the contract receives an address determined by the blockchain’s creation rules.

Deployment should use the intended compiler, optimizer, constructor arguments, account, chain, and gas settings.

Teams should perform a final simulated deployment using the exact production artifacts before sending a live transaction.

They should also verify administrative roles, ownership, upgrade permissions, treasury addresses, and emergency controls immediately after deployment.

Private keys should never be committed directly into a Hardhat configuration file or source repository.

Smart Contract Verification

Smart contract verification connects deployed bytecode with its claimed source code and compiler settings.

Verified source allows users, auditors, wallets, and monitoring tools to inspect how a contract is intended to behave.

Hardhat provides an official verification plugin.

The Hardhat verification guide explains that verification proves deployed bytecode was produced from specified source code.

Verification does not prove that the source code is safe, fair, or free from hidden economic risks.

Constructor parameters, linked libraries, optimizer settings, metadata, and compiler versions must match the deployment.

Teams should preserve build information so that verification can be reproduced later.

Hardhat Plugins

Plugins extend Hardhat with additional development functions.

Official plugins support viem, ethers, assertions, network helpers, contract verification, Ignition deployments, encrypted configuration storage, hardware signers, and test runners.

The official plugin directory lists plugins maintained by the Nomic Foundation.

Community plugins can add valuable features but may not have received the same review or maintenance.

A malicious plugin can potentially read project files, environment variables, keys, deployment data, and network traffic.

Developers should inspect plugin ownership, update history, source code, dependencies, permissions, and compatibility before installation.

Dependency Security

A Hardhat project depends on Node.js packages that can execute code during installation, testing, or deployment.

A compromised dependency may attempt to steal environment variables, private keys, source code, or deployment credentials.

Projects should commit a lockfile and review unexpected dependency changes.

Production deployments should use clean systems with minimal software and verified package versions.

Automated dependency updates should not be merged without testing and review.

A package’s popularity does not guarantee that every release is safe.

Hardhat and Private Keys

Hardhat may need access to a signing account when it deploys or calls contracts on an external network.

Using a raw private key in a plain-text configuration file creates a serious security risk.

Development keys should contain only test funds.

Production keys should be protected through encrypted storage, hardware signing, limited permissions, or multisignature procedures.

The deployment account should hold only the amount required for the planned transaction when practical.

Administrative ownership can be transferred to a more secure account after deployment.

Logs and error reports should be inspected to ensure they do not reveal sensitive configuration values.

Hardhat and Hardware Wallets

A hardware wallet can sign Hardhat deployment or administration transactions through a compatible plugin and workflow.

This can keep the private key outside the development computer.

The hardware device should display the destination, network, value, and contract data when supported.

Complex contract deployments may be difficult to interpret on a small device screen.

A hardware wallet cannot identify a harmful deployment merely because the transaction was generated by Hardhat.

The source code, compiled artifacts, constructor arguments, and transaction data must still be reviewed independently.

Common Hardhat Security Mistakes

One common mistake is committing a private key or recovery phrase to a source repository.

Another mistake is deploying to the wrong blockchain because the network label was trusted without checking the chain ID.

A third mistake is using different compiler settings for testing, deployment, and verification.

A fourth mistake is testing only successful actions while ignoring unauthorized callers and failure conditions.

A fifth mistake is depending on a fork of changing blockchain state without pinning a block number.

A sixth mistake is installing unreviewed plugins with access to deployment secrets.

A seventh mistake is assuming that complete code coverage equals a security audit.

An eighth mistake is giving the deployment account permanent control over all protocol functions.

A ninth mistake is failing to verify deployed addresses and ownership after the deployment finishes.

A tenth mistake is sending real funds to locally generated development addresses whose keys were never secured.

Hardhat Best Practices

Pin Hardhat, plugins, libraries, and compiler versions in the project dependency files.

Use a supported Node.js release and a committed package lockfile.

Keep private keys and sensitive endpoints outside the source repository.

Use separate accounts for local testing, public testing, deployment, and long-term administration.

Write unit, integration, fuzz, invariant, access-control, and failure-condition tests.

Run code coverage while remembering that coverage measures execution rather than correctness.

Use fork tests pinned to known blocks for repeatable protocol-integration testing.

Review gas changes and contract size before deployment.

Verify source code and preserve build information after deployment.

Use independent security review for contracts controlling meaningful crypto value.

Hardhat Limitations

Hardhat cannot prove that a contract’s economic design is safe.

It cannot guarantee that a test suite includes every attack path.

It cannot reproduce every production-network condition perfectly.

It cannot prevent a developer from signing a transaction with the wrong account or network.

It cannot secure a private key stored carelessly in the project.

It cannot make an unsafe third-party dependency trustworthy.

It cannot replace formal verification, auditing, bug bounties, monitoring, and incident-response planning.

Hardhat is most effective when used as one part of a wider secure-development process.

FAQ

What is Hardhat in cryptocurrency?

Hardhat is a development environment used to compile, test, debug, deploy, and verify Ethereum and EVM-compatible smart contracts.

Is Hardhat a blockchain?

No, Hardhat is a software-development tool rather than a blockchain network.

Is Hardhat a cryptocurrency?

No, Hardhat does not represent a coin or token.

Who develops Hardhat?

Hardhat is developed by the Nomic Foundation for the Ethereum development community.

What is the current major version of Hardhat?

Hardhat 3 is the current major release line.

What is the latest Hardhat version?

As of July 13, 2026, the latest tagged release is Hardhat 3.9.1.

What programming languages does Hardhat use?

Hardhat projects commonly use Solidity for smart contracts and TypeScript or JavaScript for configuration, scripts, and integration tests.

What does Hardhat compile?

Hardhat compiles Solidity source code into EVM bytecode, ABIs, artifacts, and related build information.

Does Hardhat include a local blockchain?

Hardhat includes simulated blockchain networks designed for local development and automated testing.

Does Hardhat support Solidity tests?

Yes, Hardhat 3 supports tests written directly in Solidity as well as TypeScript-based tests.

Can Hardhat perform fuzz testing?

Yes, Solidity tests can generate varied inputs to test properties and edge cases.

Can Hardhat test contract invariants?

Yes, developers can define properties that should remain true across generated sequences of contract actions.

What is Hardhat Ignition?

Hardhat Ignition is the official declarative deployment system for defining, executing, resuming, and recording smart contract deployments.

Can Hardhat deploy contracts to public networks?

Yes, Hardhat can connect to an external JSON-RPC endpoint and send signed deployment transactions.

Does Hardhat require real cryptocurrency for local testing?

No, simulated networks provide development accounts and balances that have no real-world value.

What is network forking in Hardhat?

Network forking copies blockchain state from a selected public-network block into a local simulation for testing.

Can Hardhat verify a smart contract?

Yes, the official verification plugin can submit source code and build information to supported verification services.

Does contract verification prove a contract is safe?

No, verification connects source code to deployed bytecode but does not prove that the logic is secure or economically sound.

Does high code coverage mean a contract is secure?

No, high coverage only shows that code was executed during tests and does not prove that the correct properties were checked.

Can Hardhat estimate gas use?

Yes, Hardhat can produce gas statistics and snapshots during supported test runs.

Can Hardhat connect to several blockchain networks?

Yes, Hardhat 3 can manage multiple network connections and simulated chain configurations.

Is it safe to store a private key in the Hardhat configuration?

No, private keys should be loaded through a protected external system rather than committed as plain text.

Can Hardhat use a hardware wallet?

Yes, compatible plugins and workflows can use a hardware device to sign selected deployment and administration transactions.

Are all Hardhat plugins safe?

No, plugins can access sensitive project resources and should be reviewed before installation.

Can Hardhat replace a smart contract audit?

No, Hardhat supports development and testing but does not replace independent security assessment.

Why should a fork test use a fixed block?

Pinning a block makes the copied blockchain state stable so that future test runs remain reproducible.

Can Hardhat prevent deployment to the wrong network?

Hardhat can support checks, but developers must still verify the chain ID, account, endpoint, and deployment parameters.

Conclusion

Hardhat is a comprehensive development environment for creating Ethereum and EVM-compatible smart contract software.

It combines compilation, artifacts, simulated networks, testing, debugging, deployment, verification, scripts, tasks, and plugins within one project structure.

Hardhat 3 is the current major release and adds Solidity-native tests, multichain simulation, typed artifacts, build profiles, code coverage, and more flexible network management.

Developers can use Hardhat to test contracts locally before spending real cryptocurrency or placing user assets at risk.

Hardhat Ignition provides a structured deployment system that can resume interrupted work and record deployment state.

Fork testing allows developers to reproduce public blockchain state and test interactions with existing contracts.

Execution traces, coverage reports, fuzz tests, invariants, and gas statistics can reveal many technical problems before deployment.

These tools do not guarantee security because the quality of the result still depends on the source code, tests, assumptions, dependencies, keys, and deployment process.

Private keys should remain outside source repositories and should use strong signing and access-control procedures.

Plugins and package dependencies should be reviewed because they can access sensitive development resources.

Production contracts should use pinned compiler settings, reproducible builds, verified source code, independent review, and post-deployment monitoring.

For cryptocurrency developers, Hardhat is best understood as a powerful workspace for reducing smart contract development risk rather than a replacement for careful engineering and security review.