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.

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.