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

If you work with NZRT’s blockchain operations, this one is essential listening. We’re talking about how to protect your private keys and seed phrases, because in the world of blockchain, losing control of these means losing assets, and there’s no bank to call.

Let’s start with the core rules, and there are six of them.

First, never commit a dot-env file to Git. The reason is simple but easy to forget. Git history is permanent, so if a key ends up in a commit, it is exposed forever, even if you delete the file later. Someone can still find it by scrolling back through history.

Second, never share private keys through chat, email, or cloud notes. Screenshots leak, inboxes get compromised, and cloud note services have been breached before. If it goes into a message, you have lost control of it.

Third, keep testnet and mainnet on separate wallets. If your testnet key is ever compromised, you only lose test ETH, which has no real value. Keeping them separate means a mistake in a test environment can never drain a real wallet.

Fourth, seed phrases should be stored encrypted and offline. Digital storage, even on a private device, can be breached. Offline means no network exposure at all.

Fifth, for mainnet operations, you should be using a hardware wallet or a multisig setup. A single software wallet is considered high risk for anything holding real value.

And sixth, if you ever suspect an API key has been exposed, rotate it immediately. Keys for services like Alchemy or Basescan are easy to regenerate, so there is no good reason to leave a potentially exposed key active.

Now, there is a code block in the wiki that shows a dot-gitignore template. Rather than reading the syntax, here is what it does in plain terms. It tells Git to automatically ignore and never track several types of files. That includes any dot-env file regardless of what suffix follows it, so dot-env-local or dot-env-production would both be ignored. It also ignores files ending in dot-pem or dot-key, which are common formats for cryptographic key files. And it ignores any folder named keystore. Setting this up at the start of every project means you have a safety net so that even if someone accidentally tries to commit sensitive files, Git will refuse to include them.

Next, let’s talk about what you do if a key is compromised. There are five steps and the order matters.

Step one is immediate. Transfer assets out of the compromised address right away. Do not wait to investigate first, move the assets first.

Step two, if the exposed key was the owner key of a smart contract, you will need to deploy a new contract. The old one cannot be trusted.

Step three, rotate all your API keys. That means Alchemy and Basescan at minimum.

Step four, if the compromised key was a signer on a Gnosis Safe, update the Safe signers to remove that key from the authorised list.

And step five, document the incident. This is important for your own audit trail and for understanding what happened.

Finally, let’s cover where credentials are actually stored. The wiki lists four credential types and their locations. Your MetaMask seed is at ITE slash Blockchain slash MM-Seed. Gnosis Safe signers are at ITE slash Blockchain slash safe-signers. Your Alchemy API key lives at ITE slash Blockchain slash Alchemy. And your Basescan API key is at ITE slash Blockchain slash Etherscan. If you ever need to look one of these up, those are the paths to go to.

If you want to go deeper on any of this, the related wiki pages are Key Management and Smart Contract Security, which build on the concepts covered here.

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