Security is one of the key standards that the Enecuum team is guided by. So today we are announcing the launch of a great Bug-Bounty program with a total prize fund of US $20,000 *!
A team of professionals worked on the creation of our smart contracts and we are confident of their security and safety. However, as they say, “one head is good, but two is better.”
We invite all interested participants to try and find possible vulnerabilities in our smart contracts. And we are ready to pay for it!
Here are the basic rules of participation in this campaign:
1. The remuneration will be executed on the basis of 2 levels:
- Tier 1, $ 12,000 *.
One must find a vulnerability in the security system that will lead to loss of value (tokens or broadcast) or that provides the ability for an intruder to steal legitimate users’ funds.
- Tier 2, $ 8,000
One must find a security vulnerability that does not lead to a loss of value (tokens or broadcasts), but which can lead to errors that block users’ funds, and so on.
2. No ‘minor corrections’ or ‘recommendations for improving efficiency’ can be considered as a qualifying error.
3. The prize fund of $ 20,000 is a common prize fund and will be distributed among those who find the vulnerabilities of smart contracts. In the event that no one can find any vulnerabilities, this prize fund money will be donated to the educational program to study the blockchain or blockchain hackathon.
4. The organization and execution of the bug-bounty program and distribution of funds for remunerations remains at the discretion of the Enecuum Team.
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.
Under the Hood
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).
* The winner will receive the equivalent in ENQ tokens (1 ENQ = $0,04) in accordance with the terms of tokensale terms and conditions. Tokens will be awarded to the winners according to the General conditions of the token sale.