Советы разработчика инвестору в ICO

[AdamSmitbch]

Здравствуйте уважаемые инвесторы и другие.
Как разработчик смарт-контрактов я не могу смотреть спокойно на беспредел который сейчас твориться на рынке ICO.
Из 100 проектов 99 потенциальный скам.
Примите мои советы как руководство к проверке любого ICO :
1. На преICO у команды должен быть контракт на автоматический перевод средств с прописанными условиями для ранних инвесторов - не ручками как делают многие а именно прописанный в смарт-контракте - иначе собранные средства могут просто обогатить фаундеров или условия поменяются по ходу пьесы - случаев уйма.
2. Контракт на преICO должен быть частью большого контракта на ICO - не разными монетами - это не безопасно с точки зрения уязвимостей и увода средств.
3. У контракта на преICO а затем и ICO должен быть прописан нижний и верхний барьер - если этого нет команда не знает чего хочет - просто скам.
4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.
5. В контракте должен быть прописан безусловный возврат средств в случае не достижения нижней границы собираемого пула. Именно в контракте а не в белой книге если этого нет - скам.
6. Все контракты должны быть выложены на GitHub это даст возможность сторонним разработчикам проверить контракт на уязвимости если команда не позаботилась и до ICO не выложила баунти на уязвимости.
7. В контракте должны быть прописаны условия для команды и для баунти.
8. В контракте должны быть прописаны условия по не проданным токенам - с четко обозначенными сроками.
Мой пост о том что все в конце концов должно иметь стандарт - и вместе мы сможем этого добиться - если Вы не будете вкладывать средства в команды не придерживающихся элементарных стандартов по безопасности - они просто не украдут Ваши деньги.
И было бы странно если бы я не сказал  немного слов о своей команде.
https://bitcointalk.org/index.php?topic=2198612.0
Надеюсь на диалог.

[1714021308]

1714021308

[1714021308]

1714021308

[1714021308]

1714021308

[1714021308]

1714021308

[1714021308]

1714021308

[AdamSmitbch]

Спасибо за советы!
Хотелось бы еще по каждому пункту рассказать как это проверять.

Кидайте ссылку на проект сюда- мы с командой проверим - это самое простое решение.
Если хотите самостоятельно тогда забейте адрес контракта ICO в своем аккаунте в майэфириумвайлет и весь контракт как на ладони)))

[carbon12]

Спасибо. Очень интересная информация.
https://cobinhood.com/

[AdamSmitbch]

Здравствуйте уважаемые инвесторы и другие.
Как разработчик смарт-контрактов я не могу смотреть спокойно на беспредел который сейчас твориться на рынке ICO.
Из 100 проектов 99 потенциальный скам.
Примите мои советы как руководство к проверке любого ICO :
1. На преICO у команды должен быть контракт на автоматический перевод средств с прописанными условиями для ранних инвесторов - не ручками как делают многие а именно прописанный в смарт-контракте - иначе собранные средства могут просто обогатить фаундеров или условия поменяются по ходу пьесы - случаев уйма.
2. Контракт на преICO должен быть частью большого контракта на ICO - не разными монетами - это не безопасно с точки зрения уязвимостей и увода средств.
3. У контракта на преICO а затем и ICO должен быть прописан нижний и верхний барьер - если этого нет команда не знает чего хочет - просто скам.
4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.
5. В контракте должен быть прописан безусловный возврат средств в случае не достижения нижней границы собираемого пула. Именно в контракте а не в белой книге если этого нет - скам.
6. Все контракты должны быть выложены на GithHub это даст возможность сторонним разработчикам проверить контракт на уязвимости если команда не позаботилась и до ICO не выложила баунти на уязвимости.
7. В контракте должны быть прописаны условия для команды и для баунти.
8. В контракте должны быть прописаны условия по не проданным токенам - с четко обозначенными сроками.
Мой пост о том что все в конце концов должно иметь стандарт - и вместе мы сможем этого добиться - если Вы не будете вкладывать средства в команды не придерживающихся элементарных стандартов по безопасности - они просто не украдут Ваши деньги.
И было бы странно если бы я не сказал  немного слов о своей команде.
https://bitcointalk.org/index.php?topic=2198612.0
Надеюсь на диалог.

По пунктам разберем что и где смотреть:
1. Если адрес принимающий средства на пре ICO - это адрес кошелька а не контракта - это можно посмотреть все в том же MEW - первый звоночек звенит красным светом))
 

[Viktor22]

Спасибо за советы!
Хотелось бы еще по каждому пункту рассказать как это проверять.

Кидайте ссылку на проект сюда- мы с командой проверим - это самое простое решение.
Если хотите самостоятельно тогда забейте адрес контракта ICO в своем аккаунте в майэфириумвайлет и весь контракт как на ладони)))

Этих https://startima.io/ проверите?
Хотелось бы в баунти поучаствовать, но опасаюсь что может оказаться скамом как в прошлый раз и не выплатят баунтистам.
И конечно же инвесторы пострадать могут.
Спасибо.

[AdamSmitbch]

Спасибо за советы!
Хотелось бы еще по каждому пункту рассказать как это проверять.

Кидайте ссылку на проект сюда- мы с командой проверим - это самое простое решение.
Если хотите самостоятельно тогда забейте адрес контракта ICO в своем аккаунте в майэфириумвайлет и весь контракт как на ладони)))

Этих https://startima.io/ проверите?
Хотелось бы в баунти поучаствовать, но опасаюсь что может оказаться скамом как в прошлый раз и не выплатят баунтистам.
И конечно же инвесторы пострадать могут.
Спасибо.

Пока не выложили адрес ( кошелька или контракта) говорить о проекте можно только на основе данных в свободном доступе - и вот что немного напрягает на этом этапе - отсутствие упоминания об исходном коде на ГИТХАБЕ. У такого проекта должен быть минимальный продукт - я не нашел))). Делайте вывод самостоятельно - но мой предварительный вывод скам. Обращаю внимание Фаундеров - я ни в коем случае не утверждаю что проект скам но устраните замеченные ошибки и выложите смарт контракты на проверку сообществом - вопросы отпадут сами собой.

Я очень рад что сообщество прислушивается к моим советам - кидайте больше проектов - освободим место для действительно стоящих проектов.
И еще раз обращу внимание - я не оцениваю сам проект я оцениваю риски для инвесторов и баунти участников в связи с корректностью подхода команд к написанию обещаний указанных в белой книге или на сайте - автоматизации возможной с помощью смарт контрактов.
Если у команд есть вопросы к моей компетенции вот мой топик
https://bitcointalk.org/index.php?topic=2198612.0
А вот мой телеграмм:
@johnadamsmit
Обращайтесь.

[Endigoman]

Здравствуйте уважаемые инвесторы и другие.
Как разработчик смарт-контрактов я не могу смотреть спокойно на беспредел который сейчас твориться на рынке ICO.
Из 100 проектов 99 потенциальный скам.
Примите мои советы как руководство к проверке любого ICO :
1. На преICO у команды должен быть контракт на автоматический перевод средств с прописанными условиями для ранних инвесторов - не ручками как делают многие а именно прописанный в смарт-контракте - иначе собранные средства могут просто обогатить фаундеров или условия поменяются по ходу пьесы - случаев уйма.
2. Контракт на преICO должен быть частью большого контракта на ICO - не разными монетами - это не безопасно с точки зрения уязвимостей и увода средств.
3. У контракта на преICO а затем и ICO должен быть прописан нижний и верхний барьер - если этого нет команда не знает чего хочет - просто скам.
4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.
5. В контракте должен быть прописан безусловный возврат средств в случае не достижения нижней границы собираемого пула. Именно в контракте а не в белой книге если этого нет - скам.
6. Все контракты должны быть выложены на GithHub это даст возможность сторонним разработчикам проверить контракт на уязвимости если команда не позаботилась и до ICO не выложила баунти на уязвимости.
7. В контракте должны быть прописаны условия для команды и для баунти.
8. В контракте должны быть прописаны условия по не проданным токенам - с четко обозначенными сроками.
Мой пост о том что все в конце концов должно иметь стандарт - и вместе мы сможем этого добиться - если Вы не будете вкладывать средства в команды не придерживающихся элементарных стандартов по безопасности - они просто не украдут Ваши деньги.
И было бы странно если бы я не сказал  немного слов о своей команде.
https://bitcointalk.org/index.php?topic=2198612.0
Надеюсь на диалог.

Продуктивно, спасибо!

[John White]

Здравствуйте уважаемые инвесторы и другие.
Как разработчик смарт-контрактов я не могу смотреть спокойно на беспредел который сейчас твориться на рынке ICO.
Из 100 проектов 99 потенциальный скам.
Примите мои советы как руководство к проверке любого ICO :
1. На преICO у команды должен быть контракт на автоматический перевод средств с прописанными условиями для ранних инвесторов - не ручками как делают многие а именно прописанный в смарт-контракте - иначе собранные средства могут просто обогатить фаундеров или условия поменяются по ходу пьесы - случаев уйма.
2. Контракт на преICO должен быть частью большого контракта на ICO - не разными монетами - это не безопасно с точки зрения уязвимостей и увода средств.
3. У контракта на преICO а затем и ICO должен быть прописан нижний и верхний барьер - если этого нет команда не знает чего хочет - просто скам.
4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.
5. В контракте должен быть прописан безусловный возврат средств в случае не достижения нижней границы собираемого пула. Именно в контракте а не в белой книге если этого нет - скам.
6. Все контракты должны быть выложены на GithHub это даст возможность сторонним разработчикам проверить контракт на уязвимости если команда не позаботилась и до ICO не выложила баунти на уязвимости.
7. В контракте должны быть прописаны условия для команды и для баунти.
8. В контракте должны быть прописаны условия по не проданным токенам - с четко обозначенными сроками.
Мой пост о том что все в конце концов должно иметь стандарт - и вместе мы сможем этого добиться - если Вы не будете вкладывать средства в команды не придерживающихся элементарных стандартов по безопасности - они просто не украдут Ваши деньги.
И было бы странно если бы я не сказал  немного слов о своей команде.
https://bitcointalk.org/index.php?topic=2198612.0
Надеюсь на диалог.

Ну. Молодец, что еще сказать. В двух словах доступно объяснил на какие вещи действительно стоит обращать внимание. Спасибо.

[AdamSmitbch]

Готовлю развернутый анализ ближайших проектов.

[AdamSmitbch]

Выдержка из статьи которую я скоро размещу здесь и на других ресурсах:
"Предлагаю всем проектам выходящим в ближайшее или не очень время на ICO пройти бесплатное тестирование согласно приведенному выше списку. Если Вы неравнодушны к будущему криптоэкономики и сообщества в целом Вы поймете необходимость данной процедуры – тем белее времени это занимает не много.
В случае отказа от добровольного прохождения мы с командой оставляем за собой право провести эту проверку самостоятельно и результаты выложить в общий  доступ."

[igordata]

4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.

кто будет голосовать?
по какому принципу?
какой этап считать предыдущим?
кто определяет, завершила ли команда его?

7. В контракте должны быть прописаны условия для команды и для баунти.

можешь привести пример?

С остальным яростно согласен.

Ещё интересно услышать твоё мнение по такому вопросу: как обновлять контракт, если косяки всплыли впоследствии?

[AdamSmitbch]

Голосуют ранние инвесторы - они самые нетерпиливые)). Этапы заранее прописываются по времени - что отражено в белой книге.
А сеттеры и геттеры на что?- Это по поводу изменений в контракте.

[igordata]

а как проходит это голосование? расскажи подробнее, пожалуйста. Я про техническую часть.

про геттеры и сеттеры я пока не в курсе что они делают
знаю только, что люди ворчат, если видят, что в контракте можно что-то где-то менять.

[AdamSmitbch]

4. У  контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.

кто будет голосовать?
по какому принципу?
какой этап считать предыдущим?
кто определяет, завершила ли команда его?

7. В контракте должны быть прописаны условия для команды и для баунти.

можешь привести пример?

С остальным яростно согласен.

Ещё интересно услышать твоё мнение по такому вопросу: как обновлять контракт, если косяки всплыли впоследствии?

По пункту 7
 function Crowdsale() {
   multisig = 0xEA15Adb66DC92a4BbCcC8Bf32fd25E2e86a2A770;
        restricted = 0xb3eD172CC64839FB0C0Aa06aa129f402e994e7De;
        restrictedPercent = 40;
        rate = 100000000000000000000;
        start = 1506492000;
        period = 28;
        hardcap = 10000000000000000000000;
    }
    modifier saleIsOn() {
       require(now > start && now < start + period * 1 days);
       _;
    }
Частный случай начисления процентов команде

краудсейл переводит в мультисиг где фриз ограничивает сумму на время .
В момент высвобождения средств они могут быть переведены в кошелек фаундеров если большинство адресов подтвердит транзакцию - так и происходит голосование. Инвесторы хотят получить бонус на свои вложения поэтому затягивать не будут. Но на этот случай есть возможность ограничить количество голосований до 3 переведя высвобожденные средства снова во фриз или поставив на паузу- до момента консенсуса. Все исходники контрактов лежат в библиотеке цепелинов.

[URBO]

выходит, что если нет гитхаба, то это сразу скам?

[AdamSmitbch]

выходит, что если нет гитхаба, то это сразу скам?

Если проект претендует на мои деньги я должен быть уверен что они профессионалы и думают о том как мне их вернуть - должны позаботиться о моем спокойствии. Это ведь так просто - у них есть разработчик у разработчика есть бэкграунд - если нет - скам))).
Я конечно утрирую но если нет кода что команда привносит в блокчейн культуру?

[igordata]

а обязательно она должна что-то привносить в блокчейн культуру именно через гитхаб и исходники смарт-контрактов? это как-то притянуто за уши.

[AdamSmitbch]

Через смарт контракты я как инвестор получаю минимальные гарантии - лучше чем никакие?!
А блокчейн это не легкий способ обогащения а работа с целью изменения существующих схем. По моему каждый проект так или иначе несет это изменение именно это отражается в коде который размещают в гитхабе - кроме скама))).

[igordata]

ну контракт полюбому надо светить и аудитить, это сто процентов.
если ты про этот "вклад" в културу, то да - это несомненно.

с другой стороны, если ты говоришь, что геттеры и сеттеры что-то там могут помочь с обновлением контракта, то и условия могут поменяться. Как быть?
А если контракт нельзя менять, а в нём нашли дыру - тоже как быть?
Нипанятна

[Udjine]

ИМХО

Упомянутый список критериев лишь немного усложняет обман. Или даже наоборот, помогает придать товарный вид. Наводящий вопрос - кто при наличии кода на гитхабе вытягивает байткод опубликованных контрактов, дизассемблирует и проверяет, запаблишили именно тот контракт, ичходники которого выложили, или нет? Ещё один - на сколько реально дорого и сложно реализовать эти "требования", если хочется чужих денег? Так что эти критерии скорее подсказка, как представить проект, чтобы вызвать доверие.

Если речь о серьёзных суммах, то нужны только 2 пункта:
1. В задеплоеном(ных) контракте(ах) лимиты и правила возврата, в случае несоответствия лимитам, должны быть автоматизированы
2. Код физически задеплоеного контракта должен соответствовать представленному.
Всё! Это необходимо и достаточно.

Но это что касается ICO. Далее опять же нужно трезво оценивать и ясно понимать, что не будет гарантии честного и бережливого расхода средств только на проект. По крайней мере, пока все бизнестранзакции не перейдут на блокчейны, а программисты будут получать плату криптовалютами.