А кто может помочь или где можно заказать аудит кода контрактов токена и краудсейл? Видел у некоторых ICO даже выкладывают официальные сертификаты о том что код контракта проверен, хотя те которые видел мне показались какими то поверхностными и направленными больше на то чтобы пустить пыль в глаза потенциальным инвесторам, потому как анализ кода там был типа "warning! keyword constsnt is depricated use view!", а хотелось бы чтоб контракт был проанализирован именно в функциональном и семантическом плане. 

Hello everybody! Are there some common or particular ways to find consultants for ICO. May be somebody have some useful contacts or links to people who can help with searching investors, project audit and consulting, taking organization of roadshow and etc.

Всем доброго времени суток, вопрос по контракту токена. При написании смарт-контракта токена, мне нужно сделать так чтобы на него не было возможности случайно перевести эфиры. Есть ли необходимость писать явную fallback функцию с ревертом, типа:


либо само по себе отсутствие payable fallback функции априори не позволит отправить эфиры на адрес контракта?

Всем доброго времени суток, вопрос по контракту токена. При написании смарт-контракта токена, мне нужно сделать так чтобы на него не было возможности случайно перевести эфиры. Есть ли необходимость писать явную fallback функцию с ревертом, типа:


либо само по себе отсутствие payable fallback функции априори не позволит отправить эфиры на адрес контракта?

So, is there some ways to find such people or contact them by "WeChat" (some famous public communities) for at least to make acquaintances for future communication in person?

It is known that the main part of investmnets for ICO are from China. "WeChat" is very powerful and widespread chinese internet communication tool, so, how to find or attract investors for ICO by "WeChat"?

Mintable это свойство контракта токена уметь эмитировать новые токены. По сути реализовывать функцию Mint.
Просто многие дабы произвести впечатление большей прозрачности и надёжности функцию mint не включают в контракт токена, при деплое токена закладывают изначальное количество (initialSupply) и по окончанию ICO сжигают оставшиеся токены. По сути mintable или burnable это не столько качество самого контракта токена, сколько концепция которой придерживаются при эмиссии токенов при ICO.

А если в данной ситуации для того чтобы контракт мог управлять эмиссией или отправкой просто сделать approve[owner][контракт] = initialSupply а из контракта вызывать transferFrom(owner, нужное количество) или mintFrom(owner, нужное количество)?

Ещё пара вопросов насчет краудсейл контрактов

Читал, что советуют делать по отдельному краудсейл контракту на каждый этап ICO (preSale, preICO, ICO)
Насколько это необходимо и целесообразно?

Как управлять сменой таких краулсейл контрактов, объявлять инвесторам, мол, с такой то даты отправлять эфиры не на этот адрес, а на другой?

Зачем в некоторых примеров краудсейл контрактов пишут что то вроде ERC20 token = new MyToken(), ведь таким образом владельцем токена становится краудсейл контракт, и ты теряешь всякую возможность управления контрактом токена, разве не правильней передавать в конструктор краудсейл контракта адрес токена и уже его там использовать?

Как можно автоматически сжечь токены по окончанию ICO, типа заложить в функционал крайдсейл контракта выполнение какой то процедуры по событию, насколько я знаю solidity такой возможностью не располагает и сжигание в любом случае должен кто-то инициировать?

А ещё вот один вопрос, немного оффтоп, но всё же, распространена ли практика закладывать в контракт токена условия ограничения на обращение до определённой даты или принудительного включения владельцем (запрещаем всем пересылать токены, до например окончания ICO), типа к методам transfer и approve добавляем модификатор canCiculate (require(now > startTime || msg.sender == owner)) Вообще так делается и насолько это имеет смысл, или не имеет?

Спасибо за ссылки, как реализовать Burn, я знаю, под качественно я имел ввиду грамотно написанную чью нибудь уже успешно используюмую реализацию чисто Burnable токена.

А есть примеры ICO с качественно написанным контрактом Burnable токена? Посмотрел на etherscan.io выборочно контракты токенов чисто Burnable не встретил. И вообще есть ли смысл сильно заморачиваться с контрактом токена, просто опять же можно встретить как просто унаследованные от StandartToken так и загромождённые массой дополнительных Mixin контрактов и функций.

Добрый вечер. Вопрос по смарт-контракту эфириум токена. Распространена ли практика ограничивать обращение токенов до определённой даты или непосредственного включения обращения?
Что то типа к функции transfer добавляем модификатор circulationable, который определён, например require(now > startTime || msg.sender == owner)

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

Всем доброго вечера!
Такой вопрос, например, я запускаю ICO, проект на эфириум, токены соответствено тоже, объявляю, что инвестиции принимаю в том числе и в биткоинах.
Если мои токены покупают за эфиры, тут всё очевидно, они erc20 совместимы и инвестор может их покупать используя функционал смарт-контракта токена.
Но немного непонятно, каков конкретный механизм обмена моих токенов на биткоины инвесторов? Как это вообще правильно делается?
(У меня есть несколько идей, как например, продажа/покупка через биржу, либо инвестор просто переводит на мой биткоин-кошелёк биткоины, а я на его эфириум-кошелёк мои токены)