Тест на скам от разработчика смарт контрактов

0
1660

Уважаемые члены криптосообщества хочу обратиться к Вам от лица команды разработчиков с предложением по поводу необходимости введения стандартизации выхода проектов на ICO.

Немного о нашем видении:

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

Коду написанному в открытой среде с возможностью простой и быстрой проверки любым членом сообщества. Наше предложение касается проектов использующих платформу Ethereum  для первичной эмиссии токенов ( публичных обещаний) своих проектов. Смарт контракты достигли такого уровня доверия и безопасности, что сообщество уже готово к таким переменам. Мы призываем разработчиков и всех неравнодушных присоединиться к нашему обращению – проектов реально нужных блокчейн среде катастрофически мало  и в ворохе скам проектов найти их все сложнее и сложнее.

Наша инициатива касается стандартизации выхода команд на ICO в области обеспечения минимальных гарантий безопасности средств инвесторов поверивших в проект:

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

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

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

Уважаемые участники сообщества призываем вас активно участвовать в данной инициативе — сообщайте о проектах которые Вы желаете проверить – мы сделаем это максимально быстро и корректно отправив результат фаундерам для исправления.

Кроме защиты интересов инвесторов наша инициатива  поможет участникам баунти программ более уверенно предлагать свое время ведь условия будут прописаны не зависимо от фаундеров, а значит эффективность и полезность для сообщества и для Вас лично проектов которые вы продвигаете возрастет .

Хочу объяснить почему именно эти пункты выделены мной в качестве реперных и расскажу на что нужно обращать внимание если вы решили провести проверку самостоятельно:

Пункт 1.

Если команда принимает средства на личный кошелек то это говорит как минимум о неуважении к инвесторам  и непрофессионализме команды — как следствие об отсутствии компетенций в технологии в которой они пытаются получить средства, а как максимум о неуверенности в жизнеспособности идеи – как правило на этом этапе у команды больше ничего нет ( и это нормально).

Риски:

  1. Собрав меньше минимума команда не ограниченная ничем кроме норм воспитания уйдет в рассвет помахав ручкой оставив инвесторов и баунти команду в унынии.
  2. Собрав столько сколько нужно ничего не мешает воспользоваться верхним сценарием.
  3. Неадекватная оценка мер безопасности принятых для сохранения средств ранних инвесторов и участников баунти.
  4. Изменение цены токена относительно первоначальных обещаний – как будет позволять тот же уровень воспитанности.
  5. Курсовые потери.
  6. Репутационные риски.

Вывод: Автоматизация данного этапа приведет как минимум к уменьшению потерь а как максимум охладит пыл мошенников.

Пункт 2.

Если контракт на пре-ICO является частью контракта на ICO ищите в теле контракта поле SaleAgent – именно оно говорит о единой монете.

Пункт 3 и 5

Ищите переменные softcap и hardcap первая говорит о нижней границе – вторая о верхней их отсутствие в контрактах ICO и пре ICO говорит о слабом представлении командой целей и необходимых средств на их достижение.

За автоматизацию возврата отвечает функция refund – именно ее вы вызываете когда команда не собрала нижней границы для возврата собственных средств обратите внимание что средства возвращаются за минусом затрат на проведение транзакции.

Пункт 4

Ищите в основном контракте подконтракты с именами FREEZE и Multisig

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

Цикл повторяется столько раз сколько  этапов заявлено в контракте фриз и соответственно в белой книге проекта.

По пункту 7 напишу отдельную статью.

Пункт 8.

Ищете отдельный контракт с именем  Burn, в нем прописываются условия уничтожения непроданных токенов.

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

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here