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.

---

Linear Token (LINA) Token Security Audit Report

Are Your Funds Safe?

Linear Token (LINA) Token smart contract security audit, conducted by the Callisto Network Security Department during December 2021.

1. Scope of the Audit

• https://bscscan.com/address/0x762539b45a1dcce3d36d080f74d1aed37844b878#code

• Token implementation: https://bscscan.com/address/0x2ae9952c1038da3dafeba026b96053f24cbc03b3#code

2. Audit Findings

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

• 0 high severity issues.
• 0 medium severity issue.
• 1 low severity issue.

In total, 1 notes were reported, including:

• 0 notes.
• 1 owner privileges.

No critical security issues were found.

2.1 Admin privileges

Severity: Low

Description:

Lack of transaction handling mechanism issue. WARNING! This is a very common issue, and it already caused millions of dollars in losses for lots of token users!

More details here.

Recommendation:

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

require( _to != address(this) );

2.2 Upgradable token contract

Severity: Owner Privileges

Description:

This token contract is upgradable. Owner has right to change contract implementation code to add any functions (which may be not secure).

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.

Users should note that the Contract Administrator (owner) can change the code at any time.

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.