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.

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

So let’s start with something really important to understand about smart contracts: once you deploy them to the blockchain, they’re immutable. That means if there’s a bug in your code, you can’t just push a patch. The contract is live, and the bug is live with it. That’s why security isn’t something you bolt on at the end — it has to be baked in before you ever hit mainnet.

Let’s walk through the most common vulnerabilities you need to know about.

The first one is reentrancy. This happens when your contract makes a call to an external contract before it’s finished updating its own internal state. An attacker can exploit that window to call back into your contract repeatedly, draining funds before the balance is ever updated. The fix is to use a reentrancy guard and always update your state before making any external calls.

Next up is integer overflow. This is where arithmetic in your contract wraps around past its maximum or minimum value, producing completely unexpected results. The good news is that if you’re writing in Solidity version 0.8 or later, overflow protection is built in by default — so make sure you’re on a modern compiler version.

Third is access control. If you forget to restrict who can call certain functions, anyone can call them — including attackers. The standard solution is to use OpenZeppelin’s Ownable or AccessControl contracts, which give you well-tested role and permission management out of the box.

Then there’s front-running. Miners and validators can see your transaction sitting in the mempool before it’s confirmed, and they can insert their own transaction ahead of yours to profit from that knowledge. You can defend against this using a commit-reveal scheme or by setting slippage limits on trades.

Number five is unchecked calls. When you use low-level calls in Solidity, they don’t automatically revert on failure — they just return false. If you ignore that return value, you could think an operation succeeded when it actually didn’t. Always check the return value of low-level calls.

And finally, centralization risk. If a single externally-owned account — basically just a wallet — is the sole owner of your contract, that’s a serious single point of failure. If that private key is compromised, your entire contract is compromised. The solution is to transfer contract ownership to a Gnosis Safe multisig wallet, where multiple people need to approve any action.

Now let’s look at the NZRT pre-mainnet security checklist. Think of this as your sign-off list before you deploy anything to mainnet. There are eight items to work through.

You should be building on OpenZeppelin base contracts, which are audited and battle-tested. Contract ownership needs to be transferred to a Gnosis Safe multisig, not a personal wallet. Every function in your contract needs appropriate access modifiers so that only the right parties can trigger the right things. You shouldn’t have any hardcoded addresses or secrets in your code. Every state change in the contract should emit an event so there’s a proper audit trail on-chain. Your test suite needs to cover edge cases, not just the happy path. You need to run static analysis — more on that in a moment. And finally, you should have an external audit completed before going live.

Speaking of static analysis — there’s a tool called Slither that you can use to automatically scan your contracts for known vulnerability patterns. To get started with it, you install it using Python’s package manager. Once it’s installed, you point it at your contract file and it does the analysis for you. In the NZRT setup, that means running it against the ITSL Token contract. Slither will flag things like reentrancy risks, unchecked return values, and other common issues — it’s a fast first pass that catches a lot of low-hanging fruit before you bring in a human auditor.

The key takeaway from all of this is that smart contract security is a layered process. You start with well-audited libraries like OpenZeppelin, you write defensive code, you test thoroughly, you run automated analysis with tools like Slither, and then you get external human eyes on everything before anything goes near mainnet. Each layer catches things the others might miss.

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