Why You Should Never Test Exploits on Mainnet or Public Testnets

Not everyone who moves from the Web2 security world into the Web3 space is aware of the most important, fundamental rule about blockchain hacking: never test your proof of concept (PoC) exploit on mainnet or public testnets.

But why? What’s the reason for the rule?

All transactions you make on mainnet or public testnet are visible to everyone. This is because transactions are broadcast to all nodes and can be viewed through a block explorer, or by bots.

This means that somebody can view, study, and copy your moves, possibly discovering the vulnerability you were researching, and use it to exploit a project for real financial damage.

This is different from hacking on a web security level, because your web traffic activity from your session can be obscured, and you won’t be “declaring” it to the world, like how you would on a public blockchain.

Moreover, testing on the mainnet holds even greater dangers. If the protocol is live, you could cause serious damage, even if what you meant to do seems harmless. There are so many moving parts and interlinked components of smart contracts that it becomes impossible to predict the exact consequences of your actions.

And in the worst case, a blackhat can catch on to what you’re doing and take advantage of the bug before the protocol has time to fix it. Here’s one horror story of a whitehat who watched this happen in real time.

In fact, testing on mainnet or public testnet is so dangerous that we will automatically and permanently ban anyone who does so from the Immunefi platform.

We’ve already banned one hacker for testing a PoC on mainnet. Thankfully, there was no serious damage or loss of funds, but the ban still stands because of how harmful the activity is.

And so you are caught in a dilemma. Because, as a whitehat hacker, there are times where you simply have to test an exploit before you submit a bug report, especially if it’s for a critical bounty. How else would you convince a protocol that there are significant funds at risk?

But there is always another way. Thanks to the openness of blockchain technology, most, if not all contracts can be found on the project’s Github and forked onto your own machine — where you can safely investigate with a locally hosted blockchain. Importantly, with a locally hosted blockchain, no one else can see what you’re doing, and the PoCs don’t affect the live project.

In the best case, you would also do well to avoid using ‘managed’ development environments like Tenderly or Infura, as you never know who could be watching.

How do I know if I am at risk of breaking this rule?

This is pretty simple. Just run the following checks:

• Check if you are testing on mainnet (i.e. is my current environment the live production of the network I’m testing?)
• Check if you are on a public testnet (i.e. is my current environment a test environment, but one that can be accessed by anyone else?)
• Check if you are in a managed blockchain environment, where a third party (who might be compromised) can monitor what is going on (i.e. is the data stored in servers owned by another company, who might have privileged access to data that should otherwise be encrypted?)

How to do testing on private testnets.

There are step-by-step guides that show you the process of setting up a local blockchain testing environment in order to test exploits.

There are quite a few tools on the market for this purpose, but we’ll discuss two of these tools (Remix and Hardhat) briefly.

Remix

Remix is an IDE (Integrated Development Environment) for Ethereum-based smart contracts. In other words, it’s a one-stop-shop solution for developing and testing your smart contract.

Plus, it’s free and open source. There is both a desktop and a browser version available.

You can read their documentation here.

There are also video tutorials on how to get started.

When using the browser version, ensure that your testing activities are kept private, by setting your environment to ‘VM’ or ‘Virtual Machine’. This means that all of your transactions will be executed in a sandbox blockchain in the browser, which is locally hosted.

A key feature is that this virtual machine blockchain lives in your browser and does not persist. If you happen to close your browser by accident, or refresh your page, it wipes the slate clean and you’ll have to start again.

If you are running the desktop version of Remix, you’ll need to run your own Geth client or use a Hardhat integration to run private testing. If running your own Geth client, make sure you take proper precautions to prevent others from accessing your node using dev mode.

Hardhat

Hardhat is another tool you can use for writing and testing smart contracts on a local blockchain environment to try stuff out. This is called the Hardhat network:

Simply put, it’s a simulated Ethereum chain that lives on your computer. But one key difference from the previous ‘Remix VM’ method is that this network won’t wipe clean until you shut it down manually. This could be useful if you need the network to persist even if you close or restart your browser.

And unlike Remix, you don’t need to select an environment. As long as you’re running Hardhat, you’re already using your own local Hardhat Node, so no need to worry about your transactions being seen by others.

Here are some helpful links and guides to get you all set up:

• Hardhat — Official Tutorial
• Hardhat — Official Documentation & Overview
• Immunefi — A Guide to Reproducing Ethereum Exploits: Fei Protocol

There are also some great video tutorials on youtube for using Hardhat. No, not this one… but like this one.

In closing, keep your testing activity from prying eyes by using a local node like Hardhat or your own locked-down Geth client, and supplement those with your own privacy best practices, in order to keep on whitehacking with peace of mind.

🔒 For more guides on how to secure smart contracts, analysis of past hacks, and information on the latest bounties, make sure you follow us on Twitter or join our whitehat Discord community.

P.S. Hackers subscribed to our newsletter are 35.8% more likely to earn a bug bounty. Click here to sign up.