hardhat-deploy: named contract addresses across many chains

What the plugin actually does

hardhat-deploy makes it easy for you to deploy your EVM smart contracts across many chains while keeping track of them and replicating the same environment for testing. The mechanism it adds is a way to associate names to addresses, so test and deployment scripts can be reconfigured by simply changing the address a name points to. The result is clearer scripts, and the README's phrasing is blunt about what it replaces, no more `accounts[0]` in your code. That is the core value and it is worth understanding why it matters. A script that reads `accounts[0]` is a script whose behaviour depends on the order of a list, and reordering it for a testnet deployment silently changes what the script does. A named registry makes the binding explicit. The primary language is recorded as unknown, the licence is MIT, the homepage is rocketh.dev/hardhat-deploy, and the last push was on 2026-09-07.

The code moved, the package did not

The structure of the project is unusual and worth understanding before you file anything. hardhat-deploy is powered by rocketh, and its source code and active development now live in the rocketh monorepo. This repository remains the home of the hardhat-deploy brand and its history, but code changes and issue tracking happen in rocketh so everything stays tested and released together. The source code is at the hardhat-deploy package inside the rocketh repository, issues and feature requests are to be opened there, and discussions also live in the rocketh repository. The reassurance for existing users is explicit: the npm package is unchanged, so keep installing `hardhat-deploy` exactly as before. The repository itself is now mostly documentation, with a `public/` directory and a README, so the version of the docs you are reading is the version that matters.

The version lines, and which hardhat they target

The README carries a note that this is the documentation for hardhat-deploy v2 that works with hardhat v3, and that the documentation for hardhat-deploy v1 can be found on the v1 branch. That is a real fork in the road for anyone starting. The v1 line is the one most existing projects will have in their lockfile, and it is a different tool in several respects, particularly around proxy deployment, which the v2 architecture handles through a separate module. The repository has no GitHub releases, so the version of the code you install comes from npm rather than from tags here. The topics list the scope, with deployment, ethereum, hardhat and solidity, and the description itself is simply hardhat deployment plugin.

Why not Hardhat's own Ignition plugin

The README is direct about the comparison with the official alternative. While Hardhat's official Ignition plugin offers a robust deployment system, it comes with a rigid DSL that limits flexibility. The advantages hardhat-deploy with rocketh claims are listed as five. Intuitive deployment scripts, written in plain TypeScript without learning a new DSL. Browser-compatible deployments, because of rocketh's framework-agnostic design, so your deployment scripts can be executed directly in the browser, enabling in-app deployments, testing in web environments and integration with web frontends. Hot Contract Replacement, described as the equivalent of hot module replacement for smart contracts, where you edit contracts and see changes live while developing using proxy patterns. Flexible proxy patterns, with declarative proxy deployment through `deployViaProxy` for upgradeable contracts, including support for OpenZeppelin transparent proxies. And diamond support, deploying EIP-2535 diamonds declaratively, where you specify the new state and hardhat-deploy generates the `diamondCut` for you.

The feature list, and the two that stand out

The key features list is long and two entries are about reliability rather than convenience. Deployment retrying works by saving a pending transaction, so you can recover confidently from interruptions, which matters when a deploy dies halfway through a multi-contract sequence. And deployments as test fixtures via Hardhat helpers, with caching optimisation, so a test that needs a deployed contract gets one without redeploying on every run. The rest covers chain configuration export through the `@rocketh/export` package, listing deployed contract addresses and their ABIs, which is what a web app needs to talk to the contracts it deployed. There is library linking at the time of deployment, deterministic deployment across networks, support for specific deploy scripts per environment such as L1 versus L2, a deployment dependency system that only deploys what is needed, helpers to read and execute transactions on deployed contracts by name, saved metadata of deployed contracts for full verification via Sourcify or Etherscan, contract verification submission at any time since all the necessary information is saved, and support for Hardhat's fork feature, so you can access deployments even when running through a fork.

The rocketh module system, and how the pieces divide

Under the hood, hardhat-deploy uses rocketh, a framework-agnostic system that provides a minimal API to save and load deployments, and everything else is handled by external modules. The `@rocketh/deploy` module provides a deploy function to deploy contracts. The `@rocketh/proxy` module deploys proxies declaratively, like hardhat-deploy v1 did. The `@rocketh/diamond` module deploys diamonds declaratively. The `@rocketh/read-execute` module provides helpers for reading and executing transactions, and `@rocketh/viem` is the viem client integration. You can also provide your own modules for advanced use cases. The architecture note says version 2 is a full rewrite that has been used in production for several years, and that it is fully modular, making it much easier to contribute new deployment mechanisms. So the plugin you install is an assembly of modules over a small save and load core, and the modularity is what lets a new deployment mechanism be added without touching the rest.

What to check before you adopt it

Three things, and the first is the one that catches people. The documentation, the issue tracker and the source code have all moved to the rocketh monorepo, so a bug report opened here will not be acted on, and a question about the code belongs in the rocketh discussions. The second is the hardhat version, since the v2 documentation here covers hardhat v3 and the v1 line is documented on its own branch with a different shape. The third is the deployment model. The plugin is built around a named address registry, and the value only appears once your scripts refer to names, so if your existing scripts are already written against explicit addresses from a config file, the migration is not obviously worth it. What you get for the effort is browser-compatible deployment, which the project puts down to rocketh's framework-agnostic design.

Editorial conclusion

Adopt hardhat-deploy if you deploy Solidity contracts to several chains and want named addresses in your scripts rather than indexed ones, and you are prepared to work within the rocketh module system. Skip it if a single network and a single deployment is all you need, since the naming layer and the module structure add ceremony. Before you start, note that the code and issue tracking have moved to the rocketh monorepo, that the npm package name is unchanged so existing installs keep working, and that the documentation in this repository covers the v2 line, which works with hardhat v3.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. wighawag/hardhat-deploy on GitHub