Imagine you were developing the following smart contract:

The contract implements a simple token for storing and transferring assets between users. It is written in the Solidity programming language and conforms to the widely-used ERC20 API.

During development, you obviously made sure to address all warnings or issues that were reported by the compiler. On top of that, you also ran our MythX analysis service and addressed all the issues it detected.

Since there are no more issues, the contract should be ready for deployment, right? Well, not quite… How can you be sure it actually does what it is supposed to do? There are a few common techniques to answer that question: for instance, you might want to write tests that exercise different usage scenarios or even hire auditors (such as our friends at ConsenSys Diligence) to make sure you did not miss something.

Most automated tools try to detect generic issues, such as reentancy or arithmetic overflows. However, to check custom properties about the intended behavior of a specific contract (often referred to as “functional correctness properties”), tools need some help. For instance, it would be great if the developer or an auditor could provide some description of what is considered “intended behavior” and the tool would report any unintended behavior as issues. If you are using MythX you can do this out-of-the-box, provided you have some properties in mind that you want to check.

For example, the transfer function should never change the sum of the two balances for msg.sender and _to . We can easily add a runtime check for such a property by adding the transferEnsures modifier to the transfer function:

We can see that the modifier stores the sum before entering the body of the transfer function in a local variable. After executing the body ( _ placeholder) it checks the above property by emitting a special AssertionFailed(string) event in case it is violated. MythX will report paths to the AssertionFailed(string) event as a vulnerability. While MythX will also report violations of built-in assert-statements, the above approach allows you to specify a nice message that helps with understanding the tool’s warnings and, if necessary, mapping them to locations in the source code.

After making these minor changes to the contract, we can perform another MythX scan: