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.

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.

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.