Tag Archives: blockchain

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.

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.