Title: HUMANIQ DUE DILIGENCE Post by: ICOcountdown.com on April 11, 2017, 11:37:17 PM https://www.reddit.com/r/ethereum/comments/64ufyp/emission_due_diligence_for_humaniq/
Quote Reference: (Page 10) https://humaniq.co/assets/downloads/humaniq_wp_english.pdf Final Amount determination is excercised here. http://imgur.com/a/vMSRt However smart contract says otherwise: http://imgur.com/a/fFUMZ Reference: https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqToken.sol Token Locking is also excercised and I'm not sure for what reason: http://imgur.com/a/WVacu Reference: https://github.com/humaniq/ico-contract/blob/master/contracts/HumaniqToken.sol This 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.sol As 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.sol have 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-89276d683585 If anyone wants to go further with this due diligence. Please contact me: Telegram: @Alexanderico Email: alex@icocountdown.com Telegram Group: http://telegram.me/icocountdown Title: Re: HUMANIQ DUE DILIGENCE Post by: densmirnov on April 12, 2017, 12:50:26 AM Well, that was detailed! Thus issuees some serious concerns. Anyway, we need to get comments from the team. And let this story be solved as the one with matchpool does before)
Title: Re: HUMANIQ DUE DILIGENCE Post by: ICOcountdown.com on April 12, 2017, 02:22:58 AM Well, that was detailed! Thus issuees some serious concerns. Anyway, we need to get comments from the team. And let this story be solved as the one with matchpool does before) Thank you for the response. I would advise anyone to contact the team and hopefully they address these concerns. Title: Re: HUMANIQ DUE DILIGENCE Post by: blackhawk101 on April 12, 2017, 03:11:14 AM HERE BIG CONCERN, MORON MARKET STRAGIZE
COIN FOR UNBANKED PEOPLES?! OK... WE TRY MARKET 101 --- GIVE FREE COIN (PAPERWALLET) TO BUM, HOBO, UNBANKED STARVE AFRICA ???! GEENIUS Title: Re: HUMANIQ DUE DILIGENCE Post by: aioc on April 12, 2017, 05:27:42 AM Quote 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. I don't like this one I don't know how many coin's admin has done this but dev should make sure that the utmost security should be taken and by only using a single account in ico there's a risk involve if incident like hacking an account,but I would like to know how the dev will handle those issues and concern. |