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.