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.