Welcome to the NZRT Wiki Podcast. Today we’re looking at Key Management.

If you work anywhere near NZRT’s blockchain operations, whether that’s on testnet, mainnet, or anything involving Gnosis Safe, understanding how we handle keys is essential. This episode walks you through our key inventory, the rules we follow, and how we keep sensitive credentials out of places they should never be.

Let’s start with what keys we actually have in play. There are four main entries in our key inventory, and each one has a specific job.

First, you have the MetaMask deployer key for testnet. Its purpose is testnet deployments only, and it’s stored as a seed phrase in the ITE Blockchain folder under MM-Seed. Second, there are the Gnosis Safe signers, numbered one through three. These are used for contract ownership through a multisig setup, and what’s stored for them in the ITE Blockchain safe-signers folder is addresses only, not the keys themselves. Third, you have the Alchemy API key. This one handles RPC access and lives in the ITE Blockchain Alchemy location. And fourth, there’s the Basescan API key, used for contract verification, stored in the ITE Blockchain Etherscan location.

So that’s your four main keys: a testnet deployer seed phrase, Gnosis Safe signer addresses, an Alchemy API key, and a Basescan API key. Each has a clear purpose and a designated home.

Now let’s talk about the rules. There are five of them, and each one exists for a concrete reason.

Rule one: never commit a dot-env file to Git. The reason is straightforward. If a dot-env file ends up in a repository, even a private one, you’ve potentially exposed your keys to anyone who can access that repo, now or in the future. We’ll come back to how we prevent this in a moment.

Rule two: testnet keys and mainnet keys must stay completely separate. Testnet key exposure is considered low risk because there’s no real money on the line. Mainnet exposure is a different story entirely. Do not mix them.

Rule three: seed phrases are stored offline or encrypted. This protects them against digital compromise. If it’s online and unencrypted, it’s a target.

Rule four: for mainnet, you should always use a hardware wallet or a multisig setup like Gnosis Safe. The reason is that a single externally owned account is a single point of failure. If that one key is compromised, you lose everything it controls.

Rule five: rotate API keys if they’re ever exposed. Both Alchemy and Basescan allow you to regenerate keys, so if something leaks, you can replace it. That’s your safety valve for those two.

Now, how does this look in practice? We use a dot-env file to hold sensitive values locally during development. The file contains four values. There’s a private key placeholder for the testnet deployer. There are two Alchemy URL placeholders, one for Base Mainnet and one for Base Sepolia, both of which include a key segment you replace with your actual key. And there’s a Basescan API key placeholder. The file is clearly labelled at the top as something that must never be committed.

To make sure that file never accidentally ends up in version control, you also maintain a dot-gitignore file. That file tells Git to ignore anything named dot-env, as well as any variation of dot-env with a suffix, so dot-env-dot-local, dot-env-dot-production, and so on are all excluded automatically. That two-line gitignore entry is your last line of defence against accidental exposure.

To tie it all together: you keep a clear inventory of what keys exist and where they live. You follow five rules covering git hygiene, key separation, offline storage, mainnet safety, and key rotation. And you use a dot-env file locally with gitignore protection to make sure credentials never travel further than your own machine.

If you want to go deeper, the related topics on this wiki are Key Security, Gnosis Safe Multisig, and Wallets and Keys, each of which expand on different aspects of what we’ve covered here.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.