Building on Ethereum Mainnet - An Opinionated Guide

It's 2022. Quantitative easing in response to the covid-19 economic fallout has resulted in a cobra effect. The whole world has plunged into the worse recession yet. Traditional finance is gone, while Ethereum is the only glimmer of hope for the new fintech revolution – One that can save the world from this economic nightmare.

Enter: you. You are a talented and aspiring developer who wants to create the next revolutionary financial application that will help save us all and restore peace. You know that your application needs to interact with established protocols on Mainnet such as Uniswap (Exchange), Compound/Aave (Borrowing/Lending), Nexus Mutual (Insurance), etc. You want to build it now and you want it fast.

The only problem is, you don't know where to start, and you have many questions:

Well, lucky for you dear aspiring developer, I've wasted invested the last 8 months of my life into this very niche area, and have prepared this article specifically for people like yourself.

Disclaimer: This article is a very opinionated distillation of my experience.

Smart Contract Frameworks is the tool of choice if your goal is to ship quality code fast. I've also written a separate article on it, if you'd like a more in-depth dive.

However, if you would prefer to use other frameworks, I would recommend the following in no particular order:

Testing in a Sandbox Environment

For me, the most ergonomic testing setup I've found is by running my code against an EVM implementation instead of an actual testnet. That way I can test my logic without waiting for my transaction to be mined. This alone increases my iteration speed tremendously.

If you'd like to have deterministic tests (ones where it doesn't pass on Tuesday and fail on a Friday), I strongly recommend using It uses hevm behind the scenes, which is an EVM implementation in Haskell.

Using a VM written in Haskell as opposed to Python or JS provides stricter guarantees right off the bat. If something fails, its likely something to do with your code, not the VM implementation.

Other VM implementations includes

Protocol Interactions

I test in prod - Andre Cronje

Ignore all other networks such as Rinkeby, Kovan, or Goerli. Your only focus should be on Mainnet, network id 1. Its network id is 1 for a good reason - its the only 1 network you should care about.

Chances are, if you're interacting with multiple protocols such as OneInch, Curve, Uniswap, Aave, Compound, etc. Not all of them will be deployed to the same testnet. But there is a 100% chance that they'll be deployed on Mainnet. So if you want be spoiled for choice, make Mainnet your testnet.

On popular EVM implementations like hevm, buidler-evm, and ganache-cli, there is an option to “fork” from mainnet. Essentially what that means is that you can retrieve mainnet state (i.e. Liquidity on Uniswap) and run tests against that in your local, sandbox environment.

Confession: I use ganache-cli behind the scenes to cache data before sending it off to hevm. This reduces testing time significantly, especially if your tests interact with a ton of mainnet protocols

Debugging Failed Transactions

In Your Sandbox

If you're using, buidler, or brownie, congrats on this. Seriously. You have logging and stack traces built into the testing framework itself (-v for Debugging your contracts should be quick and simple.

hevm stacktrace

However, if you're using frameworks that uses ganache-cli behind the scenes. Have fun shooting yourself in the foot while placing random revert messages everywhere in order to figure out what went wrong.

*As several people have pointed out, there's a debugger for ganache-cli. I'm well aware of it and have used it, but ended up going back to revert messages due to the amount of time and effort it took.

On Mainnet

Wowee a transaction failed, on Mainnet? How can I debug that? and provides detailed stack traces regarding the specified transaction hash (I suspect it uses openethereum's debug_tracetransaction behind the scenes). stack trace example


Tl;dr: good.

Did I miss your favorite tool or got something wrong? Or do you think this article is just plain bs? Either way feel free to email me any of your complains or suggestions.