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.

---

League of Ancients Security Audit Report

Are Your Funds Safe?

Our expert team at Callisto Network has conducted an in-depth security audit of the League of Ancients smart contract. This audit aims to ensure the security of your funds by identifying and assessing any potential vulnerabilities.

Executive Summary

This report presents the results of the security audit conducted by the Callisto Network Security Department on the League of Ancients smart contract in November 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 League of Ancients contract:

Blockchain: Binance Smart Chain.

• Source Code: https://gitlab.com/jingyi2811/luo/-/tree/main/original-contracts.
• Commit ef025a4498362ccd65af62ff81a2f38a2b2abd1b.

1.1 Excluded

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

2. Audit Findings

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

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

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

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

No critical security issues were found.

2.1 Admin privileges

Severity: owner privileges.

Description:

LoaToken contract Admin can:

• 1. Pause/unpause token transfer.
• 2. Pause/unpause token transfer for the selected address.

LoaPresale contracts Admin can:

• 3. Add/remove addresses to/from the whitelist.
• 4. Withdraw deposited BNB.
• 5. Finish LoaPresale earlier.

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. No security 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.