YearnAgnostic Smart Contract Final Audit Report.
⚡️ Audited by QuillAudits ⚡
Introduction
During the period of April 15th, 2021 to June 4th, 2021 — QuillAudits Team performed security audit for YearnAgnostic smart contracts. The code for audit was taken from the following links:
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/YFIAGToken/TokenYFIAG.sol
[Commit ID: 74791b1f2d7ed382bf865069433ddf284537a13a]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/controllers/Controller.sol
[Commit ID: f87036e351d3ced1c970509b3e809acb44f561b7]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/dao/Governance.sol
[Commit ID: 74791b1f2d7ed382bf865069433ddf284537a13a]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/dao/IRewardDistributionRecipient.sol
[Commit ID: 062df66e36e05176ad743f5f809288dcd18c6b78]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/dao/TokenToVotePowerStaking.sol
[Commit ID: 74791b1f2d7ed382bf865069433ddf284537a13a]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/dao/VotingPowerFees.sol
[Commit ID: f87036e351d3ced1c970509b3e809acb44f561b7]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/dao/VotingPowerFeesAndRewards.sol
[Commit ID: f87036e351d3ced1c970509b3e809acb44f561b7]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/interfaces/weth/IWETH.sol
[Commit ID: 74791b1f2d7ed382bf865069433ddf284537a13a]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/interfaces/weth/WETH.sol
[Commit ID: eac6a75d4a39387730d3112af499f8aba4b13f41]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/vaults/yVault.sol
[Commit ID: f87036e351d3ced1c970509b3e809acb44f561b7]
🔸https://github.com/Yearn-Agnostic/contracts/blob/main/contracts/vaults/yWETH.sol
[Commit ID: 74791b1f2d7ed382bf865069433ddf284537a13a]
✅Updated contracts:
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/YFIAGToken/TokenYFIAG.sol
[Commit ID: 75cd8dec70a475907b7138a469daab88d50f5a4a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/controllers/Controller.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a ]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/dao/Governance.sol
[Commit ID: 75cd8dec70a475907b7138a469daab88d50f5a4a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/dao/IRewardDistributionRecipient.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/dao/TokenToVotePowerStaking.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/dao/VotingPowerFees.sol
[Commit ID: 75cd8dec70a475907b7138a469daab88d50f5a4a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/dao/VotingPowerFeesAndRewards.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/interfaces/weth/IWETH.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/interfaces/weth/WETH.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/vaults/yVault.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
🔹https://github.com/Yearn-Agnostic/contracts/blob/develop/contracts/vaults/yWETH.sol
[Commit ID: 3ee222570a19f74797fd238eb3ca7b5bc7f4ac1a]
Overview of YearnAgnostic:
YearnAgnostic Finance supports decentralized finance (DeFi) projects deployed on Ethereum blockchain, Binance smart chain, Tron chain etc., focusing on simplicity, user experience, security and privacy. YearnAgnostic Finance is a DeFi yield aggregator platform providing a classical way to optimally earn yield or maximize profits on assets. YearnAgnostic Finance is a token-based ecosystem, and the underline token is YFIAG Token.
✅ Benefits:
▪️Best way to earn an optimal interest rate on assets.
▪️Simplifying earning process.
▪️Community voting for fairness and equity.
▪️Simple to use by everyone.
▪️Privacy and anonymous transactions.
✅ Features:
▫️LENDING
▫️STAKING
▫️BORROWING
▫️GOVERNANCE
✅ Tokenomics
◽️20% — Staking Rewards
◽️40% — Presale
◽️5% — Giveway
◽️15% — Team & Advisor
◽️13% — Marketing & Development
◽️7% — Future Development
👉Details: https://yearnagnostic.finance/
Scope of Audit:
The scope of this audit was to analyse YearnAgnostic smart contract codebase for quality, security, and correctness. Following is the list of smart contracts:
✔️TokenYFIAG.sol
✔️Controller.sol
✔️Governance.sol
✔️IRewardDistributionRecipient.sol
✔️TokenToVotePowerStaking.sol
✔️VotingPowerFees.sol
✔️VotingPowerFeesAndRewards.sol
✔️IWETH.sol
✔️WETH.sol
✔️yVault.sol
✔️yWETH.sol
OUT-OF-SCOPE: External contracts, External Oracles, other smart contracts in the repository or imported smart contracts, economic attacks.
Checked Vulnerabilities:
We have scanned Yearn Agnostic smart contracts for commonly known and more specific vulnerabilities. Here are some of the commonly known vulnerabilities that we considered:
▪️Re-entrancy
▪️Timestamp Dependence
▪️Gas Limit and Loops
▪️DoS with (Unexpected) Throw
▪️DoS with (Unexpected) revert
▪️DoS with Block Gas Limit
▪️Transaction-Ordering Dependence
▪️Use of tx.origin
▪️Exception disorder
▪️Gasless send
▪️Balance equality
▪️Byte array
▪️Transfer forwards all gas
▪️ERC20 API violation
▪️Malicious libraries
▪️Compiler version not fixed
▪️Redundant fallback function
▪️Send instead of transfer
▪️Style guide violation
▪️Unchecked external call
▪️Unchecked math
▪️Unsafe type inference
▪️Implicit visibility level
▪️Address hardcoded
▪️Using delete for arrays
▪️Integer overflow/underflow
▪️Locked money
▪️Private modifier
▪️Revert/require functions
▪️Using var
▪️Visibility
▪️Using blockhash
▪️Using SHA3
▪️Using suicide
▪️Using throw
▪️Using inline assembly
Techniques and Methods
Throughout the audit of YearnAgnostic smart contracts care was taken to ensure:
☑️The overall quality of code.
☑️Use of best practices.
☑️Code documentation and comments match logic and expected behaviour.
☑️Token distribution and calculations are as per the intended behaviour mentioned in the whitepaper.
☑️Implementation of token standards.
☑️Efficient use of gas.
☑️Code is safe from re-entrancy and other vulnerabilities.
A combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the smart contract audit. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the audit:
Structural Analysis:
In this step, we have analysed the design patterns and structure of smart contracts. A thorough check was done to ensure the Smart contract is structured in a way that will not result in future problems.
Static Analysis:
Static Analysis of smart contracts was done to identify contract vulnerabilities. In this step series of automated tools are used to test the security of smart contracts.
Code Review / Manual Analysis:
Manual Analysis or review of code was done to identify new vulnerability or verify the vulnerabilities found during the static analysis. Contracts were completely manually analysed, their logic was checked and compared with the one described in the whitepaper. Besides, the results of the automated analysis were manually verified.
Gas Consumption:
In this step, we have checked the behaviour of smart contract in production. Checks were done to know how much gas gets consumed and the possibilities of optimization of code to reduce gas consumption.
Tools and Platforms used for Audit:
Remix IDE, Truffle, Truffle Team, Ganache, Solhint, Mythril, Manticore, Slither, SmartCheck.
Assessment Summary and Findings Overview
Every issue in this report has been assigned with a severity level. There are four levels of severity, and each of them has been explained below.
High Severity Issues:
A high severity issue or vulnerability means that your smart contract can be exploited. Issues on this level are critical to the smart contract’s performance or functionality, and we recommend these issues be fixed before moving to a live environment.
Medium Severity Issues:
The issues marked as medium severity usually arise because of errors and deficiencies in the smart contract code. Issues on this level could potentially bring problems, and they should still be fixed.
Low Severity Issues:
Low-level severity issues can cause minor impact and or are just warnings that can remain unfixed for now. It would be better to fix these issues at some point in the future.
Informational:
These are severity four issues that indicate an improvement request, a general question, a cosmetic or documentation error, or a request for information. There is low-to-no impact.
Findings and Tech Details
High Severity Issues:
None.
Medium Severity Issues:
1. Reentrancy
One of the major dangers of calling external contracts is that they can take over the control flow, and make changes to your data that the calling function wasn’t expecting. It’s recommended that the calls to external functions/events should happen after any changes to state variables in your contract, so your contract is not vulnerable to a reentrancy exploit. When control is transferred to the recipient, care must be taken to not create reentrancy vulnerabilities. OpenZeppelin has its own mutex implementation you can use called ReentrancyGuard. This library provides a modifier you can apply to any function called nonReentrant that guards the function with a mutex.
Consider using ReentrancyGuard or the checks-effects-interactions pattern.
The following link explains more about Reentrancy and ReentrancyGuard
https://docs.openzeppelin.com/contracts/2.x/api/utils#ReentrancyGuard
https://blog.openzeppelin.com/reentrancy-after-istanbul/
Most Recent DeFi Reentrancy Attack: DFORCE
Code Lines:
▪️yVault.sol: deposit(uint256) [#142–158]
Auditor remarks: Fixed
▪️yWETH.sol: depositETH() [#21–35]
Auditor remarks: Fixed
▪️VotingPowerFees.sol: _withdrawFeesFor(address) [#82–98]
Auditor remarks: Fixed
▪️VotingPowerFeesAndRewards.sol: getReward() [#135–142]
Auditor remarks: Fixed
▪️Controller.sol: setStrategy(address,address) [#159–167]
Auditor remarks: Fixed
▪️Governance.sol: withdraw(uint256) [#290–295]
Auditor remarks: Fixed
Low Severity Issues:
1. The compiler version should be fixed
Solidity source files indicate the versions of the compiler they can be compiled with. It’s recommended to lock the compiler version in code, as future compiler versions may handle certain language constructions in a way the developer did not foresee. It is recommended to use any fixed compiler version from 0.6.12.
Auditor remarks: Fixed
Except for TokenYFIAG.sol, the compiler version is fixed. TokenYFIAG.sol — has a compiler version in a range.
2. Coding Style Issues
Coding style issues influence code readability and, in some cases, may lead to bugs in future. Smart Contracts have a naming convention, indentation and code layout issues. It’s recommended to use Solidity Style Guide to fix all the issues. Consider following the Solidity guidelines on formatting the code and commenting for all the files. It can improve the overall code quality and readability.
3. Order of layout
The order of functions as well as the rest of the code layout does not follow the solidity style guide.
Layout contract elements in the following order:
a. Pragma statements
b. Import statements
c. Interfaces
d. Libraries
e. Contracts
Inside each contract, library or interface, use the following order:
a. Type declarations
b. State variables
c. Events
d. Functions
Please read the following documentation links to understand the correct order: https://solidity.readthedocs.io/en/v0.6.12/style-guide.html#order-of-layout
4. Naming convention issues — Variables, Structs, Functions
It is recommended to follow all solidity naming conventions to maintain the readability of code.
Details: https://docs.soliditylang.org/en/v0.6.12/style-guide.html#naming-conventions
5. Remove the dead code from the files
Consider removing the commented or dead code from the files.
Code Lines:
▪️yWETH.sol: 5–9
Auditor remarks: Fixed
6. Log the important events inside functions
It’s a good practice to log important events. In Governance.sol for functions like setGovernance, setMinimum and setPeriod should emit events.
Code Lines: Governance.sol[208, 214, 220]
Auditor remarks: Fixed
7. Use external function modifier instead of public
The public functions that are never called by contract should be declared external to save gas. Following functions can be declared external:
TokenToVotePowerStaking.sol
- totalSupply() [#36–38]
- balanceOf(address) [#43–45]
- stake(uint256) [#50–54]
- withdraw(uint256) [#58–62]
Informational:
1. Overpowered owner
The contract is tightly coupled to the owner, making some functions callable only by the owner’s address. This poses a serious risk: if the private key of the owner gets compromised, then an attacker can gain control over the contract.
2. Approve function of ERC-20 is vulnerable
A security issue called “Multiple Withdrawal Attack” — originates from two methods in the ERC20 standard for approving and transferring tokens. The use of these functions in an adverse environment (e.g., front-running) could result in more tokens being spent than what was intended. This issue is still open on the GitHub, and several solutions have been made to mitigate it.
For more details on how to resolve the multiple withdrawal attack, check the following document for details:
https://drive.google.com/file/d/1skR4BpZ0VBSQICIC_eqRBgGnACf2li5X/view?usp=sharing
3. Use of block.timestamp should be avoided
Do not use block.timestamp, now or blockhash as a source of randomness. Malicious miners can alter the timestamp of their blocks, especially if they can gain advantages by doing so. Contracts often need access to the current timestamp to trigger time-dependent events. As Ethereum is decentralized, nodes can synchronize time only to some degree. It is risky to use block.timestamp, as block.timestamp can be manipulated by miners. Therefore block.timestamp is recommended to be supplemented with some other strategy in the case of high-value/risk applications.
Remediations:
☑️https://consensys.github.io/smart-contract-best-practices/recommendations/#timestamp-dependence
☑️https://consensys.github.io/smart-contract-best-practices/recommendations/#avoid-using-blocknumber-as-a-timestamp
Automated Testing
Slither: Slither is an open-source Solidity static analysis framework. This tool provides rich information about Ethereum smart contracts and has the critical properties. It runs a suite of vulnerability detectors, prints visual information about contract details, and provides an API to easily write custom analyses. Slither enables developers to find vulnerabilities, enhance their code comprehension, and quickly prototype custom analyses.
Slither didn’t raise any critical issue with smart contracts. The smart contracts were well tested, and all the minor issues that were raised have been documented in the report. Also, all other vulnerabilities of importance have already been covered in the manual audit section of the report.
SmartCheck
SmartCheck is a tool for automated static analysis of Solidity source code for security vulnerabilities and best practices. SmartCheck translates Solidity source code into an XML-based intermediate representation and checks it against XPath patterns. SmartCheck shows significant improvements over existing alternatives in terms of false discovery rate (FDR) and false negative rate (FNR).
SmartCheck did not detect any high severity issue. All the considerable issues raised by SmartCheck are already covered in the code review section of this report.
Mythril
Mythril is a security analysis tool for EVM bytecode. It detects security vulnerabilities in smart contracts built for Ethereum. It uses symbolic execution, SMT solving and taint analysis to detect a variety of security vulnerabilities.
Mythril did not detect any high severity issue. All the considerable issues raised by Mythril are already covered in the issues found section of this report.
Remix IDE
Remix is a powerful, open-source tool that helps you write Solidity contracts straight from the browser. Written in JavaScript, Remix supports both usage in the browser and locally.
The smart contract compiled without any error on Remix IDE. The contract was successfully deployed. And the gas consumption was found to be normal.
Closing Summary
Overall, the smart contract code is extremely well documented, follows a high-quality software development standard, contains many utilities and automation scripts to support continuous deployment/ testing/ integration, and does NOT contain any obvious exploitation vectors that QuillAudits was able to leverage within the timeframe of testing allotted. Overall, the smart contracts adhered to ERC20 guidelines. No critical or major vulnerabilities were found in the audit. One issue of medium severity and several issues of low severity were found and reported during the audit. A few of them are fixed now.
The outcome of this security audit is satisfactory; due to time and resource constraints, only testing and verification of essential properties was performed to achieve objectives and deliverables set in the scope. QuillAudits recommends performing further testing to validate extended safety and correctness in context to the whole set of contracts.
Disclaimer
QuillHash audit is not a security warranty, investment advice, or an endorsement of the YearnAgnostic platform. This audit does not provide a security or correctness guarantee of the audited smart contracts. The statements made in this document should not be interpreted as investment or legal advice, nor should its authors be held accountable for decisions made based on them. Securing smart contracts is a multistep process. One audit cannot be considered enough. We recommend that the YearnAgnostic Team put in place a bug bounty program to encourage further analysis of the smart contract by other third parties.
audits.quillhash.com
