TL:DR;

Private key leaks caused over $2B in losses in 2024. One of the reasons for private key leaks is using them as plaintext in .env files and storing them without encryption in local environments.

This guide shows how to use hardhat-keystore - a plugin by NomicFoundation - to encrypt and securely manage secrets in Hardhat projects, using Neon EVM as an implementation example.

‍

‍

“Private keys - the gift that keeps on giving to opportunistic hackers hunting for low-hanging fruit.”

— Credit: Rekt team

Imagine a single leaked private key costing your project hundreds of thousands or even millions of dollars. That’s not a fictional horror story but an all-too-common reality in 2025. For example:

• In early 2025, Orange Finance suffered a $843.5K breach when a private key was inadvertently leaked during a “bridge upgrade” (see Rekt investigation).
• Days later, Hacken, a renowned security firm, saw a $170K exploit after attackers used a stolen bridge key to mint and dump 900M tokens (see Rekt article).

“Hacken's $170K lesson proves that knowing about security and practicing it are two very different skills.” - writes a Rekt reporter, and we agree. In fact, that’s why later in this article we show how Neon EVM uses Hardhat Keystore to protect private keys in its projects, so that you can do the same.

These are but two incidents among countless others documented in reports and investigations. According to Chainalysis, which closely tracks crypto crime trends, they’re part of a broader pattern:

• 2024 saw over $2.2 billion stolen across 303 crypto hacks - the highest number of incidents ever recorded.

• The 2025 Chainalysis Crypto Crime Report states private key compromises made up 43.8% of all crypto theft in 2024, accounting for over $2.2 billion in stolen funds. North Korea-affiliated hackers alone stole approximately $1.34B (61% of total losses), occasionally by compromising private keys in corporate networks.

While blockchain security is a complex and multifaceted issue, these numbers keep reminding us that we should focus on better private key management - not only as end users protecting our personal wallets, but also as developers - handling keys in the code.

‍

Any smart contract developer has, at some point, passed private keys into a .env file to deploy contracts, run scripts, or interact with the blockchain. It’s one of the first things you learn to do in blockchain development and it works just fine - but it’s also one of the riskiest habits you can pick up.

Plaintext storage of private keys, even in seemingly local environments, opens the door to accidental leaks, malicious access, and eventual loss of funds.

When you add a private key like this to a .env file:PRIVATE_KEY=0xabc123...

You’re exposing that key to:

• Git leaks: Accidental commits push keys to public or private repos.
• Process exposure: Environment variables can be accessed by subprocesses or plugins.
• Team misuse: Sharing .env files means giving others unrestricted access to sensitive keys.
• Malicious software: Malware can read .env files and extract credentials.

Plaintext key storage is a single point of failure that puts developer wallets at unnecessary risk.

‍

Hardhat Keystore is a plugin that allows using encrypted secrets instead of passing plaintext private keys into .env file. At the moment of writing this article, it’s in alpha version and only available with Hardhat 3.

Instead of storing private keys in plaintext, Hardhat Keystore:

• Encrypts private keys using a secure password
• Stores only the encrypted keystore files in your project directory
• Decrypts keys at runtime only, keeping them off disk and out of memory logs

This approach is used in projects like Neon EVM’s composability libraries, where secure key handling is essential for cross-runtime deployments.

‍

To securely manage private keys and secrets in your Hardhat project, you can use the hardhat-keystore plugin by Nomic Foundation, which is already added to Neon’s GitHub projects.

This guide shows how to set it up using the Neon-contracts repository as an example. This repository contains composability libraries and example caller contracts that show how to use these libraries in Solidity smart contracts to interact with Solana programs from EVM dApps.

‍

When you clone the repo and install npm, the plugin should get installed together with other dependencies.

If not, install it using npm install --save-dev @nomicfoundation/hardhat-keystore

‍

If you’re setting keystore for the first time, you’ll need to create a password.

This will be your master key - it will encrypt the secrets and will later allow you to decrypt them.

Just start setting up the keys by pasting npx hardhat keystore set PRIVATE_KEY_OWNER in the root of the project, and you’ll be prompted to “Enter the password”

‍

To store encrypted secret values into this project's Hardhat keystore file, run the following commands in the CLI:

‍npx hardhat keystore set PRIVATE_KEY_OWNER

After entering the password, you’ll be asked to input the actual secret value (in this case - a private key for your EVM wallet) that will be encrypted and saved in an encrypted .json file.

‍

Once the master password is set, you’ll be prompted to enter it to set other secrets.

npx hardhat keystore set PRIVATE_KEY_SOLANA

These secrets will be stored in a special ****file, located in your Hardhat project directory. This file is:

• Encrypted: The secrets inside are not readable without your master password.
• Project-specific: Each Neon Hardhat project has its own keystore file. This feature isn’t available by default in keystore plugin - Neon EVM introduced custom logic to make it project-specific.
• Portable and secure: You can commit it to version control safely, as long as your password remains private.

‍

You can add the keystore password to the .env file (as KEYSTORE_PASSWORD) which allows secrets to be decrypted automatically when running Hardhat tests and scripts.

Otherwise, each running Hardhat test and script will have the CLI prompt a request to enter the keystore password manually.

‍

For Neon projects, the keystore file which stores your keys in an encrypted form is unique to each Hardhat project. To find where it’s stored for your current project, run this command in your terminal:

‍npx hardhat keystore path

This will display the exact path to the keystore .json file used by your Hardhat setup.Neon EVM introduced custom logic to make keystore file storage project-specific, which is not a default feature of Hardhat Keystore plugin. But even without this custom feature, the plugin is a powerful encryption tool.

‍

‍

• Explore the Hardhat Keystore GitHub repo
• Check out Neon’s implementation
• Refactor your project to use encrypted secrets instead of .env keys
• Join our Discord for setup support and troubleshooting