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.

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.

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.

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.