When looking for vulnerabilities in DeFi projects, or creating best practices to prevent them, it is vital to have a classification of attacks, so that we both apply prevention in the correct place, and know when we have sufficient coverage of the threat vectors. Given finite resources we need to direct our efforts appropriately.
The paper from Zhou et al gives us such a classification.
They divide the area into 4 layers, plus services which span the top 3 layers.
As a smart contract auditor and developer I am most concerned with the DeFi Protocol layer, and the Smart Contract layer, since recommendations in a project audit will be applied to those layers, with changes to the Blockchain or network out of scope.
That is not say that features at lower layers should not be taken into account, rather that given those features it is the responsibility of the higher layers to allow for those features and take precautions against any vulnerabilities that may result.
Following the classification from the paper I will now describe and give examples of some of the attacks at the DeFi protocol layer and the Smart Contract layer.
DeFi Protocol Layer Attacks
Front / Back running / Sandwich attacks need to be mitigated against with logic at the protocol layer.
A typical example is where a lack of slippage protection in a swap puts the protocol at risk of sandwich attacks.
There are protections against transaction replays at the blockchain level, but there could be similar structures at the protocol level, such as signed messages that could be replayed.
Incorrect Randomness source
Randomness in smart contracts is difficult to achieve safely, if done incorrectly it can be exploited by block producers.
A malicious contract may be called from a seemingly innocent contract
A project’s dependencies may be open to manipulation, for example