hardhat-kms 1.0 is out (latest: 1.0.1).
hardhat-kms is a Hardhat 3 plugin that signs transactions, messages, typed data and EIP-7702 authorizations with secp256k1 keys in AWS KMS, Google Cloud KMS or Azure Key Vault. The private key never leaves the KMS, and every signature is checked against the key's address before the plugin uses it.
Install
Install the core with the package for your cloud, here AWS (@hardhat-kms/gcp and @hardhat-kms/azure for the
others):
npm install --save-dev "hardhat@^3.18.0" hardhat-kms @hardhat-kms/aws
Configure a key
Then attach a key to a network:
import hardhatKmsAws from "@hardhat-kms/aws";
import { configVariable, defineConfig } from "hardhat/config";
export default defineConfig({
plugins: [hardhatKmsAws],
kms: {
keys: {
deployer: { provider: "aws", keyId: "alias/deployer" },
},
},
networks: {
sepolia: {
type: "http",
url: configVariable("SEPOLIA_RPC_URL"),
chainId: 11155111,
kmsAccounts: ["deployer"],
},
},
});
viem, ethers and Ignition sign with the key without code changes.
Try it and tell me what broke
I'm looking for one developer per cloud to follow a tutorial from a new project, with a test key on Sepolia: AWS, Google Cloud, Azure. Report what worked, broke or confused you with a tester report. Test keys and testnets only; remove credentials, cloud identifiers and API-keyed RPC URLs before posting.
Links
A community plugin, built in a personal capacity. Not affiliated with or endorsed by Nomic Foundation, Amazon Web Services, Google or Microsoft.
Top comments (1)
Really like that every signature gets checked against the key's address before it's used.
Question on the EIP-7702 part: a deployer key signing an authorization basically hands its account to whatever contract it points at. Does the plugin show the delegate address and chain id before signing, or treat 7702 auths differently from normal txs? Chain id 0 especially, since that one is valid on every chain. That's the one signature I'd want a human to look at every time.