Eristica Security Audit

HashEx was commissioned by the Eristica team to perform an audit of Eristica ICO smart contracts. The audit was conducted between August 3 and August 10, 2018.

The audited code is located in ContractEristica repository. The version used for this audit report is 26763125bd0b4347e777572cb8a1e6434033d218.

The purpose of this audit was to achieve the following:

  • Ensure that smart contracts function as intended.
  • Identify potential security issues with smart contracts.

Information in this report should be used to understand the risk exposure of smart contracts, and as a guide to improve the security posture of smart contracts by remediating the issues that were identified.

Critical Severity Issues

No critical severity issues were identified in smart contracts.

High Severity Issues


1.Before ownership is transferred from Presale contract owner to EristicaICO contract, Presale contract owner is able to mint additional unlimited number of coins during token sale, regardless of hardcap (Tokens_For_Sale variable). To do that, Presale contract owner can run additional minting of SPERT presale-tokens with function mintToken() of Presale contract, and then Manager account owner of EristicaICO contract should convert them into ERT tokens with function replaceToken(). However, Sold variable, that stores total number of tokens and that is used to check if hardcap was exceeded, stays unchanged. Thus, it is possible to exceed the Tokens_For_Sale hardcap value. It should be noted that this opportunity exists only until the end of token sale, because function replaceToken() can be called only if token sale is not finished (statusICO variable).

Eristica Team note: Flexible conditions for Presale were chosen by design to ensure security and initial risks. The Presale campaign performed in Full Monitoring and Manual mode. In the case of excessing the Hard Cap, function finishIco() would be called manually.

2. According to WhitePaper, presale duration is 45 days and main sale duration is 62 days. However, main sale duration is not limited in the smart contracts. Presale duration is actually limited to the date when function finishIco() is called.

Eristica Team note: For the same reasons, Presale duration was not limited in the smart-contract.

3. According to WhitePaper, 10% of tokens after token sale end are reserved for the Eristica team, where tokens will be locked in a smart contract with a 24-month vesting period, and a 6-month cliff. Smart contracts in this audit do not contain this lock.

Eristica Team note: Team and Challenge fund tokens allocated on dedicated wallets and it’s open for any third parties monitoring. More here.

General Recommendations


  1. Compiler version should be fixed to avoid any potential discrepancies in smart contract behavior caused by different versions of compiler. Line 1.
  2. Implementation of fallback function is redundant, because when funds are transferred to the contract without this function, exception will also be thrown. Line 39.
  3. There is no check against integer overflow when algebraic calculations are made with uint in mintToken() and burnTokens() functions. Lines 57, 64.
  4. We recommend using require(<condition>) instead of if(!condition) throw; for better code readability. Lines 10 , 68.


  1. In ERT token, the decimals variable is specified with uint type. For better compliance to the ERC20 standard, the decimals variable should have uint8 type. Line 190.
  2. We recommend using SafeMath library to protect against integer overflow of uint variables during calculations of function buy(), funciton finishICO(), function setRate(), fallback function. It should be noted that although the risk of uint overflow in these calculations is not high, it is a best practice to introduce protection against integer overflow for any calculations. Lines 69, 102, 126–132, 143.
  3. Tokens_For_Sale hardcap value of 482500000*1e18 is not matched to 687,575,392 specified in WhitePaper. Potentially it implicitly includes also tokens sold on presale. Line 46.
  4. According to WhitePaper, initial token minting will be done before token sale, and unsold tokens will be burnt at the end of the token sale. According to smart contract, however, there is no initial token minting, but tokens are generated with each purchase.
  5. Compiler version should be fixed to avoid any potential discrepancies in smart contract behavior caused by different versions of compiler. Line 1.
  6. We recommend adding index to investor parameter in LogBuyForInvestor and LogReplaceToken events. It would allow to filter logs by investor. Lines 56, 57.
  7. We recommend adding a require() check to function burn() to validate the excess of burnt tokens on user balance. Also, function transfer() and function transferFrom() are missing similar check against cases when functions are called with token transfer amount greater than the user balance. The check would allow to return the unspent gas if conditions are not met. In current function implementation, assertion error exception would be thrown, and that would spend the total gas on transaction. Lines 219, 230, 239.
  8. For correct calculation of token balance by third-party services that use event Transfer() logs, we recommend creating Transfer(msg.sender, address(0), _value) events in function burn(). Line 221.
  9. We recommend adding a check against transfer to 0x0 address in function transfer() and function transferFrom(). This check would allow to avoid accidental burn of tokens by calling these functions with uninitialized _to parameter. Lines 219, 230, 239.
  10. function div(), function sub(), and function add() should be specified as pure functions. Lines 6, 12, 16.
  11. For disambiguation, we recommend explicitly setting function visibility to public for all functions without declared visibility. Lines 5, 14, 30–34, 155, 217, 225, 230, 239, 249, 262.
  12. a == b * c + a % b condition in function div() is met in any case, therefore, it can be omitted. When dividing by 0, exception is thrown, so assert(b > 0) check can also be omitted. It should be additionally noted that this function is not used anywhere in the contracts. Lines 6–11.

Token distribution described on website differs from WhitePaper. WhitePaper states that 70% of tokens will be available for sale, while website specifies 68.07%.


No critical severity issues were identified in the audited smart contracts. Several high severity issues were identified including unlimited token minting during token sale, and discrepancies between smart contract logic and token sale rules outlined in WhitePaper.

Audit includes recommendations on improving the code and preventing potential attacks.

HashEx website:

Connect with me via LinkedIn