This needs to be addressed:
https://www.reddit.com/r/ethereum/comments/64ufyp/emission_due_diligence_for_humaniq/
Reference: (Page 10)
https://humaniq.co/assets/downloads/humaniq_wp_english.pdfFinal Amount determination is excercised here.
http://imgur.com/a/vMSRtHowever smart contract says otherwise:
http://imgur.com/a/fFUMZReference:
https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqToken.solToken Locking is also excercised and I'm not sure for what reason:
http://imgur.com/a/WVacuReference:
https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqToken.solThis has been delisted from ICOcountdown.com until further notice.
Extra due diligence done by Jack from ICOcountdown Telegram:
Okay, where do I start? As first - there are no critical vulnurabilites, like 0-day or something like that, so nobody in perspective could hack the contract and get out whole funds or something, but it is still have some malicious functions, which I will describe.
https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqToken.solAs first - look at line 88 /// @dev Function to change address that is allowed to do emission. /// @param newAddress Address of new emission contract. function changeEmissionContractAddress(address newAddress) external onlyFounder returns (bool) { emissionContractAddress = newAddress; }
it is mean that they can set any new contract in here in any time and get infinite emitient at they will. Plus, as we see, it can be not just another crowdsale contract, it could be literally any address, which means that they can set me as emissionContract and I can mint myself as many tokens as I want. And in fact it is malicious.
This problem could be solved by different ways, for example you can set iterator of changing emissionContract and set the final number of all future ways of crowdfunding rounds - in this case you can do, for example, 3 rounds of crowdfunding and emission waves but no more.
Other simple proposal to solve this problem - is specifiy type of emissionContract, therefore people can see that only real crowdfunding contract could emit new tokens and no one else could.
Locker problem. In fact, when you proceed your ICO you should forbid your buyers to transfer tokens before ICO ends - it is okay. In this case you can firstly set a phase modifiers in enum format like enum ICOPhase { Created, Running, Paused, End } and change state of the contract when it handle some events, or it can be just simple boolean modifier like lock = true In conract of Humaniq it can be found on 42 line (modifier), and this modifier lock ALL transfers of token (line 73,80).
You could say - okay, so what is problem? The problem in that their token contract have function on line 98 function lock(bool value) external onlyFounder { locked = value; } Which allow developers to lock all transactions manually in any time.
I repeat - it is not holding the ico contract, which could be useful in some kind of situation, it is lock all tokens transfer and could be used in any times even when ico is done.
When I've asked developers - why do they need this functions and why they need to use it exactly this way - in any time and not only an ICO - they have answered to me, that "it is need to migrate. when we will create new tokens contract - we will block old one".
Yes, that is exactly they have said, that they will just block old contracts with all balances when they developed new contract of token's. And that how we finde another problem.
Migrate function is actually doesn't exist. As you know - all balances in token contract is stored in mapping structure and you cannot just pull it out from contract - you need to use getter to get value of balance of specific address.
So, as I supposed, they must have some migrate function (or at least prototype of it) which allow them to secure transfer balances from one contract to another. It is a pretty difficult mechanism of two-sides function which must be work on both contracts - ask old one of balance of msg.sender, add this value to balance of new contract and delete same number from old balance - in this case user could choose themself migrate to new contract or not, plus, such desicion allow continue normally work of each contract without blackmailing.
What I have heard from developers - they said that "we will not transfer balances in smart-contract logic at all, we will have non such migrate function" - but wait, it is not even possible to do offchain cause of balances data structure - I mean really - I think many developers tryed to pull out mappings, and we are all know, that there is impossible without using of getter, and moreover - you can't do it without knowing of each key of user... so how they actually want to do this?
And all of it just for humaniq token itself and not for ICO contract.
ICO contract -
https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqICO.solhave also such function as function changeTokenAddress(address token_address) at 201 line - which is really strange thing. I don't even know how to comment it. It's like they can change token contract address in the middle of ICO and so will crowdfund two token contracts? Totally mess, I'm really don't know for what this need and how it could be exploited, it could be a real chaos with such things.
Founder's address Common problem - ico is managed by single account but not of DAO or multisig - have a possability that if key from single account will be stolen - all funds will be stolen as well.
Further Data:
https://medium.com/@classicether/soundchain-dapp-reveal-raises-red-flags-89276d683585If anyone wants to go further with this due diligence. Please contact me:
Telegram: @Alexanderico
Email:
alex@icocountdown.comTelegram Group:
http://telegram.me/icocountdown
