Owner privileges
Comments
- Owner
- can set following state variables without any limitation
- fee
- can set following addresses
- fundBox
- cannot call internal functions directly. Following internal function cannot be called by the owner because it is not used in the contract:
- pop_judge
- can set following state variables without any limitation
- Owner is able to withdraw all tokens from a token with the "withdrawRewardAdmin" function
- Anyone can read the "code" in the constructor even it is a private variable. That means, that the if condition in the "add_judge" where the passed "_code" (keccak256) is compared to the code keccak256 is unnecessary
- We highly recommend you to check the require statements where the "timestamp()" is called because the contract is looking for that the times are not same as the timestamp, and this will just happen only once.
- Block.timestamp is in seconds, the timestamp() function is converting it to milliseconds
- Fees will be deposited into the "_depositBox" state variable without any differentials. That causes that the fees cannot be seperated from each other. Anybody is able to withdraw this value.
- User funds are locked while submitting as subscriber. You are not able to withdraw it because the status cannot be changed anymore.
- Anyone can basically
- withdraw the subscript for any arbitrary address as long as the caller is not the owner. This can be bypassed by another own private wallet.
- withdraw the amount of the rewards to an arbitrary address without permission until the depostbox is empty
Audit Scope
This audit covered the following files listed below with a SHA-1 Hash. The above token Team provided us with the files that needs to be tested.
We will verify the following claims:- Correct implementation of Token standard
- Deployer cannot mint any new tokens
- Deployer cannot burn or lock user funds
- Deployer cannot pause the contract
- Overall checkup (Smart Contract Security)
- Review of the specifications, sources, and instructions provided to SolidProof to make sure we understand the size, scope, and functionality of the smart contract.
- Manual review of code, which is the process of reading source code line-by-line in an attempt to identify potential vulnerabilities.
- Comparison to specification, which is the process of checking whether the code does what the specifications, sources, and instructions provided to SolidProof describe.
- Test coverage analysis, which is the process of determining whether the test cases are actually covering the code and how much code is exercised when we run those test cases.
- Symbolic execution, which is analysing a program to determine what inputs causes each part of a program to execute.
- Best practices review, which is a review of the smart contracts to improve efficiency, effectiveness, clarify, maintainability, security, and control based on the established industry and academic practices, recommendations, and research.
- Specific, itemized, actionable recommendations to help you take steps to secure your smart contracts.
A file with a different Hash has been modified, intentionally or otherwise, after the security review. A different Hash could be (but not necessarily) an indication of a changed condition or potential vulnerability that was not within the scope of this review.
Functions
public
34
State variables
public
2
Total lines
of code
948
Capabilities
Hover on items
Audit Details
Throughout the review process, care was taken to evaluate the repository for security-related issues, code quality, and adherence to speciïŹcation and best practices. To do so, reviewed line-by-line by our team of expert pentesters and smart contract developers, documenting any issues as there were discovered.
Risk represents the probability that a certain source-threat will exploit vulnerability, and the impact of that event on the organization or system. Risk Level is computed based on CVSS version 3.0.
high Issues
Pending
#1 Issue
Wrong condition check
L716
The "_limitationWithdraw != timestamp()" require statement is wrong. In this case the caller can call the withdraw function all the time, except the timestamp of 8 days.
Pending
#2 Issue
Withdrawing whole deposited fees
L694
Everyone except the judge (who can bypass this check with another wallet) can withdraw the whole deposition by calling the function more than once. This function has no limitation to withdraw everything. Additionally they can pass any "judgeId" to get the deposited fees to the judge. There is also no check that the judge is allowed to get it.
Pending
#3 Issue
Subscriber cannot withdraw
L669
subscriber is not able to withdraw the balance of subscription because the active state will never set to false. It is true by default.
Pending
#4 Issue
Dividing by 0
L493
The "submit_openHatch" function will be reverted when the "submit_fee" is set to 0. You cannot divide by zero in the totalFee calculation. Make sure to check the "get_submitFee function because it is returning submit_fee * 1000 in this case.
low Issues
Pending
#1 Issue
Missing Events Arithmetic (events-maths)
L604-609
L876-878
Emit an event for critical parameter changes.
Pending
#2 Issue
Missing Zero Address Validation (missing-zero-check)
L872
Check that the address is not zero.
Pending
#3 Issue
State variable visibility is missing
L389
L390
L391
L436
L437
L438
L443
We recommend you to set the visibility for the state variables.
Pending
#4 Issue
Wrong TypeBox in withdrawRewardAdmin function
L762
In the "withdrawRewardAdmin" function you should use the TYPEBOX.REWARDS instead of TYPEBOX.FEES
informational Issues
Pending
#1 Issue
Functions that are not used (dead-code)
L227-229
L859-870
L881-896
L92-94
L134-136
L188-195
L150-152
L212-219
L120-122
L106-108
L167-174
L11-19
L59-66
L73-80
L40-52
L26-33
Remove unused functions.
Pending
#2 Issue
Ineffective variable setting in timestampDays functions
L944
"time" variable can be set directly as "uint256 time = _day * 86400000"
Pending
#3 Issue
Confusing function name
L596
We recommend you to modify the "get_adminBox" function name to "get_feeBox"like based on the "get_rewardsBox"
Pending
#4 Issue
Check length
L851
We recommend you to check the length of "_judges" is higher than the "_id" parameter in the function. Any values above it be the default "Judge_form" without any data in it anyway. Same for the "get_judge" function
Pending
#5 Issue
Wrong error message
L467
We recommend you to adjust the error message in the isOpen modifier because it is looking for the active status of the openHatch instead of the author.
Pending
#6 Issue
Unnecessary if statement
L558
In this case that the require statement in L561 is checking the same condition as the "if" condition and a modifier is not checking the local variable "result" at any points, it is unnecessary. We recommend you to remove it.
Pending
#7 Issue
Struct was not used in the contract
L429
Remove or use the struct "Box_Fees"
optimization Issues
Pending
#1 Issue
Public function that could be declared external (external-function)
L276-278
L284-290
L477-519
L570-576
L587-594
L596-602
L604-609
L612-618
L620-641
L643-659
L661-667
L669-692
L694-732
L736-738
L741-764
L766-772
L774-782
L803-820
L822-849
L851-857
L872-874
L876-878
L898-900
L931-937
Use the `external` attribute for functions never called from the contract.
Diagrams
Disclaimer
SolidProof.io reports are not, nor should be considered, an âendorsementâ or âdisapprovalâ of any particular project or team. These reports are not, nor should be considered, an indication of the economics or value of any âproductâ or âassetâ created by any team. SolidProof.io do not cover testing or auditing the integration with external contract or services (such as Unicrypt, Uniswap, PancakeSwap etcâ...)
SolidProof.io Audits do not provide any warranty or guarantee regarding the absolute bug- free nature of the technology analyzed, nor do they provide any indication of the technology proprietors. SolidProof Audits should not be used in any way to make decisions around investment or involvement with any particular project. These reports in no way provide investment advice, nor should be leveraged as investment advice of any sort.
SolidProof.io Reports represent an extensive auditing process intending to help our customers increase the quality of their code while reducing the high level of risk presented by cryptographic tokens and blockchain technology. Blockchain technology and cryptographic assets present a high level of ongoing risk. SolidProofâs position is that each company and individual are responsible for their own due diligence and continuous security. SolidProof in no way claims any guarantee of security or functionality of the technology we agree to analyze.