Mike Pumphrey
Jun 21 · 3 min read

We talk a lot here on the MythX team about the importance of regular, routine analysis of your smart contracts prior to deployment onto the blockchain.

The reason for this is simple: once the contract is deployed, it is immutable. Any vulnerability in your code that you deployed will be there forever.

In this way, you can think of contracts on the blockchain like embedded systems. Once the widget is sent out of the factory, it will always do whatever it was programmed to do. Forever.

(Which, incidentally, is why we should probably be slightly concerned about the Year 2038 problem. Yikes!)

Before and during

Our prescription is easily told: we recommend using MythX through every stage of the smart contract development life-cycle.

We also highly recommend a manual audit before you deploy, to find the business logic errors that an automated tool can’t detect. (We might be biased, but we can’t say enough good things about the team of auditors at ConsenSys Diligence.)

But all of that happens before deployment. What about after deployment? Can you just kick back and wash your hands of the whole security thing?

Unfortunately, no.

Why is this? Because new vulnerabilities are being discovered.

For example, we help to maintain the Smart Contract Weakness Registry, a list of the most common vulnerabilities in smart contracts. We believe it to be comprehensive, but it is a living document (it’s on GitHub after all), and we expect new vulnerabilities to be added to this list in time.

SWC Registry


In short, what is deemed secure today is not guaranteed to be secure tomorrow.

That is why we recommend doing regular security scans of contracts after they are deployed too.

Thankfully, we’ve got help in this realm. Our friends at Amberdata are using MythX to scan every single contract on mainnet. Every. Single. One. Go see for yourself.

They also have this fun little section called the Wall of Sheep. While it’s a cute page, it’s detailing the most vulnerable contracts on the entire blockchain, so keep your distance from those sheep.


In addition to Amberdata:

If one of these integrations doesn’t suit your fancy, we encourage you to build your own (there’s revenue in it for you if others use it, too).

So what happens when a new vulnerability is found and you are affected?

Because the contract itself is immutable, you’ll need to deploy a new contract, and point people to use the new one instead of the old one. There’s not much else one can do around that.

But with MythX, at least you’ll be prepared, and not be under the illusion that what is deemed secure today will be deemed secure always.

And beyond

We’re constantly improving our algorithms too. The complex interplay between our microservices, Harvey, Maru, and Mythril, can lead to uncovering lots of potential vulnerabilities, and we’re exploring ways to find even more deeply hidden secrets.

MythX is a vital tool in your development toolbox, and that extends beyond the deployment stage. Your work isn’t ever really done, but luckily, neither is ours.

ConsenSys Diligence

ConsenSys Diligence has the mission of solving Ethereum smart contract security. Contact us for an audit at diligence@consensys.net.

Thanks to Bernhard Mueller

Mike Pumphrey

Written by

Mike Pumphrey is Marketing and Brand Manager at ConsenSys working on the MythX team, a division of ConsenSys Diligence.

ConsenSys Diligence

ConsenSys Diligence has the mission of solving Ethereum smart contract security. Contact us for an audit at diligence@consensys.net.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade