Ну чтож по рассуждаю вот ваши тезисы:
1. На преICO у команды должен быть контракт на автоматический перевод средств с прописанными условиями для ранних инвесторов - не ручками как делают многие а именно прописанный в смарт-контракте - иначе собранные средства могут просто обогатить фаундеров или условия поменяются по ходу пьесы - случаев уйма.
Как умно звучит-то "автоматический перевод средств", а "не ручками как делают многие", Переводов КУДА про это не подумали? и чего городить огород? 2. Контракт на преICO должен быть частью большого контракта на ICO - не разными монетами - это не безопасно с точки зрения уязвимостей и увода средств.
Увеличение сложности системы влечет к резкому увеличению вероятности сбоя. Это даже начинающий должен понимать.
А как увязка двух краудсейл контрактов снижает риски увода средств вообще не раскрыто.3. У контракта на преICO а затем и ICO должен быть прописан нижний и верхний барьер - если этого нет команда не знает чего хочет - просто скам.
Смелое, ни на чем не основанное утверждение юного максималиста, не понимающего что могут быть разные экономики проектов.4. У контракта на ICO должен быть эскроу средсв полученных в результате размещения - это может быть фриз или мультисиг с условием голосования. Это даст Вам гарантию от расходования средств ранее чем команда завершила предыдущий этап.
Нормального механизма сейчас нет, вот умрет ваш эскроу и что дальше? И опять глубокое "должен быть ". Пока я вижу просто не умения оценивать базовые риски. Всегда видно когда люди выходят за пределы своих компетенций. Вы сейчас разработчик дающий советы по эскроу? Вы собственно говоря кто на этом рынке?5. В контракте должен быть прописан безусловный возврат средств в случае не достижения нижней границы собираемого пула. Именно в контракте а не в белой книге если этого нет - скам.
Если она установлена. При этом гению разработки не невдомек что держать средства на контракте - полный идиотизм из-за вероятности бага, взлома, зависания и.т.д. 6. Все контракты должны быть выложены на GitHub это даст возможность сторонним разработчикам проверить контракт на уязвимости если команда не позаботилась и до ICO не выложила баунти на уязвимости.
И много вы проверили контрактов на халяву? 7. В контракте должны быть прописаны условия для команды и для баунти.
Вы такое вообще видели? Какие условия для команды? На весь срок проекта ....вы ощущение с Луны...? Баунти? вы баунти предлагаете в краудсейле прописать
8. В контракте должны быть прописаны условия по не проданным токенам - с четко обозначенными сроками.
В каком? Вы себе представляете перечень условий логику их работы, различные варианты которые возникают? и все это в краудсейле? т.е. и заморозку сюда...увас видимо каша в голове и каша в коде