The Incent Coffee Token Smart Contract Security Audit

The Incent Coffee smart contract is currently being used to test out the Waves <-> Ethereum block swapper at https://blockswap.incentloyalty.com/. A version of the contract has been deployed to 0x2c875e5ea4706b1978a41b59edf2d3af31d60e70. This contract was written by Bok Consulting Pty Ltd in collaboration with Incent Loyalty Pty Ltd.

I have conducted a security audit on the deployed smart contract, resulting in three recommendation to improve on minor security issues which are:

  • balances[_to] should be checked for overflows in the transfer(...) method.
  • balances[_to] should be checked for overflows in the transferFrom(...) method.
  • The statements in transferFrom(...) should be reordered for additional security

The revised smart contract is listed below the original smart contract.

Other notes:

  • This smart contract does not have a fallback () function that is marked payable. Ethers cannot normally be accidentally sent to this smart contract (except from the selfdestruct opcode.
  • Tokens from other contract may accidentally be sent to this contract. There is no means to transfer these accidentally sent tokens back out from this contract. It would be easy enough to write a method for the owner of this contract to transfer out any ERC20-compliant tokens so it can be returned to the sender, but keeping the code of this contract simple is of more importance.
  • There are no external calls to worry about in this contract.
  • There is no integer division to worry about in this contract.
  • There is no division by zero to worry about in this contract.
  • There could be integer overflow errors in this contract, but it will be impossible when the totalSupply is way way below 2^256 / 2 .
  • There is no potential reentrancy problems as no calls to external addresses or contracts are done.
  • There is no timestamp dependency to worry about in this contract.
  • There is no circuit breaker in this contract. In the worst case the Waves <-> Ethereum block swapper can be halted, and the contract upgraded by issuing a new contract at a different address with the verified token balances transferred over.
  • There are no delayed contract actions or rate limiting features in this contract. This can be implemented in the Waves <-> Ethereum block swapper if necessary.
  • A bug bounty program is recommended for this contract.
  • The reordering of statements in transferFrom(...) is just in case a transaction runs out of gas, but the execution completes. For an example of this case, see https://github.com/bokkypoobah/TheDAOData/blob/master/ExtraBalanceReconciliation.md, where the transaction Tx 0xe290b5d4…. apparently runs out of gas but completes it’s execution.

Other references: Ethereum Contract Security Techniques and Tips.


The Current Contract

Following is the current contract at 0x2c875e5ea4706b1978a41b59edf2d3af31d60e70, with my additional comments prefixed with // CHECK:, and my recommendations prefixed with // RECOMMENDATION: :


The Revised Contract

Here is the revised smart contract that implements the 3 recommendations:

This entry was posted in Blog and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.