Shina Token

Shina Token

Date
Auditor
April 2022
Hacksafe

Audit Details

Audited project

Shina Token

Deployer address

0x0129829dBE7a41bBED9626DF482A2fc38e21584A

Client contacts

Shina Token team

Blockchain

Ethereum

Website

https://shinatoken.com/

Disclaimer

This is a limited report on our findings based on our analysis, in accordance with good industry practice as at the date of this report, in relation to cybersecurity vulnerabilities and issues in the framework and algorithms based on smart contracts, the details of which are set out in this report. In order to get a full view of our analysis, it is crucial for you to read the full report. While we have done our best in conducting our analysis and producing this report, it is important to note that you should not rely on this report and cannot claim against us on the basis of what it says or doesn’t say, or how we produced it, and it is important for you to conduct your own independent investigations before making any decisions. We go into more detail on this in the below disclaimer below – please make sure to read it in full.
DISCLAIMER: By reading this report or any part of it, you agree to the terms of this disclaimer. If you do not agree to the terms, then please immediately cease reading this report, and delete and destroy any and all copies of this report downloaded and/or printed by you. This report is provided for information purposes only and on a non-reliance basis, and does not constitute investment advice. No one shall have any right to rely on the report or its contents, and TechRate and its affiliates (including holding companies, shareholders, subsidiaries, employees, directors, officers and other representatives) (HackSafe) owe no duty of care towards you or any other person, nor does HackSafe make any warranty or representation to any person on the accuracy or completeness of the report. The report is provided “as is”, without any conditions, warranties or other terms of any kind except as set out in this disclaimer, and HackSafe hereby excludes all representations, warranties, conditions and other terms (including, without limitation, the warranties implied by law of satisfactory quality, fitness for purpose and the use of reasonable care and skill) which, but for this clause, might have effect in relation to the report. Except and only to the extent that it is prohibited by law, HackSafe hereby excludes all liability and responsibility, and neither you nor any other person shall have any claim against HackSafe, for any amount or kind of loss or damage that may result to you or any other person (including without limitation, any direct, indirect, special, punitive, consequential or pure economic loss or damages, or any loss of income, profits, goodwill, data, contracts, use of money, or business interruption, and whether in delict, tort (including without limitation negligence), contract, breach of statutory duty, misrepresentation (whether innocent or negligent) or otherwise under any claim of any nature whatsoever in any jurisdiction) in any way arising from or connected with this report and the use, inability to use or the results of use of this report, and any reliance on this report
The analysis of the security is purely based on the smart contracts alone. No applications or operations were reviewed for security. No product code has been reviewed.

Background

HeckSafe was commissioned by Shina Token to perform an audit of smart contracts:

Contracts Details

Token contract details for 25.04.2022

Contract name
: TokenMintERC20Token
Total supply
: 12 trillion
Token ticker
: SHI
Decimals
: 18
Token Holders
: 2,172
Transactions count
: 21,151
Contract deployer address
: 0x0129829dBE7a41bBED9626DF482A2fc38e21584A

Shina Inu Token Distribution

Shina-Token

Shina Inu Top 10 Token Holders

Shina-Token1

Contract functions details

+ [Int] IERC20

+ [Lib] SafeMath

+ ERC20 (IERC20)

+ TokenMintERC20Token

($) = payable function

# = non-constant function

Issues Checking Status

No
Title
Status
1.
Unlocked Compiler Version
Low issues
2.
Missing Input Validation
Passed
3.
Race conditions and Reentrancy. Cross-function race conditions.
Passed
4.
Possible delays in data delivery
Passed
5.
Oracle calls.
Passed
6.
Timestamp dependence.
Passed
7.
Integer Overflow and Underflow
Passed
8.
DoS with Revert.
Passed
9.
DoS with block gas limit.
Passed
10.
Methods execution permissions.
Passed
11.
Economy model of the contract
Passed
12.
Private user data leaks.
Passed
13.
Malicious Event log
Passed
14.
Scoping and Declarations.
Passed
15.
Uninitialized storage pointers.
Passed
16.
Arithmetic accuracy.
Passed
17.
Design Logic.
Passed
18.
Safe Open Zeppelin contracts implementation and usage.
Passed
19.
Incorrect Naming State Variable
Passed

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.

Security Issues

Critical Severity Issues

No critical severity issue found.

High Severity Issues

No high severity issue found.

Medium Severity Issues

No medium severity issues found.

Low Severity Issues

one low severity issues found.

1. Unlocked Compiler Version.

The contract utilizes an unlocked compiler version. An unlocked compiler version in the contract’s source code permits the user to compile it at or above a particular version. This, in turn, leads to difffferences in the generated bytecode between compilations due to diffffering compiler version numbers. This can lead to ambiguity when debugging as compiler-specifific bugs may occur in the codebase that would be diffiffifficult to identify over a span of multiple compiler versions rather than a specifific one.

It is advisable that the compiler version is alternatively locked at the lowest version possible so that the contract can be compiled. For example, for ^0.5.0 the contract should contain the following line:

pragma solidity 0.5.0;

Conclusion

Smart contract contains low severity issues! The further transfer and operations with the fund raised are not related to this particular contract.

HackSafe note: Please check the disclaimer above and note, the audit makes no statements or warranties on business model, investment attractiveness or code sustainability. The report is provided for the only contract mentioned in the report and does not include any other potential contracts deployed by Owner.

Send your project now

Fill the details to be connected with our experts.

Send your project now

Fill the details to be connected with our experts.