A Roundup of Typical Examples of Risks Discovered in Smart Contracts

In our previous article, we explained how Fairyproof classified issues or risks discovered in an audit report. Given readers might be…

In our previous article, we explained how Fairyproof classified issues or risks discovered in an audit report. Given readers might be curious about what risk is of critical-severity, high-severity, medium-severity, and low-severity and what a neutral suggestion would be, we are going to elucidate more on this topic.

In this article, we will give some examples for these categories of risk severities and elaborate on why these risks are marked as these severities and what Fairyproof would suggest the auditee do.

A risk of critical severity has the highest priority and should be fixed as soon as possible.

A typical risk of this kind is a syntax error in a smart contract. Syntax errors are errors that are usually caused by a violation of a smart contract language’s principles. A syntax error will cause a smart contract to fail in compilation and cannot be run at all.

In a Solidity implemented smart contract, errors such as incorrectly defining a variable, mismatch of compiler version, etc are of this kind. They should be fixed by the auditee immediately without any delay.

In the early days, Fairyproof would list risks of this kind in a report if they were discovered during an audit even if they were fixed by the auditee. But in the most recent audit reports risks of this kind were seldom listed if they were fixed after being discovered.

Risk of high severity has the second highest priority and will very likely bring problems and should be fixed.

A typical risk of this kind is an incorrect algorithm or inappropriate implementation etc.

For instance, as all known, yield farming is a popular DeFi application. Users can stake a specified crypto asset in a yield farming pool to earn profits. The number of profits a user can earn depend on the share of the user’s staked asset in the pool’s total staked assets. If the algorithm that is used to calculate the user’s share is incorrect, the user will not get his/her deserved profits.

If a risk of this kind is discovered, it will be marked as high-severity and Fairyproof will urge the auditee to fix it as soon as possible.

Risks of high severity are seldom listed in Fairyproof’s most recent audit reports as well since Fairyproof would urge the auditee to fix them as soon as possible once they were discovered.

An issue or risk of medium severity could potentially bring problems and should eventually be fixed.

A typical risk of this kind is an excessive admin right or inappropriate access control etc.

For instance, nearly every DeFi application issues its own governance token. When the governance token’s contract is deployed, the admin, in general, has full access control to all the token’s operations such as mint, burn,etc. To bootstrap its issuance, circulation, and application, such excessive admin rights are needed in a project’s early development. But as the project develops and grows, its functions will evolve and become increasingly complex. An admin with such excessive rights would expose the whole project to huge risks since if the admin’s private key is compromised, the whole project will be exposed to devastating damages.

For this risk Fairyproof would suggest the auditee should transfer the admin’s rights to a multi-sig wallet or a DAO to prevent the project from being exposed to this “single-point failure”.

An issue or risk of low severity is a minor detail or warning that can remain unfixed but would be better fixed at some point in the future.

A typical risk of this kind is a misleading variable name. A misleading variable name is one that doesn’t describe the variable’s behavior. It would cause difficulties for the code’s developers to maintain the code or even mislead the users.

For instance, when a developer intends to define a function to set a variable’s value, as a rule of thumb, the function would better be named as “setVariable”. However, if the function is named as “getVariable” it would be misleading and even cause users to be confused about its real behavior thus leading to unexpected operations.

For this risk, Fairyproof would still suggest the auditee should rename it and fix this issue whenever it’s convenient.

An issue of neutral severity is not an issue or risk but a suggestion for code improvement.

A typical suggestion of this kind is removing redundant code, variables,etc.

For instance, there are variables defined but never used in a smart contract. If these variables are discovered, Fairyproof would suggest the auditee remove them in a timely manner. But even if the auditee puts aside this suggestion, it wouldn’t cause risks to the project at all.

About the author:

Yuefei TAN, CEO of Fairyproof

About Fairyproof:

Fairyproof Tech is a blockchain security company, established in Jan 2021.

It was founded by a team with rich experience in smart contract programming and network security. The team members participated in initiating a number of draft standards in the Ethereum field, including ERC-1646, ERC-2569, ERC-2794, and EIP-3712, of which ERC-2569 was officially accepted by the Ethereum team.

The team participated in the launch and development of various Ethereum projects, including blockchain platforms, DAO organizations, on-chain data storage, decentralized exchanges, and conducted security audits of multiple projects which have been deployed on Ethereum. Based on its strong R&D capability and deep understanding of smart contract security, Fairyproof has developed comprehensive vulnerability tracking and security systems and tools.

Fairyproof Tech serves and works closely with customers by providing systematic solutions covering both “code vulnerabilities” and “logic vulnerabilities” and aims to provide customers with the best and most professional services.