Checkout Our Smart contract Audit Process and OxyCoin Audit Report.

We’ve been asked by the Oxycoin team to review and audit their new token code. Here is their unaudited token contract code. We looked at their contract and now publishing our results.

Before writing the results let me tell you in brief about our process of auditing smart contracts. At quillhash , we follow a strategy of verification and validation testing. In verification testing, we perform lots of unit test cases on smart contracts along with the manual testing on every line of the smart contract. After that, we use some automated tools like oyente,mythril,manticore etc to perform several vulnerable attacks on smart contracts.

In the Validation testing phase, we deploy the contract on the ropsten or rinkeby network and ask our team members to use the smart contract for 2,3 days. According to the results of verification and validation testing, we prepare the final audit report.

Also, Read Our Next Article on Security Audit

Checkout Our Smart contract Audit Process and OxyCoin Audit Report 1

Now let come back to oxycoin.

The contract of oxycoin was a simple ERC20 token. However, it was not secure at all. Here are our assessment and recommendations, in order of importance:

High vulnerability issues:-

Integer overflow and underflow:- There are many places where they are not using safe math operations which were highly unsafe.

Arguments checking:- In many functions, they were not checking the function arguments with requiring statements, which allows us to pass negative values in functions like mintTokens() functions.

Medium severity issues:-

Short address attack:- Modifier to check short addresses were not there in the contract.

Arguments checking:- In many functions they were not checking the arguments with require statements which were not directly damaging to contract but that can lead to unnecessary wastage of gas if any user passes some wrong value by mistake.

Low severity issues:-

1. Solidity version should be fixed in smart contracts. For ex:- It should be
pragma solidity 0.4.24 and not pragma solidity ^0.4.24

Final comments:-

Contract should be properly commented. It is not commented at all now. It is advised to comment the code as it is good practice.
Function arguments must be checked with require statement in every function.
SafeMath library functions should be used in every mathematical operation.
. In total supply function _totalSupply. sub(balances[address(0)]); ,the
highlighted sub-operation is unnecessary it can be safely removed.
You can check the unaudited and audited code along with the report in the following github repo.(

Very severe security issues were found. Many changes were recommended to follow best practices and reduce the potential attack surface.

We’re available for smart contract development and security auditing work. You can fill this form to get in touch.

Thanks for reading. Also, do check out our earlier blog posts.

At QuillHash, we understand the Potential of Blockchain and have a good team of developers who can develop any blockchain applications like Smart Contracts, dApps,Smart Coins, DeFi, DEX on the any Blockchain Platform like EthereumEOS and Hyperledger.

To be up to date with our work, Join Our Community :-

Telegram | Twitter | Facebook | LinkedIn