Smart contract audit competitions such as Sherlock or Code4rena can be lucrative, but they are increasingly competitive.

Finding a vulnerability and getting a prize can be difficult. In this article I will outline some strategies to help.

This article is just a brief introduction to the area, to find out more check out or training below.

We can categorise the types of exploits as follows

• General software bugs

  • logic errors

  • DOS

• Solidity / EVM specific

  • Re entrancy

  • Upgradability

  • MEV

• General Security

  • Access control

  • Key compromise / loss

• Economic

  • Price manipulation (Oracle manipulation)

  • Slippage

• Governance

• Development lifecycle issues / best practices

Most exploits (about 80 %) are economic, other common types are access control.

In order to stand out from the other auditors, you should aim to find a niche area.

For example in a recent audit, of about 1000 issues submitted, about 20% were a slippage issue, which while valid, is easy to spot, and therefore will be found by many of your competitors.

If you can find exploits in a niche area, you are more likely to get a bounty, so concentrate on less well known or complex areas such as cryptography, assembly, or more complex economics.

Although every contract is different, there is a common approach that can be taken.

I would ask the following questions for every project, and maybe each contract if appropriate.

1. What are the entry points to the contract

2. Are there interactions with other contracts

3. Is there access control ? If so

   1. What are the roles

   2. Do any accounts have multiple roles ?

   3. How do these map to users

   4. How is the access control configuration changed ?

4. What are the major functional pathways through the contract ?

5. Are funds held in, or controlled by the contract ?

6. From the use case perspective, what assumptions are we making about the inputs for the 'happy path' ?

7. What represents a 'bad state' for the contract ?

I would then look for any of the following items.

• Upgradability

• Access control

• Complex arithmetic

• Casting between datatypes

• Error handling

• Use of assembly

• Non-standard patterns

• Not using standard libraries when available

• Modifying standard libraries

• Dead code / TODOs

These areas are often implemented poorly by developers, and are therefore more likely to provide issues.Estimating severity

In competitions there will be guidelines to follow, don’t be tempted to increase the severity of the issues you find.

• Slither

• Halmos

• Solc SMT Checker

• Foundry

• Ziion

• Solidity Metrics

The most important tool is your attitude, an adversarial, questioning approach to the contracts should be taken.

In addition to entering competitions, you may take on audits for clients, in which case you will need to raise your profile as an auditor.

To achieve this

• Show completed audits

• Show understanding of protocols (write articles)

• Write post mortem of exploits

• Do open source work for projects / volunteer for audit teams

• In competitions concentrate on niche bugs

We run a course for potential auditors to give them the skills they need for competitions or solo audits. The next cohort starts on July 8th.

For more details and a place, apply here

At Extropy we have been auditing projects since 2017, please contact us if you would like an audit, or audit training.

Our security website has more details