GNO Token v2.0.0 Audit Report

Our review focused on the v2.0.0 branch, specifically, commit hash 1cc6023ecd6494dd4e37591c4864bb487f1b0373.

Below is the summary of the GNO token v2.0.0 audit:

1. Smart Contract Auditing Service
   • Verilog Solutions team analyzed the entire project using a detailed-oriented approach to capture the fundamental logic and suggested improvements to the existing code. Details can be found under Findings & Improvement Suggestions

• Code Assessment
  • We evaluate the overall quality of the code and comments as well as the architecture of the repository.
  • We help the project dev team improve the overall quality of the repository by providing suggestions on refactorization to follow the best practice of Web3 software engineering.

• Code Logic Analysis
  • We dive into the data structures and algorithms in the repository and provide suggestions to improve the data structures and algorithms for the lower time and space complexities.
  • We analyze the hierarchy among multiple modules and the relations among the source code files in the repository and provide suggestions to improve the code architecture with better readability, reusability, and extensibility.

• Access Control Analysis
  • We perform a comprehensive assessment of the special roles of the project, including their authorities and privileges.
  • We provide suggestions regarding the best practice of privilege role management according to the standard operating procedures (SOP).

Our auditing for GNO Token v2.0.0 covered the following components

none ; )

none ; )

1. Unused components

   Severity	Low
   Source	@gnosis.pm/util-contracts/contracts/GnosisStandardToken.sol: L4 ; GnoDevDependencies.sol: L12;
   Status	Acknowledged

   • Description

     Proxy.sol has not been used in the GnosisStandardToken.sol and EtherToken.sol has not been used in the GnoDevDependencies.sol.

     GnosisStandardToken.sol is a standard token contract implemented by the Gnosis team. GnosisStandardToken.sol imported 3 solidity files:

     1. Token.sol: an abstract token contract for the ERC20 token (functions are not implemented)

     2. Math.sol: a math library allows the calculation of logarithmic and exponential functions

     3. Proxy.sol: a proxy standard contract indicates that a contract will be provided, it also defines storage requirements for proxy.

     However, the imported Proxy.sol has not been used/inherited in the GnosisStandardToken.sol.

     GnoDevDependencies.sol is used for truffle compilations.

     GnoDevDependencies.sol imported 2 Solidity files:

     1. GnosisStandardToken.sol: a standard token contract implemented by the Gnosis team.

     2. EtherToken.sol: a token contract that allows exchanging with Ether 1:1

     However, the imported EtherToken.sol has not been used/inherited in the GnoDevDependencies.sol.

     Smart contract implementation should be succinct and sufficient. To keep the best practice, any unnecessary functions/imports should be eliminated.

   • Exploit Scenario

     N/A

   • Recommendations

     Remove these unused imports.

   • Results

     Acknowledged by the Gnosis team.

1. State variable visibility unspecified

   Severity	Informational
   Source	@gnosis.pm/util-contracts/contracts/GnosisStandardToken.sol: L13-L15;
   Status	Acknowledged

   • Description

     Some variables in contract StandardTokenData.sol do not have specified visibilities. Labeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.

     TokenGNO.sol is the ERC20 implementation of the GNO token and it inherits contract GnosisStandardToken.sol. There are three variables that existed in GnosisStandardToken.sol:

     contract StandardTokenData {
         /*
          *  Storage
          */
         mapping(address => uint) balances;
         mapping(address => mapping(address => uint)) allowances;
         uint totalTokens;
     }

     The above pre-defined standard token data are accessed and can be modified in the derived contracts. Thus, the visibilities can be specifically marked as internal for better code readability and understanding.

   • Exploit Scenario

     N/A

   • Recommendations

     Adding internal for better readability, use below as an example

     mapping(address => uint) internal balances;
     mapping(address => mapping(address => uint)) internal allowances;
     unit internal totalTokens;

   • Results

     Acknowledged by the Gnosis team.