Shiba Inu Security Audit

By Fushuma | Fushuma | 22 Dec 2021


giphy.gif

Note: This article was originally published under the Callisto Network blog. We are now evolving into Fushuma, a community-driven blockchain leveraging advanced ZK-Rollup technology for low fees and high throughput.

In Fushuma, FUMA token holders drive on-chain governance by making decisions on network upgrades and project funding. As the ecosystem grows, they are rewarded with tokens airdropped from funded initiatives.

Learn more about our transition and the exciting developments ahead for Fushuma here.


SHIBA INU (SHIB) Token Security Audit Report

Are Your Funds Safe?

Our expert team at Callisto Network has conducted an in-depth security audit of the SHIBA INU (SHIB) Token smart contract. This audit aims to ensure the security of your funds by identifying and assessing any potential vulnerabilities. Here, we present our findings:

Executive Summary

This report presents the results of the security audit conducted by the Callisto Network Security Department on the SHIBA INU (SHIB) Token smart contract in December 2021. It analyzes the contract’s security in-depth and highlights any identified vulnerabilities.

1. Scope of the Audit

The audit focused on the following SHIBA INU contract:

1.1 Excluded

The schedule correctness of token distribution was excluded from the audit.

2. Audit Findings

Our audit reported a total of 1 finding(s), categorized as follows:

  • 0 high-severity issue(s).
  • 0 medium severity issue(s).
  • 1 low-severity issue(s).

In addition to these findings, our audit identified 1 additional points, detailed in the following sections:

  • 1 note(s).
  • 0 owner privilege(s).

No critical security issues were found.

2.1 Known Vulnerabilities of ERC-20 Token

Severity: Low.

Description:

The contract lacks a transaction handling mechanism. WARNING! This common vulnerability has already led to significant financial losses. For a comprehensive understanding of this issue, click here.  

Recommendation: 

Add the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

2.2 allDepositIds is not necessary

Severity: Note.

Description:

The allDepositIds array contains a sequence of id from 1 to depositId. So all deposits Ids are below or equal to depositId.

3. Security Practices

Open-Source Contract: The contract's source code should be accessible for public scrutiny.

❌ Bug Bounty Program: Initiating a bug bounty program post-audit for comprehensive security validation is recommended.

❌ Public testing: The contract should undergo public testing to detect unforeseen bugs or issues.

❌ Automated Anomaly Detection System: Not Implemented. Establishing a simple anomaly detection algorithm to monitor and respond to unusual activities is advised. For instance, the contract must temporarily suspend deposits if a large withdrawal is detected until approval by the contract owner or community.

Multi-signature Owner Account: A multi-signature setup for owner accounts is recommended for additional security layers.

❌ Standard ERC20-Related Issues: Not Implemented. It is known that a smart contract, even if not designed to receive or hold tokens, can still inadvertently receive ERC20-token deposits, without the ability to reject them. Thus, it's recommended to incorporate a function that allows for the extraction of any number of such unintended tokens from the contract.

Crosschain Address Collisions: Transactions can be mistakenly sent to a contract's address on a different chain (ETH, ETC, CLO, etc..). To mitigate this, deploying a "mock contract" that allows token withdrawal or prevents fund deposits at the address is recommended. Please note native blockchain coin deposits can be rejected, but ERC20 token deposits cannot. The following source code can be used as a mock contract: extractor contract source code. When deploying a new contract using CREATE (0xf0) opcode, the new contract's address follows this scheme keccak256(rlp([sender, nonce])). Thus, the same address used on the main chain should be used to deploy the mock contract, with the transaction nonce matching that on the original chain. For example, if your main contract (address 0x010101) was deployed in your 2021st transaction, you need to increase your nonce of address 0x010101 to 2020 on the chain where your mock contract will be deployed. Then, your 2021st transaction can deploy your mock contract, which will share the same address as your mainnet contract.  

4. Conclusion

The audited smart contract can be deployed. Only low-severity issues were found during the audit.

It is recommended to adhere to the security practices described in pt. 4 of this report to ensure the contract’s operability and prevent any issues that are not directly related to the code of this smart contract.

How do you rate this article?

16


Fushuma
Fushuma

Fushuma is a community-driven blockchain ecosystem with ZK-Rollup technology, low fees, and on-chain governance. FUMA holders decide on upgrades, funding, and are rewarded as the ecosystem grows.


Fushuma
Fushuma

Fushuma is a community-driven blockchain with ZK-Rollup technology, low fees, and on-chain governance. FUMA holders decide on upgrades, funding, and are rewarded as the ecosystem grows.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.