Introduction

CoinFabrik was asked to audit the contracts for the Katana project. First we will provide a summary of our discoveries and then we will show the details of our findings.

Summary

The contracts audited are taken from the package Katana.rar, with md5 hash 4cs1966ec0ccef5e8bf27d6cadbc8a8c7.

Contracts

The audited contract is:

• KatanaToken.sol: Katana Token, with delegation and checkpoint logic.
• Samurai.sol: Token administration functions and allocation logic.

This KatanaToken.sol contract uses OpenZeppelin’s ERC20 and Ownable libraries.

Analyses

The following analyses were performed:

• Misuse of the different call methods
• Integer overflow errors
• Division by zero errors
• Outdated version of Solidity compiler
• Front running attacks
• Reentrancy attacks
• Misuse of block timestamps
• Softlock denial of service attacks
• Functions with excessive gas cost
• Missing or misused function qualifiers
• Needlessly complex code and contract interactions
• Poor or nonexistent error handling
• Failure to use a withdrawal pattern
• Insufficient validation of the input parameters
• Incorrect handling of cryptographic signatures

Detailed findings

Severity Classification

Security risks are classified as follows:

• Critical: These are issues that we manage to exploit. They compromise the system seriously. They must be fixed immediately.
• Medium: These are potentially exploitable issues. Even though we did not manage to exploit them or their impact is not clear, they might represent a security risk in the near future. We suggest fixing them as soon as possible.
• Minor: These issues represent problems that are relatively small or difficult to take advantage of but can be exploited in combination with other issues. These kinds of issues do not block deployments in production environments. They should be taken into account and be fixed when possible.
• Enhancement: These kinds of findings do not represent a security risk. They are best practices that we suggest to implement.

This classification is summarized in the following table:

SEVERITY	EXPLOITABLE	ROADBLOCK	TO BE FIXED
Critical	Yes	Yes	Immediately
Medium	In the near future	Yes	As soon as possible
Minor	Unlikely	No	Eventually
Enhancement	No	No	Eventually

Critical severity

No issues of critical severity have been found.

Medium severity

No issues of medium severity have been found.

Minor severity

Usage of now in delegateBySig

delegateBySig uses now instead of block number, which may be changed by the miner. This could be used to deny delegation in certain circumstances.
However, it’s unlikely this could be exploited. An improvement to this could be done by using the block number instead of block timestamp.

Enhancements

Uneven usage of safemath

The function getPriorVotes doesn’t use safemath. While we didn’t find that this would inevitably end in overflow, we advise using it. This also happens in doHalvingCheck in Samurai.sol

Conclusion

We found the contract to be straightforward and have an adequate amount of documentation. No real issues were found, neither denial of service nor reentrancy attack in the contracts. 

Disclaimer: This audit report is not a security warranty, investment advice, or an approval of the Katana project since CoinFabrik has not reviewed its platform. Moreover, it does not provide a smart contract code faultlessness guarantee.