Program Rules

About Company

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.

Scope

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.

What to look for

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 :

• Reentrancy
• Reordering
• Over and under flows
• Attacks on logic (behavior of the code is different from business description)
• Missing access control
• ERC20 Standard Violation
• Time dependencies (30 sec is crucial)
• Randomness issues

The size of rewards

We appreciate your efforts in taking out time and pointing it out to Enecuum Team, it helps us be better in our approach.

• Only vulnerabilities which can lead to real issues are covered by the bug bounty program.
• However, it’s entirely at Enecuum Team discretion to decide whether a bug is significant enough to be eligible for reward.
• In special cases, the size of the award can be increased if the researchers demonstrate how the vulnerability can be used to inflict maximum harm.

Enecuum Team is highly interested in 2 types of vulnerabilities:

1) Tier 1 - prize fund is 11881 USDT(TRC-20)

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 7920 USDT(TRC-20)

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.

Out-of-Scope

In general, the following vulnerabilities do not correspond to the severity threshold:

• Old compiler version
• Compiler version is not locked
• Vulnerabilities in imported contracts
• Code style guide violations
• Redundant code
• Gas optimizations
• Obsolete solidity constructions

Smart Contracts Info

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:

• the sender address is whitelisted [the logic is implemented in the WhitelistedCrowdsale contract]
• the hardcap isn’t reached [the logic is implemented in the CappedCrowdsale contract]
• the sender doesn’t contribute more than the individual cap [the logic implemented in the IndividuallyCappedCrowdsale contract]
• the PrivateSale isn’t paused [the logic is implemented in the PausableCrowdsale contract]

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:

• the URL (in Oraclize format, to get actual fiat/eth rate)
• Scale (of fiat price)
• Delay (of recursive Oraclize query)
• Gas Price (for Oraclize query)
• Gas Limit (for Oraclize query)

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).