Enecuum - the world's first and only blockchain platform with the possibility of mobile mining. Enecuum uses a hybrid consensus algorithm. Its mining component is based on an improved version of Bitcoin-NG which allows for the mining of many different network blocks in parallel. The platform is optimized for building business applications focused on solving practical problems, including those from the real sector of the economy. Security is one of the key standards that the Enecuum team is guided by. That’s why Enecuum is launching 1-week bug bounty program, from July 16th till July 23rd, to test their smart contracts.
ENQ is based on the ERC20 token, MultiSig Wallet (by Gnosis) and some utilitarian contracts. All contracts use the latest stable version of the Solidity language (except dependencies, which we can’t control) and have passed internal tests and audits.
Smart contracts from the scope are listed here: https://github.com/633kh4ck/enq-ico
The scope is limited ONLY to smart contracts.
Note that contract ICO.sol is not compilable because of graph linearization issues in OpenZeppelin contract, which can't change be changed by Enecuum team (but they inherit from it), thus, team is patching the issue locally for compilation.In order to compile contract you also need to make local patch - change inheritance order in Whitelist.sol.
We are looking for an evidence and reasons of incorrect behavior of the smart contract, which could cause unintended functionality. We are interested in the following vulnerabilities that can lead to scenarios from Tier 1, Tier 2 :
We appreciate your efforts in taking out time and pointing it out to Enecuum Team, it helps us be better in our approach.
Enecuum Team is highly interested in 2 types of vulnerabilities:
1) Tier 1 - prize fund is 47286 HKN
Vulnerabilities that lead to loss of value (tokens or broadcast) or that provide an ability for an intruder to steal legitimate users’ funds.
2) Tier 2 - prize fund is 31524 HKN
Vulnerabilities that do not lead to a loss of value (tokens or broadcasts), but which can lead to errors that block users’ funds and so on.
The prize fund of 20,000 USD is a common prize fund and it will be distributed among those who find unique vulnerabilities in Enecuum smart contracts. If no one can find any vulnerabilities, this prize fund will be donated to the educational program to study blockchain or blockchain hackathon.
In general, the following vulnerabilities do not correspond to the severity threshold:
A Token smart contract implements the ERC20 standard and extends it to be burnable (useful for future migration to one’s own blockchain), pausable (useful for force majeure situations) and capped (we can’t mint more tokens than the defined hard cap). During the process of initialization, it accepts the address of the beneficiary wallet for initial supply (a multisig wallet address in our case). The token name, its symbol, the number of decimals and the cap are hardcoded.
A Crowdsale (private sale) smart contract implements and extends the following interfaces and contracts: MintedCrowdsale, CappedCrowdsale, IndividuallyCappedCrowdsale, FinalizableCrowdsale, WhitelistedCrowdsale, PausableCrowdsale, and FiatCrowdsale. Most of these come from the OpenZeppelin framework and were actually developed by the Zeppelin team, and some of them were developed by us. The contract accepts payments in ETH (formally USD, the FiatCrowdsale contract does it’s magic via Oraclize and converts wei to cents) and checks to ensure that:
Then it interacts with the Token contract to mint tokens, deploy the TokenVesting contract for the sender (if it does not already exist), and then it transfers tokens to the TokenVesting contract.
After that, it sends the deposited ETH to the MultiSig Wallet.
Every four hours this contract will be called by Oraclize (blockchain oracle service) contract to perform an automatic fiat/ETH rate update (exchange rate). The invested wei will be converted to cents automatically, because all of params are stored in cents in the smart contract [this logic implemented in the FiatCrowdsale contract]. In the process of initialisation, it accepts:
It implements some useful methods to change params. No hardcoded data.
The Wallet contract fully implements the multisignature wallet with daily limit by Gnosis, and it can be extended to implement some additional features in the future releases.
The TokenVesting contract is a token holder that can release its token balance gradually like a typical vesting scheme, with a cliff and vesting period; it fully implements TokenVesting by the OpenZeppelin team.
All contracts have several system functions to perform administrative management, which will not be discussed in this document.
Hint: all the links in the flowchart demonstrate not only the interaction between contracts, but also administrative capabilities (thus, the MultiSig Wallet can’t directly interact with the TokenVesting or Token contracts and so on).
Contact us if you want more information.