SOY Finance Security Audit
Soy.Finance (SOY) security audit, conducted by the Callisto Network Security Department during March 2021.
Article published on Callisto Blog on 28th March 2021.
SOY Finance Specification
Audit Request
SoyFinance smart-contract security audit performed by Dexaran.
Telegram: https://t.me/Soy_FinanceNews.
Symbol:
SOY.
SOY Finance Smart Contracts Security Audit Report
1. In scope
Commit cf49fdee1ddd1a3e743d2c3a6e8a22e37ae2ece5
CLOE_ERC20.sol
Ownable.sol
SOY_ERC20.sol
StakingRewards.sol
airdrop.sol
2. Findings
In total, 6 issues were reported including:
2 low severity issues.
3 notes.
1 owner privileges.
No critical security issues were found.
2.1 Private variables
Severity: low.
Description:
There is no way to hide any values of internal variables on the chain because the history of transactions is publicly available at any time as well as initial values of the variables. As the result making variables private has no real use. Private variables can only make debugging harder.
Code snippet:
2.2 Non-constant unchangeable variables
Severity: note / readability.
Description:
Some variables are not intended to be changed during the contract workflow. Such variables should be marked as constant or immutable (immutable state variables in Solidity).
Example: _name, _symbol, _decimals.
Code snippet:
Recommendation
It is recommended to make unchangeable variables constant.
2.3 Declaring variables during deployment
Severity: note / readability.
Description:
Some variables are declared as constructor parameters.
While declaring contract addresses in the constructor is more flexible it may be better to hard-code addresses of the preliminarily known contracts to ensure that no mistake can occur during deployment as well as make verifying contracts correctness easier.
Code snippet:
2.4 Owner privileges can be removed permanently
Severity: low.
Description:
Some variables are declared as constructor parameters.
While declaring contract addresses in the constructor is more flexible it may be better to hard-code addresses of the preliminarily known contracts to ensure that no mistake can occur during deployment as well as make verifying contracts correctness easier.
Code snippet:
Recommendation:
It is strongly recommended to use a multisig as an owner of the contract. Otherwise it is possible to implement the possibility to have multiple owners.
2.5 Owner can potentially mint tokens at will.
Severity: owner privileges
Description:
Owner can assign any arbitrary contract a gateway role and use it to mint new tokens.
2.6 Standard ERC20 issues prevention
Severity: low
Description:
Since ERC20 is a widely used standard across the Ethereum-based chains it is reasonable to assume that ERC20 tokens can potentially interact with this contract as well. It is known that ERC20 tokens can get stuck in any contract if they are sent via the transfer function.
It would be reasonable to implement a “ERC20-rescue” function in any contract in order to prevent financial losses for any users of ERC20 tokens in the future.
Recommendation:
Implement an interface contract iERC20rescueable and make every contract that is not supposed to have ERC20 tokens at its balance to be iERC20rescueable
Implement a function that would allow the “owner” of an iERC20rescueable contract to extract any arbitrary number of ERC20 tokens from the contract balance.
3. Conclusion
The audited smart contract does not contain any critical or high severity security issues. It is recommended to implement the ERC20-rescue function in order to prevent financial losses for future users of ERC20 tokens that may potentially interact with the audited contracts.
Last updated
