# Preparing for audit competitions

**Published by:** [Extropy](https://paragraph.com/@extropy/)
**Published on:** 2023-06-17
**URL:** https://paragraph.com/@extropy/preparing-for-audit-competitions

## Content

Smart contract audit competitions such as Sherlock or Code4rena can be lucrative, but they are increasingly competitive.Code4rena BountiesFinding 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.Taxonomy of exploitsWe can categorise the types of exploits as followsGeneral software bugslogic errorsDOSSolidity / EVM specificRe entrancyUpgradabilityMEVGeneral SecurityAccess controlKey compromise / lossEconomicPrice manipulation (Oracle manipulation)SlippageGovernanceDevelopment lifecycle issues / best practicesMost exploits (about 80 %) are economic, other common types are access control.Finding your nicheIn 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.Code inspection - a general approachAlthough 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.What are the entry points to the contractAre there interactions with other contractsIs there access control ? If soWhat are the rolesDo any accounts have multiple roles ?How do these map to usersHow is the access control configuration changed ?What are the major functional pathways through the contract ?Are funds held in, or controlled by the contract ?From the use case perspective, what assumptions are we making about the inputs for the 'happy path' ?What represents a 'bad state' for the contract ?I would then look for any of the following items.UpgradabilityAccess controlComplex arithmeticCasting between datatypesError handlingUse of assemblyNon-standard patternsNot using standard libraries when availableModifying standard librariesDead code / TODOsThese 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.Useful toolsStatic Analysis / Symbolic Execution tools / IDEsSlitherHalmosSolc SMT CheckerFoundryToolsets / pluginsZiionSolidity MetricsThe most important tool is your attitude, an adversarial, questioning approach to the contracts should be taken.Solo auditsIn 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 thisShow completed auditsShow understanding of protocols (write articles)Write post mortem of exploitsDo open source work for projects / volunteer for audit teamsIn competitions concentrate on niche bugsTrainingWe 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 detailsSubscribe

## Publication Information

- [Extropy](https://paragraph.com/@extropy/): Publication homepage
- [All Posts](https://paragraph.com/@extropy/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@extropy): Subscribe to updates
- [Twitter](https://twitter.com/extropyLaurence): Follow on Twitter