🎆Internal Audit
Introduction
This report presents the findings of the security assessment of the Thorn Stable Swap’s smart contract and its code review conducted between July 22nd, 2024 – July 26th, 2024.
Project Summary
Project Name: Thorn Stable Swap
Language: Solidity
Codebase:
Commit: f2cfa14f44b7326d514560257c2cdfb48e1be8ae
Audit method: Static Analysis, Manual Review
Scope:
contracts/stableSwap
contracts/StableSwapRouter.sol
Vulnerability Summary
Findings
Detailed Results
ID-01: Missing zero address validation
Description
Detect missing zero address validation. Transactions can be reverted in unexpected way if functions are called with invalid arguments.
At contracts/StableSwapRouter.sol#53, stableSwapFactory = _stableSwapFactory; is called without validating the _stableSwapFactory address.
At contracts/StableSwapRouter.sol#54, stableSwapInfo = _stableSwapInfo; is called without validating the _stableSwapInfo address.
At contracts/stableSwap/StableSwapLP.sol#28, minter = _newMinter; is called without validating the _newMinter address.
At contracts/libraries/SmartRouterHelper.sol#25, IStableSwapFactory.StableSwapPairInfo memory info = IStableSwapFactory(stableSwapFactory).getPairInfo(input, output); is called without validating the stableSwapFactory address.
Recommendation
Check that the address is not zero.
ID-02: Mismatched function name
Description
At TransferHelper.sol#56, function used to transfer native token (ROSE) is named safeTransferETH(address to, uint256 value).
Recommendation
Change function name to safeTransferROSE to avoid confusions.
ID-03: Lack of comment for functions
Description
Functions without developer’s comments: getStableInfo(address, address, address, uint256); getStableAmountsIn(address, address, address[] memory, uint256[] memory, uint256); getStableAmountsOut(address, address[] memory, uint256[] memory, uint256)
Recommendation
Add comments for functionality, parameters, and return values
Appendix
Severity Definitions
Critical This level vulnerabilities could be exploited easily and can lead to asset loss, data loss, asset, or data manipulation. They should be fixed right away
Medium This level vulnerabilities are hard to exploit but very important to fix, they carry an elevated risk of smart contract manipulation, which can lead to critical-risk severity.
Low This level vulnerabilities should be fixed, as they carry an inherent risk of future exploits, and hacks which may or may not impact the smart contract execution.
Informational This level vulnerabilities can be ignored. They are code style violations and informational statements in the code. They may not affect the smart contract execution.
Finding Categories
Gas Optimization Gas Optimization findings refer to exhibits that do not affect the functionality of the code but generate different, more optimal EVM opcodes resulting in a reduction on the total gas cost of a transaction.
Logical Issue Logical Issue findings are exhibits that detail a fault in the logic of the linked code, such as an incorrect notion on how block.timestamp works.
Coding Style Coding Style findings usually do not affect the generated byte-code and comment on how to make the codebase more legible and as a result easily maintainable.
Mathematical Operations Mathematical Operation exhibits entail findings that relate to mishandling of math formulas, such as overflows, incorrect operations etc.
Dead Code Code that otherwise does not affect the functionality of the codebase and can be safely omitted.
Language Specific Language Specific findings are issues that would only arise within Solidity, i.e. incorrect usage of private or delete.
Last updated