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

So, what exactly is a smart contract? Put simply, it’s a self-executing program that lives on a blockchain. Once you deploy it, its code is locked in place and it runs exactly as written — no exceptions, no overrides, no one in the middle to interfere. That permanence is actually one of its defining features.

Let’s talk about the key properties that make smart contracts tick, because there are four worth understanding. First, they’re immutable — meaning once that code is deployed, you cannot change it. If you want a contract that can be updated later, you need to build in something called a proxy pattern from the start, so keep that in mind during design. Second, they’re deterministic — the same inputs will always, every single time, produce the same outputs. There’s no randomness, no surprises. Third, they’re trustless — you don’t need a bank, a lawyer, or any other intermediary to enforce the agreement. The network itself does that. And fourth, there’s gas cost. Every operation your contract performs consumes gas, and that gas is paid by whoever is calling the contract. So efficiency in your code isn’t just good practice — it directly affects cost.

Now let’s look at a code example to make this concrete. The sample here is written in Solidity, which is the most common language for writing smart contracts on Ethereum-compatible blockchains. The contract is called ITSL Token — that’s NZRT’s Iteasel Token. At the top, you’ll see a license identifier and a version declaration, which tells the compiler exactly which version of Solidity to use. The contract then imports two pre-built building blocks from a library called OpenZeppelin — one handles the standard ERC-20 token behaviour, and the other handles ownership, so only the contract owner can perform certain privileged actions.

Inside the contract, there’s a constructor — think of this as the setup function that runs once when the contract is first deployed. It takes an initial supply as an input, sets the token’s name to “Iteasel Token” and its ticker symbol to ITSL, assigns ownership to whoever deployed the contract, and then mints the initial supply of tokens straight to that deployer’s wallet. Below that, there’s a mint function. This lets the owner create additional tokens later and send them to any address — but crucially, only the owner can call it, thanks to that Ownable pattern imported earlier.

So that’s the code. A relatively compact file, but it gives you a fully functional, ownable token on the blockchain.

Next, let’s walk through the contract lifecycle — what actually happens from writing code to getting it live in production. You write your Solidity source code first. Then you compile it using a tool called Hardhat, which produces two things: the ABI, which we’ll come back to in a moment, and the bytecode, which is what actually gets deployed to the chain. After compiling, you write and run unit tests — both Hardhat and Foundry are common frameworks for this. Once tests pass, you deploy to a testnet first. In NZRT’s case, that’s Base Sepolia, and you verify the contract on Basescan so anyone can inspect it. Then comes the security audit — a review specifically looking for vulnerabilities before you touch mainnet. Only after that do you deploy to Base Mainnet, and at NZRT that deployment goes through Gnosis Safe for an added layer of control.

That brings us to the ABI — the Application Binary Interface. This is essentially the instruction manual for your contract. It describes every function the contract exposes: what it’s called, what inputs it expects, and what it returns. Your frontend, your scripts, any external tool that needs to talk to the contract — they all need the ABI to do it. Without it, you can’t interact with the contract in any meaningful way.

And that’s the full picture of smart contracts: self-executing, immutable, trustless programs with a clear development pipeline from code to production.

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