Category Archives: 000BCH

000BCH, 09 - Agentic AI & DeFi

Agentic Ai In Defi

Welcome to the NZRT Wiki Podcast. Today we’re looking at Agentic AI in DeFi.

So let’s start with the big question: what actually makes an AI agent in DeFi different from the trading bots you might already know about? The key distinction is reasoning. A traditional DeFi bot follows fixed rules — if price hits X, do Y. An agentic AI reasons about whether to act at all. It reads the current state of the market, thinks through the situation, and decides. That adaptability is what makes it genuinely useful in fast-moving decentralised finance environments.

Let’s walk through the main roles an agent can play. First is a yield optimizer. This agent monitors interest rates across protocols like Aave, Compound, Yearn, and Morpho, then rebalances funds to chase the best returns — with built-in circuit breakers so it won’t rebalance if the gain isn’t worth it.

Second is a liquidity manager. If you’ve used Uniswap V3, you’ll know that concentrated liquidity positions need active management. This agent watches price ranges, tracks fee income, monitors impermanent loss, and repositions when the price drifts outside the target range.

Third, a risk monitor. This one watches loan health factors in protocols like Aave — collateralisation ratios and liquidation thresholds. If a position gets too close to being liquidated, it can trigger a partial repayment before it’s too late.

The fourth role is the most immediately relevant for NZRT: the Revenue Distributor for the ITE business unit. When ETH revenue arrives, this agent reads the ITSL token holder list, calculates each holder’s pro-rata share, and calls the distribute function on the smart contract — but only after a multisig approval step. More on that shortly.

And fifth, a KYC and whitelist manager. This agent processes investor applications, validates identity documents against New Zealand’s FMCA wholesale investor criteria, and either approves addresses onto the smart contract whitelist or escalates flagged cases to a human reviewer.

Now let’s talk about how these agents actually work. The most practical setup for NZRT right now is called an off-chain agent with on-chain signing. In plain terms: the AI runs off-chain as a reasoning engine powered by the Claude API. It uses read tools to pull live data — wallet balances, on-chain events, pool figures — via a service called Alchemy. It runs a decision loop, and if action is needed, it constructs a transaction and submits it to a Gnosis Safe multisig wallet for approval. A human or group of signers reviews and approves that transaction before it ever touches the blockchain. Critically, the agent never holds private keys. It cannot move funds on its own.

The reasoning pattern these agents use is called ReAct — short for Reasoning and Acting. Here is what that looks like in practice. The agent thinks: I should check the ETH balance in the ITSL distribution contract. It reads that balance. It observes there is half an ETH available. It thinks: the threshold is point one ETH, so we are good to proceed. It calculates the distribution across twelve holders. It proposes the transaction to Gnosis Safe. It observes the transaction hash. It then notifies the relevant person to approve it in the Safe interface. Think, act, observe, think again — that is the full loop.

For more complex multi-step operations — like withdrawing from one protocol, bridging to another chain, and depositing somewhere else — there is a plan-and-execute pattern. The agent builds the full plan upfront, then works through each step in sequence, verifying state at each stage before moving on.

Now, safety. This is arguably the most important part. On-chain mistakes can be irreversible, so agentic DeFi needs layered controls. There are six layers worth knowing. By default, agent tools are read-only — write access has to be explicitly enabled. Swap tools automatically reject transactions with more than half a percent slippage, protecting against MEV attacks. Each agent has daily transaction size caps hardcoded in its tool definitions, so a mistake has a ceiling on its damage. All value-transferring transactions must pass through the Gnosis Safe approval gate — that human-in-the-loop step is non-negotiable. Circuit breakers halt the agent and raise an alert if observed state moves outside expected bounds, which can signal an exploit or a compromised contract. And every single tool call is logged with a timestamp, its inputs, and its outputs — so if something goes wrong, you have a full forensic trail to work from.

For NZRT specifically, the immediate application is automating the ITSL revenue distribution process. Today that runs as a manual script. The agent version would watch for incoming ETH deposits via an event subscription, trigger when the balance clears a minimum threshold, calculate each holder’s share from live contract data, propose the distribution transaction to Gnosis Safe, and notify the finance agent and the administrator to approve it. After execution, it logs the event to Nextcloud. One important note: the agent automates execution, but it does not change the legal obligations under the FMCA. Legal review from the administrator is still required before any of this goes live on mainnet.

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

000BCH, 07 - Reference

Blockchain Glossary

Welcome to the NZRT Wiki Podcast. Today we’re looking at Blockchain Glossary.

If you’re new to blockchain development or just need a quick reference for the terminology you’ll encounter working with NZRT’s stack, this episode walks you through the core terms. We’ve got a big list here, so let’s move through it in a way that actually makes sense.

Let’s start with the foundations. A blockchain transaction is a signed instruction sent to the network, whether that’s transferring tokens or calling a smart contract. A smart contract is a self-executing program stored directly on the blockchain, and it’s written in a language called Solidity, which is the primary language for Ethereum-based development. When you want to run that contract, it gets compiled down to bytecode, which is the machine-readable version that lives on-chain. The thing that actually runs it is called the EVM, or Ethereum Virtual Machine. Think of it as the engine underneath everything.

Now, every contract and wallet has an address, which is a twenty-byte hexadecimal identifier derived from a public key. You’ll see these starting with zero-x followed by a string of characters. There are two main account types. An EOA, or Externally Owned Account, is a wallet controlled by a private key, which is a two-hundred-and-fifty-six-bit secret that authorises your transactions. Then there are smart contract accounts, like a Multisig, which requires multiple approvals before anything executes. Gnosis Safe is a common example of that.

To deploy a contract means publishing it to the blockchain. Once it’s live, you interact with it through something called an ABI, which stands for Application Binary Interface. The ABI defines how to call the contract’s functions, what inputs they take and what they return. If you’re building tooling around a contract, you’ll be working with the ABI constantly.

Let’s talk about networks. NZRT’s primary network is Base, which is an Ethereum Layer 2 blockchain built by Coinbase. Layer 1, or L1, refers to the base blockchain itself, which in this context is Ethereum. Layer 2, or L2, is a scaling solution built on top of that. Base has two main environments you’ll use. Mainnet is the live production network, and it has a Chain ID of eight-four-five-three. Base Sepolia is the testnet, where you use fake ETH to test your work without spending real money, and it has a Chain ID of eighty-four-five-three-two. Always build and test on Sepolia first.

Now for the cost side of things. Gas is the unit that measures computational work on the network, and you pay for it in ETH. Gas prices are usually expressed in Gwei, which is one billion Wei. Wei is the smallest unit of ETH, and there are ten to the power of eighteen Wei in a single ETH. So Gwei sits in the middle, which makes it a convenient unit for talking about fees without writing out enormous numbers.

When a transaction goes through, you’ll hear about confirmations. Each confirmation is another block added to the chain after your transaction’s block. More confirmations means more finality, meaning it becomes increasingly unlikely the transaction will be reversed.

Every account has a nonce, which is a sequential number that prevents transaction replay attacks. Each transaction from an account increments the nonce, so the network knows the order and won’t let the same transaction be submitted twice.

For token standards, ERC-20 defines fungible tokens, meaning each token is identical and interchangeable. USDC is a great example, a stablecoin pegged one-to-one with the US dollar, and it’s widely used on Base. ERC-721 is the NFT standard, where each token is non-fungible, meaning unique and non-interchangeable.

A few more terms worth knowing. OpenZeppelin is a library of audited Solidity base contracts, a solid starting point for writing secure token and access control logic. Hardhat is the development environment used to compile, test, and deploy contracts. RPC stands for Remote Procedure Call, and it’s the API layer you use to talk to a blockchain node. Verification means publishing your contract’s source code on Basescan, the block explorer for Base, so anyone can inspect what the contract actually does.

DeFi is Decentralised Finance, financial services running on-chain without traditional intermediaries. RWA stands for Real-World Asset, which refers to a physical asset that’s been represented on-chain as a token.

On the security side, your seed phrase is the twelve or twenty-four words used to recover a wallet. These follow the BIP-39 standard. Treat it like a master password, because it is one. Ethereum itself runs on Proof-of-Stake, which has been its consensus mechanism since an upgrade known as The Merge.

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

00 - Overview, 000BCH

Blockchain Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Blockchain Overview.

If you’ve been following along with NZRT’s work, you may have heard the name Iteasel come up — that’s our ITE product line. And one of the key things happening with Iteasel right now is real-world asset tokenization, built on the Ethereum and Base blockchain network. So today we’re going to walk you through what a blockchain actually is, how NZRT’s stack is set up, and why we’ve chosen the tools we have.

Let’s start from the top. A blockchain is a distributed, append-only ledger of transactions secured by cryptography. Break that down and you get four key properties. First, it’s decentralised — there’s no single point of control, and no one organisation owns it or can shut it down. Second, it’s immutable — once a transaction is confirmed, it cannot be altered. It’s written in stone, so to speak. Third, it’s transparent — all transactions are publicly visible on-chain, meaning anyone can look them up. And fourth, it’s trustless — smart contracts execute automatically without needing a middleman to oversee them. Those four properties are what make blockchain useful for things like tokenizing real-world assets.

Now let’s talk about NZRT’s specific blockchain stack, because this is where it gets practical for us.

At the foundation, you’ve got Layer 1, which is Ethereum. Think of this as the settlement layer — the bedrock that everything else is anchored to. On top of that, NZRT operates on Layer 2, which is Base. Base is built by Coinbase and it’s our primary network. It gives us low-cost, fast transactions while still inheriting Ethereum’s security underneath.

For development, we use a tool called Hardhat. That handles local development, testing, and deployment of smart contracts. When it comes to actually connecting to the Base network, we go through Alchemy, which is a managed node provider — essentially a reliable gateway to the blockchain so we don’t have to run our own node.

To verify contracts and look up transaction history, we use Basescan, which is Etherscan’s explorer built specifically for the Base network. Think of it like a public dashboard where you can inspect anything that’s happened on-chain.

For wallets, we use MetaMask as the deployer wallet during testnet work. For production contract ownership, we use Gnosis Safe, which is a multisignature wallet that requires two out of three approvals before any action can be taken — that’s a critical security layer. And the actual smart contracts themselves are built on top of OpenZeppelin’s ERC-20 base contracts, which are the industry standard for fungible token implementations on Ethereum-compatible networks.

So why Base specifically, rather than deploying straight to Ethereum Layer 1? The difference comes down to cost, speed, and practicality. On Ethereum Layer 1, a single transaction can cost you anywhere from five dollars to over fifty dollars in gas fees, and it takes around twelve seconds to confirm. On Base, that same transaction costs somewhere between one cent and ten cents, and confirms in about two seconds. Both networks offer strong security — Ethereum natively, and Base by inheriting that security from Ethereum underneath. The Base ecosystem is growing quickly, backed by Coinbase, making it a pragmatic choice for a project like NZRT’s ITE tokenization work.

Putting it all together — NZRT’s ITE product, Iteasel, tokenizes real-world hardware assets using an ERC-20 token called ITSL, deployed on Base Mainnet. The full architecture around that, including how the contracts are structured and how assets are represented on-chain, lives in the NZRT Blockchain Architecture documentation, which you can explore separately. There’s also deeper reading available in the Ethereum and Base Network doc, and the NZRT ITE Vault.

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

000BCH, 09 - Agentic AI & DeFi

Chain Fusion Cross Chain

Welcome to the NZRT Wiki Podcast. Today we’re looking at Chain Fusion & Cross-Chain.

Let’s start by unpacking what chain fusion actually means, because the term gets used in a couple of different ways. At its most specific, Chain Fusion is a concept from a platform called the Internet Computer Protocol, or ICP. ICP’s version of chain fusion lets smart contracts running on its network directly read and write to other blockchains — like Bitcoin, Ethereum, or Base — without relying on external bridges or trusted third parties. More broadly though, you can think of chain fusion as the idea of weaving multiple independent blockchains into a single piece of smart contract logic. One contract, multiple chains, all coordinated simultaneously.

So how does ICP actually pull this off? There are two key technologies at play. The first is called Threshold ECDSA, or tECDSA. What this means in practice is that an ICP smart contract — called a canister — can hold and control cryptographic keys in a distributed way. No single node holds the complete private key. Instead, it’s split across many nodes using threshold cryptography, and they cooperate to sign transactions. The result is that an ICP canister can own and operate an Ethereum wallet natively — signing and broadcasting Ethereum transactions — without any centralised custodian or external bridge involved.

The second technology is HTTP Outcalls. This lets ICP canisters reach out to external web services directly from within the smart contract environment. That includes Ethereum and Base node endpoints. So a canister can check token balances, read contract events, and react to on-chain activity happening on those other networks.

If you picture the architecture, an ICP canister sits in the middle. On one side it’s reading state from Base or Ethereum through a service like Alchemy. On the other side it’s signing and broadcasting transactions back to those networks via the distributed key scheme. For NZRT, this is technically exciting because it could allow autonomous token operations without a centralised server or private key holder — but it’s pre-mainnet for our use case, so it stays on the radar rather than the immediate roadmap.

Now let’s talk about something more immediately relevant — the bridge between Base and Ethereum mainnet. NZRT currently deploys the ITSL token on Base, which is Coinbase’s Layer 2 network built on the OP Stack. Understanding how assets move between these two networks matters for things like migrating liquidity or accepting revenue payments from mainnet wallets.

The native connection is called the OP Stack Canonical Bridge. Moving assets from Ethereum mainnet down to Base takes roughly one to three minutes. Moving assets the other way — from Base back up to mainnet — takes seven days. That delay exists because OP Stack uses an optimistic rollup model, where transactions are assumed valid but anyone can challenge them during a fraud proof window. It is the core security model of the system.

If you need faster movement from Base back to mainnet, third-party bridges can help. There are three worth knowing about. Across Protocol uses an intent-based model and is known for being fast and low cost. Stargate, built on LayerZero, uses unified liquidity pools and supports many chains. Hop Protocol is purpose-built for OP Stack Layer 2 networks. The trade-off with any of these is that you’re accepting additional trust assumptions beyond the canonical bridge — the canonical bridge has no extra counterparty risk, while third-party bridges introduce their own smart contract risk.

For cross-chain messaging more broadly, there are three major protocols to understand. The first is Chainlink CCIP, the Cross-Chain Interoperability Protocol. It uses Chainlink’s oracle network to validate and relay messages across chains. It’s enterprise-grade and well-suited to regulated environments and high-value transfers, though it comes at a higher cost and requires paying fees in Chainlink’s own token.

The second is LayerZero. It supports over seventy chains and uses what are called Decentralised Verifier Networks to attest messages. One of its standout features is the Omnichain Fungible Token standard — OFT — which lets an ERC-20 token like ITSL exist natively on multiple chains at the same time rather than being wrapped or bridged. That makes it a compelling option if ITSL ever needs to expand beyond Base.

The third is Wormhole. It uses a network of nineteen validators and is particularly strong for projects that need to reach non-EVM chains like Solana, Sui, or Aptos. It had a significant exploit in 2022, though the funds were fully repaid.

So where does all of this leave NZRT? For ITSL, the current recommendation is to stay single-chain on Base until the mainnet launch is complete. If investor demand grows to the point where wholesale investors want to buy ITSL without bridging from Ethereum mainnet, LayerZero’s OFT standard is the leading candidate to evaluate after launch. On the consulting side, cross-chain architecture is a genuine billable advisory area for ICS — helping clients choose between these protocols, integrate CCIP for regulated token transfers, or design multi-chain token architectures from the ground up.

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

000BCH, 02 - Development Tools

Alchemy

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

Alchemy is NZRT’s primary blockchain infrastructure provider. More specifically, it gives you managed RPC node access for the Base network. If you’re not familiar with RPC — it stands for Remote Procedure Call — it’s essentially the communication layer between your application and the blockchain. Instead of running your own blockchain node, which is resource-intensive and complex to maintain, Alchemy handles all of that for you and exposes a simple API endpoint your code can talk to.

So what does Alchemy actually give you? There are five main services to know about. The first is RPC endpoints — these let you send transactions and read the current state of the chain. The second is enhanced APIs, which go well beyond basic node functionality and include things like token balances, NFT data, and full transaction history lookups. Third, there are webhooks. These let you set up event-driven notifications, so your system gets alerted automatically when a specific transaction event happens on-chain, rather than you having to poll for updates constantly. Fourth is mempool monitoring, which gives you visibility into pending transactions — ones that have been submitted but not yet confirmed in a block. That can be really useful for tracking the real-time status of a transaction. And fifth, and perhaps most practically important, is node reliability. Alchemy offers a 99.9% uptime SLA, which is a meaningful step up from public RPC endpoints that can be slow, rate-limited, or simply unavailable when you need them.

Now let’s talk about how you actually connect to Alchemy in your project. You store two environment variables in your dot-env file. The first is your Base Mainnet URL — this is the endpoint you point at when you’re working on the live network with real funds, and it has your API key embedded at the end of the address. The second is your Base Sepolia URL — same structure, but pointing at the Sepolia test network, which is where you do development and testing before going anywhere near mainnet. Your actual API key isn’t hardcoded anywhere in the codebase — it lives in the credentials store under ITE, Blockchain, Alchemy.

If you’re using Hardhat — NZRT’s smart contract development framework — wiring Alchemy in is straightforward. In your Hardhat config file, you define a networks section. Inside that, you add an entry for base-mainnet. The URL for that network pulls directly from the environment variable you just set up, and your wallet’s private key comes in from a separate environment variable. That configuration is all Hardhat needs to know which node to connect to when you’re deploying contracts or running scripts against the mainnet.

For day-to-day monitoring, Alchemy has a dashboard at dashboard dot alchemy dot com. From there you can manage your API keys and keep an eye on three key metrics: requests per second, compute units consumed, and error rates. If your blockchain calls start behaving unexpectedly, the dashboard is your first diagnostic stop.

Two related topics worth reading alongside this one are the Hardhat wiki entry, which covers the contract development and deployment tooling in more depth, and the Ethereum and Base Network page, which gets into how the underlying network itself works.

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

000BCH, 07 - Reference

Base Network Reference

Welcome to the NZRT Wiki Podcast. Today we’re looking at Base Network Reference.

If you’re doing any blockchain development at NZRT, Base is one of the networks you’ll be working with regularly. This episode covers the key parameters, useful contracts, and how to configure your local Hardhat setup for both the mainnet and testnet environments.

So first, let’s talk about what Base actually is. Base is a Layer 2 blockchain network built on top of Ethereum, developed by Coinbase. Like Ethereum, it uses ETH as its currency and gas token. The important thing to understand is that NZRT works with two versions of the Base network. There’s Base Mainnet, which is the live production network where real transactions happen with real value. And then there’s Base Sepolia, which is the testnet — a sandbox environment where you can develop and test without spending real money.

Let’s go through the network parameters for both. Each network has what’s called a Chain ID, which is a unique number that identifies the network to your tools and wallets. For Base Mainnet, that Chain ID is 8453. For Base Sepolia testnet, it’s 84532. You’ll need these numbers when configuring wallets or development tools.

Both networks use ETH as the currency, though on the testnet it’s test ETH with no real-world value.

For connecting to the networks, you have two RPC endpoint options — think of these as the addresses your tools use to talk to the blockchain. The public RPC for Base Mainnet is mainnet.base.org, and for the testnet it’s sepolia.base.org. If you’re using Alchemy for a more reliable connection, there are dedicated Alchemy endpoints for both networks that include your API key as part of the URL.

For browsing transactions and contracts on-chain, the explorer for Base Mainnet is basescan.org, and for the testnet you’d go to sepolia.basescan.org. These are essentially search engines for the blockchain — you can look up wallet addresses, transactions, and contract details.

If you need to move ETH between Ethereum and Base, the bridge for mainnet is bridge.base.org. For the testnet, you’d use testnets.superbridge.app. And speaking of the testnet — if you need test ETH to actually run transactions in the Sepolia environment, you can get it free from the Coinbase faucet at coinbase.com/faucets. There’s no faucet needed for mainnet since that uses real ETH.

One more useful number: the block time on both networks is approximately 2 seconds. That means transactions confirm pretty quickly compared to Ethereum mainnet.

Now let’s look at two important contract addresses you’ll use frequently on Base Mainnet. A contract address is a fixed location on the blockchain where a specific token or smart contract lives. The first is USDC — the USD Coin stablecoin — which lives at an address starting with 0x8335. The second is WETH, which stands for Wrapped Ether, and that lives at an address starting with 0x4200. You’ll need these addresses any time you’re interacting with those tokens programmatically. Make sure you grab the exact full addresses from the wiki rather than typing them manually — contract addresses are case-sensitive and errors can be costly on mainnet.

Now let’s cover the Hardhat configuration. Hardhat is a development environment for building and deploying smart contracts. The code block in the wiki shows how to add Base Mainnet and Base Sepolia as named networks in your Hardhat config file. What it’s doing is defining two network entries. The first, called base-mainnet, points to your Alchemy Base Mainnet URL — which you store as an environment variable so it stays out of your code — and it uses your private key, also stored as an environment variable, to sign transactions. It also specifies that Chain ID of 8453 so Hardhat knows exactly which network it’s talking to. The second entry does the same thing for Base Sepolia, pointing to the Alchemy Sepolia URL and using Chain ID 84532. Once these entries are in your config, you can deploy or run scripts against either network just by passing the network name in your Hardhat command.

A quick note on environment variables — you’ll notice the config references things like your Alchemy URL and private key pulled from the environment rather than hardcoded. That’s intentional. Never put API keys or private keys directly in your config files. Store them in a dot-env file locally and make sure that file is excluded from version control.

For further reading, the wiki cross-references three related topics: the broader Ethereum and Base Network page, the Alchemy integration notes, and the Hardhat documentation. If you’re setting up a new project or onboarding to NZRT’s blockchain stack for the first time, those are worth working through in that order.

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

000BCH, 03 - Smart Contracts

Contract Deployment

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

Specifically, we’re going to walk through how you compile, deploy, and verify a smart contract on the Base network using a tool called Hardhat. Whether you’re targeting the testnet or pushing to mainnet, this guide covers the full sequence from pre-flight checks all the way through to post-deployment confirmation.

Let’s start before you even touch a deploy command, because there are five things you need to have sorted first.

One, your contract needs to be compiled and come back clean — no warnings. Two, your tests need to be passing. You run those with the Hardhat test command. Three, you need a dot-env file populated with three specific values: your private key, your Alchemy Base Sepolia URL, and your Basescan API key. Four, your deployer wallet needs to actually have test ETH on Base Sepolia — no funds, no deployment. And five, your Hardhat config file needs to include both Base Sepolia and Base Mainnet as networks. Get all five of those sorted before you go any further.

Now let’s talk about the deployment script. There’s a JavaScript file in the scripts folder called deploy dot js, and here’s what it does in plain terms. It starts by grabbing the first signer from your Hardhat environment — that’s your deployer wallet. It logs the wallet address and the current ETH balance to the console, so you can confirm you’re deploying from the right account with enough funds. Then it sets an initial supply of one million tokens, uses Hardhat’s contract factory to pull in a contract called ITSLToken, and deploys it with that initial supply. Once the deployment transaction is confirmed on-chain, it prints the deployed contract address to your console. There’s also basic error handling at the end — if anything goes wrong, it logs the error and exits with a failure code so you know the deployment didn’t succeed.

Once that script is in place, actually running a deployment is a single command. For testnet, you run Hardhat with the deploy script pointed at the base-sepolia network. That will execute everything in the script we just described and land your contract on Base Sepolia. For mainnet, the command is identical except you swap base-sepolia for base-mainnet. The wiki notes to use mainnet with caution — you’ll need a funded deployer wallet, and there’s no undoing a mainnet transaction.

After deployment, you’ll want to verify your contract on Basescan. Verification means the source code is publicly visible and readable on the block explorer, which is important for trust and auditability. You do this with a Hardhat verify command, passing in the network, the contract address you just deployed to, and the initial supply as arguments. So for example, you’d supply the contract address — a long hexadecimal string — and then the number one million as a quoted value. Hardhat handles the rest, submitting your source to Basescan and linking it to the deployed bytecode.

Once verification is done, there are four post-deployment steps to work through. First, go to the Basescan explorer — for testnet that’s sepolia dot basescan dot org, and for mainnet it’s basescan dot org — and confirm your contract actually shows up. Second, click into the Contract tab on that page and check that it shows verified source. If the verification step worked correctly, you should see your readable Solidity code right there in the browser. Third, if you’re on mainnet, transfer ownership of the contract to a Gnosis Safe. That’s a multi-signature wallet setup that protects against single points of failure — so no one person can unilaterally make changes to the contract after it’s live. And fourth, record the contract address in the Wiki under the Blockchain section, so the rest of the team knows where to find it.

That’s the full flow. Pre-deployment checklist, deploy script, run the deploy command for whichever network you’re targeting, verify on Basescan, then confirm, check the source tab, hand off ownership if you’re on mainnet, and document the address.

If you want to go deeper on any of the pieces here, the related topics in the wiki are Hardhat, Contract Verification, and Gnosis Safe Multisig — all worth reading alongside this guide.

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

000BCH, 03 - Smart Contracts

Contract Verification

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

So, what exactly is contract verification, and why should you care? When you deploy a smart contract to a blockchain network like Base, the code that actually lives on-chain is compiled bytecode — essentially machine-readable instructions that aren’t meant for human eyes. Verification is the process of publishing your original source code alongside that bytecode on a block explorer like Basescan. Once verified, anyone can read your contract logic directly in the browser, transactions become human-readable, and your project gains a visible marker of legitimacy — a green checkmark on Basescan that signals to investors and users that you have nothing to hide.

There are four main reasons you’d want to do this. First, investors can read your contract logic directly on Basescan — no guesswork, no blind trust. Second, decentralised applications and scripts can pull and use your public ABI, which is the interface definition that tells external tools how to interact with your contract. Third, if you’re running a public token offering, verification is essentially a requirement — it’s part of the trust baseline. And fourth, that green checkmark is a genuine signal of legitimacy to anyone looking at your project.

Now let’s talk about how you actually do it. There are two main methods: using the Hardhat Verify plugin from your command line, or doing it manually through the Basescan website.

The command-line approach is the easier and more reliable path. You run a command through Hardhat’s verify task, specifying which network you’re targeting along with the deployed contract’s address. If your contract was deployed with constructor arguments — for example, an initial token supply passed in as a number — you include that value at the end of the command. If your contract had no constructor arguments, you leave that part out entirely. And if it had multiple arguments, you pass each one in sequence. The plugin handles the rest, matching your source code to what’s on-chain and submitting it to Basescan automatically. You can target either a test network like Base Sepolia or the live mainnet, depending on what you’re verifying.

The second method is the manual fallback through the Basescan website. You navigate to the verify contract page, enter your contract’s address, and choose how you want to submit your source — either as a single flattened Solidity file or as a standard JSON input. If you go the flattened file route, you first run a flatten command through Hardhat, which combines your contract and all its imports into one big file, and then paste that into the Basescan form. Crucially, you also need to make sure the compiler version and optimisation settings you select in the form exactly match what’s in your Hardhat configuration file. If those don’t line up, verification will fail.

Speaking of failures — let’s walk through the most common issues you might run into. There are four worth knowing about. The first is seeing a message that says the contract is already verified. That one’s actually fine — it just means someone already submitted it, and no further action is needed. The second issue is a compiler version mismatch. The fix is straightforward: go back to your Hardhat config file and use the exact compiler version listed there — don’t guess or approximate. The third issue involves constructor argument mismatches. This happens when the arguments you provide during verification don’t match what was actually passed when the contract was deployed. You need to ABI-encode the exact same values that went in at deploy time. And the fourth issue is import errors that show up in your flattened file. This often happens because the flattening process can produce duplicate SPDX licence declarations when multiple source files each carry their own. The fix is to go through the flattened output and remove the duplicates, leaving only one licence header at the top.

So to recap: verification makes your contract readable, trustworthy, and usable by the broader ecosystem. The Hardhat plugin is your primary tool, and the Basescan UI is there as a backup when you need it. Watch your compiler version, match your constructor arguments exactly, and clean up any duplicate licence headers in flattened files — and you’ll get that green checkmark without much drama.

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

000BCH, 09 - Agentic AI & DeFi

Dao Governance

Welcome to the NZRT Wiki Podcast. Today we’re looking at DAO Governance.

So, what is a DAO? The acronym stands for Decentralised Autonomous Organisation. At its core, a DAO is an organisation where the rules are encoded in smart contracts on a blockchain, and decisions are made by token holders through proposals and votes rather than by a traditional board of directors or management team. Your membership and voting power are represented by governance tokens held in your wallet.

To understand how different that is from a traditional company, think about five key properties. Governance in a company sits with a board and shareholders. In a DAO, it sits with token holders through on-chain voting. Execution in a company means a management team carrying out decisions. In a DAO, smart contracts handle that automatically, or a multisig wallet does. Transparency is selective in a company, but in a DAO every proposal and every vote is public on-chain. Membership in a company means appearing in a share registry. In a DAO, it means holding a governance token in your wallet. And finally, jurisdiction. A company operates under registered company law, while a DAO exists in a much more variable legal space, sometimes unregistered, sometimes structured as a Wyoming DAO LLC.

Now, DAOs come in several types. Protocol DAOs govern a DeFi protocol, where token holders vote on things like interest rates, collateral ratios, and fee distribution. Well-known examples include Uniswap, Aave, and Compound. For NZRT, this is relevant because ITSL, the Iteasel token, could potentially adopt protocol DAO governance after mainnet launch. Investment DAOs pool capital from members and collectively vote on where to invest it. For ITSL, investment DAO patterns could apply to collective governance of revenue distribution. Social and membership DAOs gate access by token or NFT holding and govern treasury spending or community direction. Service DAOs are freelancer collectives that pool reputation and distribute income. And then there are AI DAOs, an emerging category where token holders govern which AI models are used, what system prompts are applied, and how outputs are validated.

Moving on to tooling. For proposals and voting, there are four main tools you should know about. Snapshot uses off-chain, gasless voting. It is the most widely used, but votes do not execute automatically. A multisig wallet has to implement the result, which adds a trust layer. Tally uses on-chain voting through Governor contracts, so votes execute automatically, but voters need to pay gas fees. Aragon is a full DAO framework covering voting, treasury, and membership in one platform. And OpenZeppelin Governor, also called Governor Bravo, is the industry-standard on-chain governance contract used by Compound and Uniswap.

The key tradeoff between Snapshot and on-chain voting is cost versus trust. Snapshot is cheaper and more accessible but advisory only. On-chain Governor executes automatically but can reduce participation because of gas costs. For ITSL governance, the NZRT recommendation is to start with Snapshot combined with Gnosis Safe, where the multisig implements approved proposals, then migrate to on-chain Governor when participation and treasury size justify the overhead.

For treasury management, Gnosis Safe is the most common DAO treasury tool, a multisig where appointed signers implement DAO decisions. Llama handles analytics and spending authorisation. Hedgey manages token vesting and distribution for contributors.

On token distribution, there are four common patterns. A fair launch means no pre-mine, tokens distributed via liquidity mining or airdrop from day one. A retroactive airdrop distributes tokens to past users based on a snapshot of on-chain activity. A vesting schedule locks team and investor tokens over two to four years to prevent immediate selling. And contributor grants allocate tokens from the DAO treasury for completed work.

On the legal side, DAOs exist in a grey zone in most jurisdictions. Wyoming was the first US state to legally recognise DAOs, providing members limited liability through a Wyoming DAO LLC. The Marshall Islands DAO LLC is a low-cost offshore option used by many DeFi projects. A foundation plus DAO structure, common in the Cayman Islands or Switzerland, has a foundation holding the IP and contracts while the DAO governs protocol parameters. An unregistered association carries the highest legal risk since members may have unlimited personal liability. And a New Zealand company with a DAO governance layer on top lets the company retain legal personhood while the DAO handles governance.

Now, the most critical NZRT-specific point. ITSL tokens are currently structured as revenue-sharing interests under the New Zealand Financial Markets Conduct Act 2013, using the wholesale investor exemption. If you add on-chain governance voting rights to ITSL, the token could be reclassified as an interest in a managed investment scheme, which requires full registration, a licensed manager, and a supervisor. That is a significantly higher compliance burden. The clear rule here is do not add governance functionality to the ITSL contract without a New Zealand securities lawyer confirming the exemption still applies.

If legal advice does confirm a DAO layer is permissible, the most conservative structure would work like this. At the top, NZRT Network Ltd remains the legal entity holding contracts and intellectual property. Underneath that sits a DAO governance layer built on Snapshot and Gnosis Safe. That layer uses a separate governance token, not ITSL, and its scope is limited to advisory votes on product direction only. Execution flows through Gnosis Safe with existing leadership retained as a required signer, meaning the DAO cannot override the company’s obligations under the Companies Act 1993.

The immediate next step for NZRT is obtaining a New Zealand securities lawyer opinion on whether adding governance rights to ITSL would trigger managed investment scheme requirements under the FMCA. That legal opinion is the prerequisite before any DAO planning moves forward.

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

000BCH, 09 - Agentic AI & DeFi

Decentralized Ai Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at Decentralized AI Overview.

So let’s start with the basics. What actually is Decentralized AI? You might have heard it called DeAI for short. The idea is that AI model inference, training, and governance happens outside the infrastructure of any single centralized provider — companies like OpenAI, Anthropic, or Google. Instead of your application calling one company’s API, decentralized AI spreads that computation across a whole network of independent nodes. Those nodes are economically incentivized through tokens to participate honestly, and their outputs can be verified using cryptographic proofs.

To understand why that matters, it helps to compare it with what you’re probably already familiar with — centralized LLM APIs. Think about six key dimensions. First, control: with a centralized provider, one company is in charge; with a decentralized network, control is spread across many nodes. Second, pricing: centralized systems charge in USD based on usage, while decentralized networks use token-based incentives. Third, censorship: centralized providers enforce their terms of service, meaning some requests can be blocked, whereas decentralized networks are generally permissionless — though that varies. Fourth, verifiability: with a centralized provider you’re trusting them to run the model correctly, whereas decentralized systems can use cryptographic or zero-knowledge proofs to verify outputs. Fifth, latency: centralized APIs are highly optimized and fast; distributed networks tend to be slower. And sixth, model selection: centralized providers curate the models available, while decentralized networks are more open.

For most NZRT agent tasks, centralized APIs remain the right default. Lower latency, higher quality, simpler integration. DeAI becomes relevant for specific situations: censorship-resistant inference, on-chain verifiable AI decisions, or client workloads that require decentralization as a compliance or trust property.

Now let’s walk through the key decentralized AI networks worth knowing about. The first is Bittensor, which runs on its TAO token. Think of it as a decentralized machine learning marketplace. Validators score miners who run AI models, and the best-performing models earn TAO rewards. It’s organized into subnets — specialized networks for things like text generation, image processing, or even protein folding. For NZRT’s ICS consulting arm, this is relevant when clients want permissionless LLM access without being locked into a single provider, or when TAO itself is part of an investment thesis.

Next is Ritual, which runs an inference layer called Infernet. Ritual connects on-chain smart contracts to off-chain machine learning models — so a smart contract can actually call an AI model as a native operation, through Ritual’s oracle network. For NZRT, the interesting future architecture here would be an ITSL smart contract that calls an AI model to decide things like revenue distribution timing or investor eligibility.

Then there’s Giza, which focuses on Zero-Knowledge Machine Learning, or ZKML. This is about proving that a model ran correctly without revealing the inputs or the model weights. A smart contract can accept a zero-knowledge proof confirming that a specific model produced a specific output. The NZRT use case is around the ITE business unit — specifically, auditable ITSL revenue distribution, where you could prove the allocation algorithm ran correctly before the Gnosis Safe approves a transaction.

Similarly, Modulus Labs focuses on ZK-ML proofs for on-chain verifiable neural network inference, with a particular focus on gaming, DeFi, and prediction markets where outcomes have to be provably fair. And finally, Ocean Protocol is a decentralized data marketplace where data providers earn tokens and AI models can train on licensed data. For NZRT this is lower relevance — noted mainly as a knowledge reference.

Now let’s dig into that ZK-ML concept a little deeper, because it’s the most architecturally interesting one. The flow works like this: off-chain, an AI model runs its inference and generates a zero-knowledge proof of correct execution. That proof is then passed on-chain, where a smart contract verifies it and accepts the result as a trusted input — without ever having to recompute the inference itself. This creates what’s called trustless AI decisions on-chain. The practical implication for NZRT is that an ITSL distribution agent could prove it applied the correct allocation algorithm, and only then would the Gnosis Safe approve the transaction. Worth noting though: ZK-ML is still computationally expensive. Proof generation can take anywhere from seconds to minutes even for small models. It’s production-ready for simple models but still research-stage for anything at the scale of a large language model.

There’s also the concept of AI DAOs — Decentralized Autonomous Organizations that govern AI model parameters. A DAO can vote on which model version is used, what system prompts are applied, and how outputs are acted on. Bittensor subnets already do this, with TAO stakers voting on validator quality and model standards. For NZRT’s ITE unit, this could eventually mean ITSL token holders voting on which model drives distribution decisions — but that’s firmly a post-mainnet consideration.

So to bring it all together: across NZRT’s business units, the DeAI opportunities are real but all currently low priority. ZK-ML for ITSL distribution, AI DAO governance, and Ritual-style oracle integration are all on the radar for ITE — but flagged as post-mainnet. For current operations, keep using Claude via the existing AI agents stack. DeAI is a consulting knowledge domain and a future architecture option, not an immediate infrastructure change.

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

000BCH, 03 - Smart Contracts

Erc 20 Tokens

Welcome to the NZRT Wiki Podcast. Today we’re looking at ERC-20 Tokens.

So, what exactly is ERC-20? It’s the standard that Ethereum uses for fungible tokens. Fungible just means that every token is identical and interchangeable — one ITSL token is worth exactly the same as any other ITSL token, the same way one dollar bill is the same as any other dollar bill. At NZRT, ERC-20 is directly relevant because our ITSL token is built on this standard and lives on the Base network, which is an Ethereum Layer 2 chain.

Now, the ERC-20 standard defines a set of functions that every compliant token contract must include. Think of these as a minimum feature set — a kind of API contract that lets wallets, exchanges, and other smart contracts interact with your token without needing to know anything else about it. Let’s walk through each one.

First, there’s total supply. This does exactly what it sounds like — it tells you how many tokens exist in total. Then there’s balance of, which takes an address and returns how many tokens that address holds. So if you want to check your own token balance, this is the function doing that work under the hood.

Next is transfer. This is how you send tokens directly from your own wallet to someone else’s. You provide the recipient’s address and the amount, and the tokens move. Then there’s approve, which is where things get a little more interesting. Approve lets you authorise a third party — called a spender — to use up to a certain number of your tokens on your behalf. This is critical for things like decentralised exchanges, where a smart contract needs permission to move your tokens without you handing over full control of your wallet.

Closely related to approve is allowance. This function lets you check how many tokens a spender is still authorised to use. So if you approved someone to spend a hundred tokens and they’ve already used thirty, allowance would come back with seventy.

Finally, there’s transfer from. This is the function that actually executes a third-party transfer — the spender you previously approved uses this to move tokens from your address to another one, within the limit you already set.

On top of these functions, ERC-20 also defines two events. An event called Transfer fires every time tokens move between addresses, and an event called Approval fires whenever an approval is granted. These events are how external tools like block explorers and wallets track activity on-chain without having to read every piece of contract state directly.

Now let’s look at how NZRT’s own ITSL token is implemented. The contract code shows a Solidity smart contract that extends two components from the OpenZeppelin library — the standard ERC-20 base contract, and an Ownable module that restricts certain privileged actions to the contract’s owner. The constructor sets the token’s name to Iteasel Token and its symbol to ITSL, assigns ownership to whoever deploys the contract, and immediately mints the full initial token supply to that same deployer address. The supply calculation accounts for decimals by multiplying the number you pass in by ten to the power of eighteen — which brings us neatly to the token’s properties.

The ITSL token has a name of Iteasel Token, a ticker symbol of ITSL, and uses eighteen decimal places. That’s the default for ERC-20 tokens, and it means one token is stored on-chain as a whole number with eighteen zeros behind it. This is how you get precise fractional amounts when transacting. The token lives on Base Mainnet and is built using the OpenZeppelin ERC-20 implementation, which is the industry-standard audited library for this kind of contract.

There is also a mint function in the contract. This is a post-deployment function that only the contract owner can call. It lets the owner create and send additional tokens to any address at any time after launch — useful if you need to distribute tokens in stages rather than all at once at deployment.

If you want to go deeper, the wiki cross-references three related topics: OpenZeppelin, which provides the base contract code; the ITSL Token page, which covers deployment specifics and tokenomics in more detail; and the Contract Deployment page, which walks you through the process of actually getting a contract live on the Base network.

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

000BCH, 01 - Core Concepts

Ethereum Base Network

Welcome to the NZRT Wiki Podcast. Today we’re looking at Ethereum & Base Network.

So first, a quick framing note. NZRT deploys on Base, which is a low-cost Ethereum Layer 2 network built by Coinbase. Base settles back to Ethereum’s main chain, so you get the security of Ethereum with much lower costs. That’s the core reason NZRT uses it, and it’ll make more sense as we walk through the pieces.

Let’s start with some Ethereum basics, because you need these to understand everything that follows.

Ethereum is a proof-of-stake Layer 1 blockchain. Think of it as the foundation — it’s a smart contract platform, meaning you can deploy programs directly onto it that run without a central server. The thing that actually runs those programs is called the EVM, short for Ethereum Virtual Machine. The EVM executes the bytecode of smart contracts, and it runs the same way on every node in the network, which is how you get trustless, consistent execution.

The language most developers use to write those smart contracts is called Solidity. If you’ve seen any Ethereum development work, you’ve probably come across it.

Now, running code on Ethereum costs something. That cost is measured in units called gas. Gas is just the unit of computation — every operation in a smart contract uses a certain amount of it, and you pay for that gas in ETH, which is Ethereum’s native currency.

Speaking of ETH, it’s worth knowing the denominations. The smallest unit is called Wei. One ETH equals ten to the power of eighteen Wei — so an enormous number. In practice, when people talk about gas prices, they usually use Gwei, which is one billion Wei. You’ll see Gwei come up a lot in tooling and configuration, so it’s good to have that in your vocabulary.

Now let’s talk about Base specifically.

Base is what’s called an Optimistic Rollup. That’s a type of Layer 2 solution where transactions are processed off the main Ethereum chain, but the results are periodically posted back to Ethereum for final settlement. The “optimistic” part means transactions are assumed to be valid unless someone challenges them. This approach lets you dramatically reduce costs while still inheriting Ethereum’s security guarantees.

Base was built by Coinbase, its native token is ETH just like Ethereum, and its block time is around two seconds — much faster than Ethereum’s main chain. If you ever need to look up a transaction on Base, the block explorer is at basescan dot org. There’s also a testnet version of Base called Base Sepolia, which is where you’d go to test things without spending real money.

Two numbers worth memorising: the Chain ID for Base Mainnet is 8453, and for the Base Sepolia Testnet it’s 84532. You’ll need these when configuring wallets or developer tools.

On that note, let’s talk about how you actually configure your environment to connect to Base.

When you’re setting up a tool like MetaMask or a development framework like Hardhat to point at Base Mainnet, you’d provide a few key pieces of information. You’d name the network Base, point the connection URL to the mainnet Base endpoint — which you can get either directly from Base or through a provider like Alchemy — set the Chain ID to 8453, set the currency to ETH, and use basescan dot org as the explorer URL.

For the testnet setup — Base Sepolia — it’s the same idea. You’d name it Base Sepolia, point the connection URL to the Sepolia endpoint, use Chain ID 84532, and note that the ETH here is testnet ETH, meaning it has no real value. The explorer for testnet is at sepolia dot basescan dot org. And if you need testnet ETH to actually do anything, Coinbase runs a faucet where you can get some for free.

Faucets, by the way, are just web tools that send you small amounts of testnet currency so you can pay for gas while you’re developing and testing.

That covers the core concepts you need to work with Ethereum and Base at NZRT. To recap: Ethereum is the Layer 1 foundation, the EVM runs smart contracts written in Solidity, gas is what you pay in ETH for computation, and Wei and Gwei are the sub-units of ETH you’ll encounter in tooling. Base sits on top of Ethereum as an Optimistic Rollup — faster, cheaper, same ETH token, Chain ID 8453 for mainnet and 84532 for testnet. When you’re configuring your wallet or dev tools, those two Chain IDs are the key thing to get right.

If you want to go deeper, the wiki also links out to related topics on smart contracts, the Alchemy provider, and the contract deployment process — so those are good next reads if you’re getting hands-on with Base development at NZRT.

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

000BCH, 02 - Development Tools

Etherscan Basescan

Welcome to the NZRT Wiki Podcast. Today we’re looking at Etherscan & Basescan.

If you’ve ever deployed a smart contract and wondered how anyone is supposed to trust it, this is the tool that answers that question. Basescan is the block explorer for the Base network, and it’s one of the most important things you’ll use when working with blockchain development at NZRT. It lets you verify contracts, inspect transactions, and expose your contract’s ABI publicly so that other developers and users can see exactly what your contract does. The same family of tools includes Etherscan, which covers the Ethereum mainnet. Think of these explorers as a public ledger viewer — a window into everything that’s happening on the chain.

Let’s start with the three explorers you need to know about. For the Base mainnet, you head to basescan dot org. For Base Sepolia, which is the test network you’ll use during development, you go to sepolia dot basescan dot org. And for the Ethereum mainnet, the address is etherscan dot io. Those are your three primary URLs, and which one you use depends entirely on which network you’re working on.

Now let’s talk about contract verification, because this is probably the most important thing you’ll do with Basescan. When you verify a contract, you’re publishing its source code publicly on Basescan. This matters for two big reasons. First, it means the public ABI — that’s the application binary interface, essentially the list of functions your contract exposes — becomes accessible to anyone. Second, it makes transactions human-readable. Instead of seeing a wall of encoded hex data, people can actually see what a transaction is doing in plain terms.

To verify a contract, you use Hardhat from your terminal. The first code example shows the general command structure. You run Hardhat’s verify task, specify which network you’re targeting — in this case Base Sepolia — then provide the contract’s deployed address, followed by any constructor arguments your contract was deployed with. So if your contract took two arguments when it was first deployed, you pass both of those in order after the address.

The second example makes this concrete. It shows verifying the ITSL Token contract on Base Sepolia, where the contract was deployed with an initial supply of one million tokens. So the command passes the contract address and then that initial supply value as the constructor argument.

One thing to keep in mind before any of this works: you need a Basescan API key, and it needs to be stored in your dot env file under the name BASESCAN underscore API underscore KEY. At NZRT, you’ll find the API key stored under ITE slash Blockchain slash Etherscan in the credentials system — so check there first before going looking elsewhere.

Once your contract is verified, Basescan becomes a really powerful inspection tool. There are six key things you can check, and knowing where to find each one will save you a lot of time. First, to confirm a contract is actually verified, you go to the Contract tab and look for a green checkmark — that’s your confirmation. Second, if you want to read data from the contract, you go to Contract and then Read Contract — this shows you all the view functions and lets you call them directly from the browser without spending any gas. Third, if you need to interact with state-changing functions, you go to Contract and then Write Contract — this is where you can call functions that modify the blockchain state, and you’ll need a connected wallet to do it. Fourth, to see who holds tokens associated with the contract, you go to Token and then Holders. Fifth, for a full history of every transaction that’s touched the contract, you check the Transactions tab. And sixth, if you want to see event logs — things the contract has emitted during its lifetime — you go to the Events tab.

Those six checks cover the vast majority of what you’ll need day to day when monitoring or debugging a deployed contract. Whether you’re confirming a deployment went through, checking that a function returned the right value, or auditing token distribution, Basescan puts all of that in one place.

If you want to dig deeper into the workflow around deploying and verifying contracts, the related topics to look up in the wiki are Hardhat and Contract Verification — those will give you the full picture of the development and deployment pipeline that feeds into what you’ve heard today.

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

000BCH, 01 - Core Concepts

Gas Transactions

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.

000BCH, 04 - Wallets & Signers

Gnosis Safe Multisig

Welcome to the NZRT Wiki Podcast. Today we’re looking at Gnosis Safe Multisig.

If you’ve ever worried about a single person holding the keys to a smart contract, this is exactly the kind of setup that solves that problem. NZRT uses what’s called a 2-of-3 Gnosis Safe multisig as the owner of its smart contracts on Base. What that means in plain terms is that there are three authorised signers, and any admin transaction on the contract requires at least two of those three people to approve it before anything actually happens.

So why does NZRT use multisig in the first place? There are four solid reasons. First, it eliminates a single point of failure. If one wallet key gets compromised, that alone isn’t enough to drain or control the contract — you’d still need a second signer to go along with it. Second, for serious mainnet contract ownership, multisig isn’t just a nice-to-have — it’s expected. Third, every transaction goes through Basescan, so there’s a full audit trail of anything that happens. And fourth, this is simply standard practice across professional DeFi and token projects. If you’re building something that matters, you use multisig.

Now let’s look at how NZRT’s Safe is actually configured. There are five key properties to know. The type is a 2-of-3 multisig. The network is Base Sepolia, which is the testnet environment. The threshold is two signers required per transaction. There are three owner addresses in total, and those are documented separately in the safe-signers reference file. And the interface you use to interact with all of this is app.safe.global.

So how do you actually use the Safe to perform a contract admin action? The workflow has seven steps. You start by going to app.safe.global. Then you connect using one of the three signer wallets — the setup assumes you’re using MetaMask. Once you’re in, you select the NZRT Safe on the Base Sepolia network. From there you create a new transaction and choose the Contract Interaction option. You enter the contract address and specify the function you want to call. The first signer confirms it, and at that point the transaction is queued but not yet live. When the second signer confirms it, the transaction actually executes on-chain.

Now there’s one important step that happens right after testnet deployment, and that’s transferring ownership of the contract to the Safe. The wiki includes a code snippet for this in a Hardhat script. In plain terms, what it does is look up your already-deployed token contract by its address, and then calls a function on it called transferOwnership, passing in your Gnosis Safe’s address. After that call goes through, the Safe — not any individual wallet — is the owner of that contract. That’s the moment when the multisig protection actually kicks in for real.

If you want to go deeper on any of the surrounding topics, the wiki also links out to MetaMask Setup, Key Management, and Smart Contract Security. Those are your next stops for understanding the full picture of how NZRT manages blockchain security.

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

000BCH, 02 - Development Tools

Hardhat

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

Hardhat is the development environment NZRT uses for compiling, testing, and deploying Solidity smart contracts to the Base network. If you’re working on blockchain development here, Hardhat is your main toolkit, and this episode will walk you through how it’s set up and used.

Let’s start with installation. The setup code block shows you a sequence of commands to get a new project going. You start by creating a new folder for your contract project and moving into it. Then you initialise a Node package, which sets up your project’s dependency management. After that you install Hardhat itself as a development dependency. Once that’s done, you run Hardhat’s init command and choose the JavaScript project option when it prompts you. Finally, you install two more packages — the Hardhat Toolbox, which bundles together a set of useful plugins, and the OpenZeppelin Contracts library, which gives you access to audited, battle-tested contract templates. That’s your full starting point — five steps and you’re ready to go.

Now let’s talk about how a Hardhat project is organised. The project structure block lays out five key locations. First, there’s a folder called contracts, which is where all your Solidity source files live. Second, there’s a scripts folder — this is where your deployment scripts go. Third, a test folder holds your test files, written using the Mocha and Chai testing frameworks. Fourth, a file called hardhat.config.js is your central configuration file — it handles network settings and plugins. And fifth, a dot-env file is where you store your private keys and API keys. That last one is critical — you never commit that file to version control. Keep it local and keep it secret.

The next section covers the Hardhat config file set up specifically for the Base network, and this is where things get a bit more detailed. The config file shown in the wiki does a few things. It pulls in the Hardhat Toolbox and the dotenv library, which lets you read those environment variables from your dot-env file. It then defines your Solidity compiler version as 0.8.20. After that it sets up two networks. The first is Base Sepolia, which is the testnet — it uses a chain ID of 84532 and pulls its RPC URL and your wallet’s private key from environment variables. The second is Base Mainnet, the live network, which uses chain ID 8453 and works the same way. On top of that, the config sets up contract verification through Basescan — again for both networks. For Base Sepolia, it points to the Sepolia-specific Basescan API and browser URLs. For Base Mainnet, it points to the standard Basescan URLs. Both read your Basescan API key from an environment variable. This setup means you can switch between testnet and mainnet deployments just by changing one flag in your command, without ever hardcoding sensitive credentials into your config.

Speaking of commands, let’s go through what’s in the common commands section. There are six you’ll reach for regularly. The first is the compile command, which processes your Solidity files and checks them for errors. The second is the test command, which runs your full test suite. The third starts a local network on your machine, useful for rapid development and iteration without touching any real or test network. The fourth and fifth are your deployment commands — you run the same deploy script but point it at either Base Sepolia or Base Mainnet by passing the network name as a flag. And the sixth is the verify command, which submits your deployed contract’s source code to Basescan so that anyone can inspect it. When you run verify, you pass the network, the deployed contract address, and any constructor arguments your contract was initialised with.

One thing worth noting from the wiki — the full NZRT-specific deployment guide lives in the ITE Blockchain section under Hardhat. If you’re doing an actual production deployment and want the NZRT-specific steps and conventions, that’s where to go. The wiki page you’re listening to now is the overview and reference — the deeper guide covers the full process end to end.

Related topics in the wiki include Alchemy, which is the RPC provider you saw referenced in the config file, and the Contract Deployment guide which covers the broader deployment workflow.

To summarise: Hardhat gives you a complete local environment for Solidity development. You install it with npm, organise your work across contracts, scripts, and test folders, configure your networks in the config file using environment variables for security, and then use a small set of commands to compile, test, deploy, and verify your contracts on Base.

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

000BCH

Iteasel Safe Multisig Signer Wallets

**Security flag — dropping caveman for this.**

The source document contains live private keys and mnemonic seed phrases. The document’s own header warns: *”Never commit this file to git”* and *”Delete this file from your computer once you have saved the keys safely.”*

A podcast script is a shareable, recordable artifact. Including those values — even paraphrased — defeats the warning entirely. The script below describes the *structure and purpose* of the credentials without reproducing any actual key values or seed phrases. Confirm this is the intent before distributing.

—

Welcome to the NZRT Wiki Podcast. Today we’re looking at Iteasel Safe Multisig — Signer Wallets.

If you’re working on the Iteasel project, this is one of the most security-sensitive pieces of documentation you’ll come across. Let’s walk through what it covers and what you need to know.

First, the big picture. Iteasel uses a Gnosis Safe multisig wallet. That’s a type of smart contract wallet on the blockchain that requires more than one person to sign off before any transaction goes through. Think of it like a joint bank account where you need multiple signatures before money can move.

The specific setup here is a two-of-three configuration. Three wallets are registered as authorised signers, but any two of them working together is enough to approve a transaction. You don’t need all three — just any two. This protects against a single point of failure. If one signer’s wallet is lost or compromised, funds can’t be moved unilaterally, but the other two can still operate the safe together.

Now let’s look at the three signers. The first is called the Deployer wallet. This is an existing wallet, and its private key is already stored in the deployment environment file, so you don’t need to manage it separately through this document.

The second and third signers were freshly generated for this setup. Each one has three pieces of information associated with it: a public wallet address, a private key, and a mnemonic seed phrase. The public address is safe to share — it’s just how the blockchain identifies that wallet. The private key and the mnemonic, however, are extremely sensitive. Whoever holds either of those has full control of that wallet. These must be stored securely offline — in a password manager or on a hardware wallet — and this file should be deleted from your machine once you’ve saved the credentials safely. Never commit this file to a git repository.

To import either of these generated wallets into MetaMask, you can use the private key or the mnemonic seed phrase — both work, and they represent exactly the same wallet. On testnet, using a software wallet like MetaMask is acceptable for development. But the documentation is explicit on one point: when you move to mainnet, you must use a hardware wallet, such as a Ledger or Trezor. Do not reuse the testnet keys on mainnet. Generate fresh keys on a hardware device instead.

On the network side, this Safe is configured for two environments. Testing happens on Base Sepolia, which is the test network for the Base blockchain. Production will run on Base Mainnet.

So here’s a quick summary of what you need to remember. You have a two-of-three multisig safe, meaning any two of the three signers can approve transactions. The first signer’s key is already in your deployment config. The second and third are newly generated and need to be imported manually. The safe runs on Base Sepolia for testing and Base Mainnet for production. And all private keys and seed phrases must be stored offline and securely — never in version control, never in a shared document, never in a podcast script.

If you’re setting this up for the first time, your action items are: save the private keys and mnemonics to a secure offline store, import the wallets into MetaMask using those credentials, create the Safe on the relevant network with all three signer addresses and the two-of-three threshold configured, and then delete the credentials file from your local machine.

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

000BCH, 04 - Wallets & Signers

Key Management

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

If you work anywhere near NZRT’s blockchain operations, whether that’s on testnet, mainnet, or anything involving Gnosis Safe, understanding how we handle keys is essential. This episode walks you through our key inventory, the rules we follow, and how we keep sensitive credentials out of places they should never be.

Let’s start with what keys we actually have in play. There are four main entries in our key inventory, and each one has a specific job.

First, you have the MetaMask deployer key for testnet. Its purpose is testnet deployments only, and it’s stored as a seed phrase in the ITE Blockchain folder under MM-Seed. Second, there are the Gnosis Safe signers, numbered one through three. These are used for contract ownership through a multisig setup, and what’s stored for them in the ITE Blockchain safe-signers folder is addresses only, not the keys themselves. Third, you have the Alchemy API key. This one handles RPC access and lives in the ITE Blockchain Alchemy location. And fourth, there’s the Basescan API key, used for contract verification, stored in the ITE Blockchain Etherscan location.

So that’s your four main keys: a testnet deployer seed phrase, Gnosis Safe signer addresses, an Alchemy API key, and a Basescan API key. Each has a clear purpose and a designated home.

Now let’s talk about the rules. There are five of them, and each one exists for a concrete reason.

Rule one: never commit a dot-env file to Git. The reason is straightforward. If a dot-env file ends up in a repository, even a private one, you’ve potentially exposed your keys to anyone who can access that repo, now or in the future. We’ll come back to how we prevent this in a moment.

Rule two: testnet keys and mainnet keys must stay completely separate. Testnet key exposure is considered low risk because there’s no real money on the line. Mainnet exposure is a different story entirely. Do not mix them.

Rule three: seed phrases are stored offline or encrypted. This protects them against digital compromise. If it’s online and unencrypted, it’s a target.

Rule four: for mainnet, you should always use a hardware wallet or a multisig setup like Gnosis Safe. The reason is that a single externally owned account is a single point of failure. If that one key is compromised, you lose everything it controls.

Rule five: rotate API keys if they’re ever exposed. Both Alchemy and Basescan allow you to regenerate keys, so if something leaks, you can replace it. That’s your safety valve for those two.

Now, how does this look in practice? We use a dot-env file to hold sensitive values locally during development. The file contains four values. There’s a private key placeholder for the testnet deployer. There are two Alchemy URL placeholders, one for Base Mainnet and one for Base Sepolia, both of which include a key segment you replace with your actual key. And there’s a Basescan API key placeholder. The file is clearly labelled at the top as something that must never be committed.

To make sure that file never accidentally ends up in version control, you also maintain a dot-gitignore file. That file tells Git to ignore anything named dot-env, as well as any variation of dot-env with a suffix, so dot-env-dot-local, dot-env-dot-production, and so on are all excluded automatically. That two-line gitignore entry is your last line of defence against accidental exposure.

To tie it all together: you keep a clear inventory of what keys exist and where they live. You follow five rules covering git hygiene, key separation, offline storage, mainnet safety, and key rotation. And you use a dot-env file locally with gitignore protection to make sure credentials never travel further than your own machine.

If you want to go deeper, the related topics on this wiki are Key Security, Gnosis Safe Multisig, and Wallets and Keys, each of which expand on different aspects of what we’ve covered here.

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

000BCH, 04 - Wallets & Signers

Metamask Setup

Welcome to the NZRT Wiki Podcast. Today we’re looking at MetaMask Setup.

MetaMask is NZRT’s browser-based crypto wallet, and it plays a specific role in the blockchain workflow — it’s used for testnet deployment and transaction signing. If you’re working on anything in the ITE or blockchain space, this is the tool you’ll need to get familiar with.

Let’s start with installation. Head over to metamask.io and install the MetaMask browser extension. Once that’s done, you’re not going to be creating a brand new wallet. Instead, you’ll be importing an existing one using a seed phrase. That seed phrase is stored securely in the vault under ITE, then Blockchain, then MM-Seed. Retrieve that phrase, use it to import the wallet, and you’re ready to move on to network configuration.

MetaMask doesn’t include the Base network out of the box, so you’ll probably need to add it manually. That said, it’s worth checking Settings, then Networks first, because MetaMask sometimes detects and auto-adds Base for you. Save yourself a step if it’s already there.

There are two Base networks to set up. The first is Base Mainnet. When you go to add a custom network in MetaMask, you’ll be filling in five fields. The network name is Base. The RPC URL is the mainnet.base.org address using HTTPS. The Chain ID is 8453. The currency symbol is ETH. And the block explorer URL is basescan.org, also using HTTPS.

The second network is Base Sepolia, which is the testnet environment. Same process, just different values. The network name is Base Sepolia. The RPC URL is sepolia.base.org using HTTPS. The Chain ID is 84532 — that’s eight, four, five, three, two. The currency symbol is still ETH. And the block explorer is sepolia.basescan.org using HTTPS.

With your networks in place, you may also need to export your private key, particularly when you’re working with Hardhat for smart contract deployment. To do that, open MetaMask, go to your Account, click the three-dot menu, then select Account Details, and choose Show Private Key. Copy that value and paste it into your dot-env file, using PRIVATE underscore KEY as the variable name, with the key value prefixed by zero x. And here’s a rule with no exceptions: never commit that dot-env file to Git. Your private key must stay out of version control at all times.

Now for security, and this part really matters. This MetaMask wallet is a testnet deployer only. You should never send mainnet funds to it. When you need to operate on mainnet, that goes through Gnosis Safe, which is NZRT’s multisig setup for production use. As for the seed phrase, it’s stored offline — the full details are in the Key Security documentation in the vault.

If you want to go deeper on any of this, there are three related pages in the wiki worth reading: Gnosis Safe Multisig, Wallets and Keys, and Key Security. Between those three and this guide, you’ll have a solid picture of how NZRT manages its blockchain signing infrastructure.

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

00 - Overview, 000BCH

Nzrt Blockchain Architecture

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Blockchain Architecture.

If you’re working at NZRT or just trying to understand how the blockchain side of things is put together, this episode gives you a clear picture of the full stack, from where code gets written all the way through to live tokens on the blockchain.

Let’s start with the big picture. The architecture shows a pipeline that flows from development tools down through testing environments and into production. At the top you’ve got Hardhat, which is the development framework the team uses to write and test smart contracts locally. From there, code can be deployed to a local test network running on your own machine, then out to Base Sepolia which is a public testnet, and finally all the way to Base Mainnet, the live production blockchain where real tokens exist. Connecting the smart contracts to the outside world is Alchemy, which acts as the RPC provider, essentially the communication layer between your application and the blockchain network. The primary smart contract right now is the ITSL Token, which follows the ERC-20 standard. There are also future contracts planned for things like staking, vesting, and governance. Sitting above all of this is a Gnosis Safe multisig wallet that acts as the contract owner and administrator. And everything is publicly visible and verifiable on Basescan, which hosts the contract verification and the public ABI.

Now let’s walk through the three deployment environments. The first is your local development environment. This runs on the Hardhat Network with a Chain ID of 31337 and connects to your own machine. This is where you do fast iteration, testing changes quickly without spending any real money or waiting on a network. The second environment is the testnet. This connects to Base Sepolia with a Chain ID of 84532 and uses Alchemy as the RPC provider. This is where you test your contracts in a realistic network environment before going anywhere near real funds. The third and final environment is production, Base Mainnet with Chain ID 8453, also running through Alchemy. This is the live network where the ITSL token actually exists and operates.

Next, let’s look at how contract ownership is structured. There are three roles to understand. The contract owner role is held by a Gnosis Safe wallet, operating as a two-of-three multisig, meaning you need at least two out of three authorised signers to approve any administrative action. This is an important security measure for a live token. The deployer role for testnet is a standard MetaMask externally owned account, used for testnet only. And for mainnet deployment, the Gnosis Safe itself acts as the deployer, so even the initial deployment of a production contract requires that multisig approval.

Now for the star of the show, the ITSL Token itself. This is an ERC-20 token, the most widely used token standard on Ethereum-compatible blockchains. It’s built on top of OpenZeppelin’s ERC20 base contract, an industry-standard audited library that gives you safe and reliable token functionality out of the box. The token lives on Base Mainnet, carries the symbol ITSL, and uses 18 decimal places, which is standard for ERC-20 tokens and allows one token to be divided into incredibly small fractions for precise transactions. The total supply is defined separately in the tokenomics documentation, so the contract itself stays flexible on that front.

To tie it all together, you’ve got a clean layered architecture. Development starts locally with Hardhat, gets validated on Base Sepolia testnet, and graduates to Base Mainnet for production. Alchemy handles the RPC connectivity throughout. The ITSL ERC-20 token is the current live contract, secured by a Gnosis Safe multisig for all ownership and admin actions. And Basescan provides public transparency for anyone who wants to verify the contract code.

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

000BCH, 02 - Development Tools

Openzeppelin

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

If you’ve been following NZRT’s blockchain work, you’ve probably heard the name OpenZeppelin come up. So let’s break down what it actually is and how we use it.

OpenZeppelin is a library of smart contracts written in Solidity, the programming language used to build on Ethereum and compatible blockchains. The key word here is battle-tested. These contracts have been audited, reviewed by thousands of developers, and used in production across the industry. At NZRT, we use OpenZeppelin as the foundation for our ITSL ERC-20 token.

Let’s start with getting it into your project. Installation is a single command — you’re essentially telling your Node project to pull in the OpenZeppelin contracts package. Once that’s done, you have access to the full library.

Now let’s talk about which contracts NZRT actually uses, because there are quite a few to choose from.

There are six key contracts worth knowing. First, ERC20 — this is the standard fungible token contract and it forms the base of the ITSL token. Second, Ownable, which gives a contract a single designated owner and a special modifier that restricts certain functions so only that owner can call them. Third, AccessControl — a more flexible alternative to Ownable. Instead of a single owner, it lets you define roles and assign permissions to multiple addresses. Fourth, Pausable, which is essentially an emergency stop button for your contract. If something goes wrong, you can pause all activity. Fifth, ERC20Burnable, which adds the ability to permanently destroy tokens, reducing the total supply. And sixth, ERC20Capped, which lets you set a hard maximum on how many tokens can ever exist.

Next, let’s look at how you bring these into your Solidity code. You’ll see five import statements, each one pointing into the OpenZeppelin contracts package. You’re pulling in the base ERC20 contract, the Burnable extension, the Capped extension, the Ownable access contract, and the Pausable utility. Think of these as building blocks you snap together before writing your own logic on top.

Now for the ITSL token itself — this is where it all comes together. The token contract is called ITSLToken, and it inherits from three of those building blocks: ERC20 for standard token behaviour, ERC20Burnable to allow burning, and Ownable to lock down admin functions to a single owner. Inside the constructor — the function that runs once when the contract is first deployed — you set the token’s full name as Iteasel Token, its ticker symbol as ITSL, and assign ownership to whoever deploys the contract. Then you mint the initial supply. The amount is calculated by taking the initial supply number and multiplying it by ten to the power of the token’s decimal places. This is standard practice in Solidity, since the language doesn’t support floating point numbers, so decimal precision has to be handled explicitly like this.

One more tool worth knowing about is the OpenZeppelin Contract Wizard. It’s a web-based interface where you tick checkboxes for the features you want — mintable, burnable, pausable, capped, and so on — and it generates clean, ready-to-use Solidity code. It’s a great starting point when you’re prototyping. You take the output, drop it into your project, and adjust from there rather than starting from scratch.

If you want to go deeper after this episode, the related topics to explore are Smart Contracts, ERC-20 Tokens, and the ITSL Token page in the wiki.

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

000BCH, 06 - Security

Smart Contract Security

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.

000BCH, 06 - Security

Key Security

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.

000BCH, 01 - Core Concepts

Smart Contracts

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.

000BCH, 01 - Core Concepts

Wallets Keys

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.