Welcome to the NZRT Wiki Podcast. Today we’re looking at Gas & Transactions.

If you’ve ever sent a transaction on a blockchain network, you’ve encountered gas. Gas is the unit that measures how much computational work a transaction requires. Every on-chain operation you perform consumes gas, and you pay for it in ETH. The good news, especially if you’re working on Base, is that gas fees there are remarkably cheap — we’re talking around one cent per transaction. Compare that to Ethereum’s main layer, where you might pay anywhere from five to fifty dollars or more for the same operation. So the network you choose really does matter.

Let’s break down what actually makes up a transaction. Think of a transaction as a small packet of information sent to the blockchain. It has seven key fields. First, there’s the from field — that’s the sender’s address, identifying who is initiating the transaction. Next is the to field, the recipient’s address, which could be another person’s wallet or a smart contract. Then there’s the value field, holding the amount of ETH you’re sending, measured in a very small unit called Wei. After that comes the data field, used when you’re calling a function on a smart contract — it holds the encoded version of that function call. Then you have the gas field, which sets the gas limit, essentially the maximum amount of gas you’re willing to let the transaction use. Next is the gas price field — under the modern fee model this is called max fee per gas — and it tells the network how much you’re willing to pay per unit of gas, measured in Gwei. Finally, there’s the nonce, a sequential counter that tracks how many transactions a particular address has sent, helping prevent duplicates from being processed.

So how do you calculate what you’ll actually pay? The formula is straightforward. Your transaction fee equals the amount of gas used, multiplied by the gas price. If you know those two numbers, you can work out the cost.

To give you a feel for what that means in practice, let’s look at a few examples on Base. A simple ETH transfer uses around twenty-one thousand gas units. At a gas price of about zero-point-zero-zero-one Gwei, that works out to roughly a fraction of a cent. An ERC-20 token transfer is a bit more involved, using around sixty-five thousand gas units. And if you’re deploying a full smart contract, you’re looking at anywhere from five hundred thousand to two million gas units, depending on how complex the contract is.

Now, there’s a specific fee model worth understanding, called EIP-1559, which arrived with what’s known as the London upgrade to Ethereum. Before this change, gas pricing was a simple open auction. After the upgrade, fees split into two parts. There’s a base fee, set automatically by the network based on how busy it is — and this portion is actually burned, meaning it’s permanently removed from circulation. Then there’s a priority fee, sometimes called a tip, which goes directly to the validator who processes your transaction. The maximum fee you set covers both of these. In practice, this model makes fees more predictable because the base fee adjusts up and down with network demand rather than spiking unpredictably.

When you’re configuring a development environment — say, with a tool like Hardhat — you can set the gas price to auto, which lets the tool determine the appropriate value for you automatically. Or you can specify an exact value in Wei if you need precise control over your costs.

If you’re working on a test network and need some ETH to experiment with, there are a few places to get it for free. For Base Sepolia, the test version of the Base network, you can visit the Coinbase faucets page or Sepolia Faucet dot com. Alchemy also runs a faucet, though that one requires you to have an Alchemy account set up first. These faucets drip small amounts of test ETH into your wallet so you can practice without touching real funds.

To go deeper on what we covered today, check out the related wiki pages on Ethereum and the Base Network, and on Contract Deployment, which gets into what happens when you push a smart contract to the chain and why those gas costs are so much higher than a simple transfer.

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 Wallets & Keys.

So let’s start with the core idea, because everything else builds on it. A blockchain wallet doesn’t actually hold your crypto the way a physical wallet holds cash. What it holds is your private key. And that private key is what signs your transactions and proves you own what you own. Put simply: whoever controls the key controls the assets. That’s the most important sentence in this entire topic, and it’s worth keeping front of mind as we go through the rest.

Let’s talk about the different types of keys and identifiers you’ll encounter. There are four to know about. First is the private key itself — this is a 256-bit secret value, and it’s what signs every transaction you make. Second is the public key, which is mathematically derived from your private key and is used to verify those signatures. Third is your address — this is the last 20 bytes of a specific hash of your public key, and it’s your on-chain identity, the thing other people send funds to. Fourth is the seed phrase, sometimes called a mnemonic — this is either 12 or 24 words following the BIP-39 standard, and it can regenerate all the keys in your wallet. Lose the seed phrase and you lose access. Share the seed phrase and you’ve handed over control.

Now let’s look at wallet types, because not all wallets work the same way. There are four main types you’ll come across at NZRT. The first is an EOA, or Externally Owned Account. This is the most common type — it’s directly controlled by a private key, and you use it for regular transactions. The second type is a smart contract wallet, like Gnosis Safe. Instead of being controlled by a single key, it’s controlled by code. This makes it great for multisig setups or team accounts where you want more than one person to approve a transaction. Third is a hardware wallet, like a Ledger device. With this, the private key is stored offline on the device itself, which makes it the most secure option for high-value assets because the key never touches the internet. Fourth is MetaMask, which is a browser extension that acts as an EOA. It’s the tool you’ll typically use for development work and signing transactions in a Web3 environment.

Now let’s talk about how NZRT specifically has things set up. There are two wallets to be aware of. The first is a MetaMask wallet used for deployer work — testnet deployment and signing — running on the Base Sepolia network. The credentials and seed for that live in the ICS Blockchain folder under MetaMask Seed. The second is a Gnosis Safe configured as a two-of-three multisig. That means at least two out of three authorised signers need to approve any transaction. It runs on the Base testnet and is used for contract ownership. You can find the signer details in the ICS Blockchain folder under safe-signers.

Before we wrap up, let’s go through the security rules, because this is where things get serious. First — and this cannot be overstated — never commit private keys or seed phrases to a Git repository. If a key ends up in version control, treat it as compromised immediately. Second, store your seeds in encrypted, offline storage. Not in a notes app, not in email, not in a cloud document with no encryption. Third, when you’re working locally with environment variables that contain keys, use a dot-env file and make absolutely sure that file is listed in your dot-gitignore so it never gets pushed. Fourth, on mainnet — meaning real money, real assets — you should always be using either a hardware wallet or a multisig setup. No exceptions. And fifth, any testnet EOA you use for development should never hold mainnet funds. Keep those environments completely separate. A testnet account is for testing; treat it accordingly.

The related topics to dig into from here are Gnosis Safe Multisig, Key Security, and MetaMask Setup — all of which go deeper on the specific tooling mentioned today.

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 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.