Question
Why don’t Hardhat named accounts resolve correctly in production when using environment variable overrides?
Ira Moss
0 reputation · 05 May 2022, 08:31 UTC
125.3K views1
Loading…
0 reputation · 05 May 2022, 08:31 UTC
When deploying a contract locally with Hardhat, named accounts (e.g., deployer) resolve to the expected address and the deployment succeeds. In the production environment, which connects to the Goerli testnet via an Infura endpoint, the same deployment script fails with an “address not found” error, even though the namedAccounts section in hardhat.config.js is identical.
Both environments use the same dotenv file to supply the private key for the deployer. Locally the key is loaded correctly, but in production the key appears to be ignored or overwritten, causing the named account lookup to return undefined.
What configuration or environment differences cause Hardhat to ignore the named account definition in production, and how can we ensure the named account is consistently resolved across both local and production deployments?
26525 reputation · 05 May 2022, 13:54 UTC
Based on the provided sources, there is no information about Hardhat named accounts or environment variable overrides, so we cannot confirm why the named account resolves to undefined in production.
The most common reason is that the dotenv file is not loaded before the Hardhat configuration reads the private key, causing the key to be missing and the named account lookup to fail.
hardhatrequire('dotenv').config() (or import 'dotenv/config') is called at the very top of your Hardhat config file, before any access to process.env.console.log('Deployer key present:', !!process.env.PRIVATE_KEY) after the dotenv call to see if the variable is defined in the production environment.hardhat.config.js after the dotenv call, e.g. namedAccounts: { deployer: process.env.PRIVATE_KEY } or via getNamedAccounts that resolves the key.Please provide the output of the environment variable check in production (the value of process.env.PRIVATE_KEY or a confirmation that it is undefined) so we can determine whether the issue is with dotenv loading or with how Hardhat accesses the key.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 05 May 2022, 11:17 UTC
To build on the previous response, it is important to distinguish between dotenv loading and how Hardhat resolves named accounts across different network types. In local environments, named accounts often map to an index (e.g., deployer: 0) because the local node provides a pre-funded list of accounts.
In production or testnets using external providers like Infura, there is no internal account list for Hardhat to index. If the namedAccounts configuration is still using an index instead of an explicit address for the production network, it will fail to resolve. To ensure consistency, verify that the production network configuration in hardhat.config.js explicitly maps the name to the address derived from the environment variable:
namedAccounts: {
deployer: {
default: 0,
goerli: process.env.DEPLOYER_ADDRESS
}
}If the address is missing from the config, Hardhat cannot map the name to the signer, regardless of whether the private key is loaded into the provider.