Hacken - Bonded Staking - SingularityDAO Documentation

Search…
Hacken - Bonded Staking
Smart Contract Code Review and Security Analysis Report
Customer: SDAO
Date: August 13th, 2021
​
 
​
This document may contain confidential information about IT systems and the intellectual property of the Customer as well as information about potential vulnerabilities and methods of their exploitation.
The report containing confidential information can be used internally by the Customer, or it can be disclosed publicly after all vulnerabilities are fixed — upon a decision of the Customer.
Document
Name
Smart Contract Code Review and Security Analysis Report for
SDAO.
Approved by
Andrew Matiukhin | CTO Hacken OU
Type
Bonded Staking
Platform
Ethereum / Solidity
Methods
Architecture Review, Functional Testing, Computer-Aided
Verification, Manual Review
Repository
https://github.com/Singularity-DAO/farming_contracts
Commit
a14f87eddc615e7fc0f143de94d78735687112b3
Technical Documentation
YES
JS tests
YES
Timeline
09 AUGUST 2021 – 13 AUGUST 2021
Changelog
12 AUGUST 2021 – INITIAL AUDIT
13 AUGUST 2021 – SECOND REVIEW
Hacken OÜ (Consultant) was contracted by SDAO (Customer) to conduct a Smart Contract Code Review and Security Analysis. This report presents the findings of the security assessment of the Customer's smart contract and its code review conducted between August 9th, 2021 - August 12th, 2021. The second review conducted on August 13th, 2021.
Scope
The scope of the project is smart contracts in the repository:
Repository:
​https://github.com/Singularity-DAO/farming_contracts​
Commit:
a14f87eddc615e7fc0f143de94d78735687112b3
Technical Documentation: Yes
JS tests: Yes
Contracts:
interfaces/IERC20.sol 
libraries/BoringERC20.sol 
libraries/BoringMath.sol 
libraries/SignedSafeMath.sol 
mocks/ERC20Mock.sol 
Migrations.sol 
SDAOBondedTokenStake.sol 
SDAOTokenStaking.sol
We have scanned this smart contract for commonly known and more specific vulnerabilities. Here are some of the commonly known vulnerabilities that are considered:
Category
Check Item
Code review
Reentrancy
Ownership Takeover
Timestamp Dependence
Gas Limit and Loops
DoS with (Unexpected) Throw
DoS with Block Gas Limit
Transaction-Ordering Dependence
Style guide violation
Costly Loop
ERC20 API violation
Unchecked external call
Unchecked math
Unsafe type inference
Implicit visibility level
Deployment Consistency
Repository Consistency
Data Consistency
​
​
Functional review
Business Logics Review
Functionality Checks
Access Control & Authorization
Escrow manipulation
Token Supply manipulation
Assets integrity
User Balances manipulation
Data Consistency manipulation
Kill-Switch Mechanism
Operation Trails & Event Generation
Executive Summary
According to the assessment, the Customer's smart contracts are well-secured.
​
Insecure
Poor secured
Secured
Well-secured  <-- You are here
Our team performed an analysis of code functionality, manual audit, and automated checks with Mythril and Slither. All issues found during automated analysis were manually reviewed, and important vulnerabilities are presented in the Audit overview section. All found issues can be found in the Audit overview section.
As a result of the audit, security engineers found 5 medium and 3 low severity issues.
After the second review security engineers didn’t find any security issues in the code.
Notice:
The document with business logic was updated. Not it matches contracts.
Severity Definitions
Risk Level
Description
​
​
​
​
Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to assets loss or data manipulations.
​
​
​
​
High
High-level vulnerabilities are difficult to exploit; however, they also have a significant impact on smart contract execution, e.g., public access to crucial functions
​
​
​
​
Medium
Medium-level vulnerabilities are important to fix; however, they can't lead to assets loss or data manipulations.
​
​
​
​
Low
Low-level vulnerabilities are mostly related to outdated, unused, etc. code snippets that can't have a significant impact on execution
​
​
​
​
​
Audit overview
​
​
​
​
Critical
No critical issues were found.
​
​
​
High
No high severity issues were found.
​
​
Medium
1.Documentation discrepancy: 90,000 SDAO token with a min APY of 30% guaranteed
Provided request for audit document states the following: “90,000 SDAO token with a min APY of 30% guaranteed (guaranteed APY can change in future). Rewards should be configurable while opening the stake pool/window.
Ensure that we replenish if APY goes below 30% for the pool”
But actually contracts doesn’t have anything to do with min APY guarantees or initial rewards amount.
Recommendation: Please either update documentation or implement a missing logic
Fixed before the second review: Updated the document. Refer first section of the document.
2. Documentation discrepancy: Credits to each token holder
Provided request for audit document states the following: “Participating in the bonding pool would also give a credit to each token holder that held for the whole period.”
But actually contracts have nothing to do with either bonding pools or rewards for participating in those.
Recommendation: Please either update documentation or implement a missing logic.
Fixed before the second review: This is already in place in the contract as part of the bonusToken. Updated the document to be on the same lines.
3. Documentation discrepancy: Max limit for stake
Provided request for audit document states the following: “There is a max limit on the number of tokens that a user can stake? 25K per wallet to be begin with but can be changed later.”
But contracts only have an ability to specify the max amount for staking when creating a new staking, but nothing regarding default 25K per wallet or ability to change a limit later.
Recommendation: Please either update documentation or implement a missing logic.
Fixed before the second review: Updated the document accordingly. Max Limit for the wallet is already in place in the contract.
4. Documentation discrepancy: Airdrop users
Provided request for audit document states the following: “Airdrop users can choose to stake directly from the airdrop portal. These users get priority in the stake but will have 5 days when their tokens are just sitting in the bonded staking contract (the window period)”
But contracts only have an ability to mass add airdropped users as a batch buy the admin, and have nothing to do with 5 days locking or anything like that.
Recommendation: Please either update documentation or implement a missing logic.
Fixed before the second review: Updated the document.
5. Documentation discrepancy: Window for bonded staking
Provided request for audit document states the following: “Window for bonded staking is 5 days after 5 days the window closes and staking begins.
In these 5 days users can deposit to stake and withdraw (if they choose).
Users coming in from the airdrop can also withdraw if they choose to.”
But contracts have neither windows for staking nor differentiation for stakes from airdrop user and others
Recommendation: Please either update documentation or implement a missing logic.
Fixed before the second review: Updated the document.
​
Low
1.Test coverage
The tests provided for audit does not cover all cases provided in documentation as well as test coverage for code branches is only 52%.
Recommendation: Please consider covering all the cases provided in the documentation and have a code coverage at least 95%.
Fixed before the second review: Most of the functionality is covered, Also covered scenario where the bonus amount is not set or set to zero.
2. Style guide violation: Code Layout
A solidity declares a style guide and a code layout guides as a part of it. It is very important to follow them because it make a code more readable and easy to audit.
Recommendation: Please follow code layout guides.
Fixed before the second review: Followed the same coding style. Minimized the dev doc section, will improvise the same.
3. A public function that could be declared external
public functions that are never called by the contract should be declared external to save gas.
Recommendation: use the external attribute for functions never called from the contract.
Fixed before the second review.
Conclusion
Smart contracts within the scope were manually reviewed and analyzed with static analysis tools.
The audit report contains all found security vulnerabilities and other issues in the reviewed code.
As a result of the audit, security engineers found 5 medium and 3 low severity issues.
After the second review security engineers didn’t find any security issues in the code.
Notice:
The document with business logic was updated. Not it matches contracts.
Hacken Disclaimer
The smart contracts given for audit have been analyzed in accordance with the best industry practices at the date of this report, in relation to cybersecurity vulnerabilities and issues in smart contract source code, the details of which are disclosed in this report (Source Code); the Source Code compilation, deployment, and functionality (performing the intended functions).
The audit makes no statements or warranties on the security of the code. It also cannot be considered as a sufficient assessment regarding the utility and safety of the code, bug-free status, or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only — we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts.
Technical Disclaimer
Smart contracts are deployed and executed on a blockchain platform. The platform, its programming language, and other software related to the smart contract can have vulnerabilities that can lead to hacks. Thus, the audit can't guarantee the explicit security of the audited smart contracts.