Прежде чем заказывать или писать смарт-контракт

0
1381

Я разработчик и занимаюсь написанием смарт-контрактов для ICO. Заказчики попадаются разные. В основном адекватные, потому как в теме ICO людей с техническим складом ума довольно много. Но конечно бывают и исключения.

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

Я хочу отметить что эти рекомендации не являются жесткими правилами. Иногда проект действительно требует «ухода от канонов». Но в основном большинство проектов можно уложить в эти требования.

    1.  Только ETH. Многие просят обновлять цену токена из-за доллара аргументируя это тем, что цена эфира может упасть. Это не хорошо. Аргументы:
      • Полетит вся система бонусов. Может случится так, что из-за новой цены инвестор, который купил токены на ранней распродаже  — купил их дороже по сравнению с теми инвесторами которые купили позже. Пример — негодование пользователей в Полибиусе. Но  даже там цена не обновлялась, а просто нужна была возможность покупать с карточки фиатными деньгами по фиксированной цене.
      • Для тех у кого эмитированы токены заранее (чего делать плохо — см.следующие пункты) и есть условия распределения токенов не в процентах (см.следующие пукты), а в количестве. Эти условия могут быть не выполнимы или бессмысленны из-за плавающей цены. Например, если заказчик указывает фиксированное количество токенов на баунти. А цена токена плавает. Баунтисты относительно проданных токенов могут получить существенно меньше или больше своих токенов. Что конечно их не обрадует.
      • Увеличение стоимости транзакции и усложнение кода. Как следствие — потенциальные ошибки. Пример — проект Карма и их выводы. У них была ошибка из-за плавающей цены. На одном из митапов они рассказали про свой опыт и ясно дали понять, что с долларом не нужно работать.Как обойти:
        Закладывайте риски в цену в эфире сразу. Например, если сейчас эфир стоит 300, то считайте относительно 270 или 250.Когда и зачем это нужно — исключения: Если у вас есть возможность купить токены за доллары. Например такая возможность была у Полибиуса, но из-за того что цена плавала, инвесторы возмущались.
    2.  Все доли токенов — все в процентах.
      Будь то  баунти, токены основателям, эдвайзерам — все указывайте в процентах. Никогда не указывайте фиксированное количество. Никаких количественных пределов в цифрах.
      Аргументы:Если вы укажите фиксированное количество токенов на баунти, то доля проданных будет плавать относительно баунти. Может получиться так, что баунтисты владеют значительной долей. Тем самым они способны размыть цену.
    3. Халявных токенов (не бонсуных инвесторам) баунтистам и основателям должно быть меньше всего. Исключение — когда токен является долей компании — тут можно оправдать владение 51 процентом.
      Аргументация:Баунтисты, основатели, эдвайзеры — все они не платят за токены. А соответственно они им не дороги. Особенно это касается баунтистов. Они могут просто слить токены по низкой цене, тем самым спровоцировав падение стоимость токена. В отличие от основателей у банутистов нет сильной мотивации не сливать токены.
    4. Не указывайте предел сборов (hardcap) в токенах ! Только в эфире.
      Аргументация:Свой проект вы будете делать за реальные деньги, которые получите конвертируя эфир. Или расплачиваясь эфиром. Но не токенами. А из-за бонусной системы hardcap в токенах будет сложно рассчитать, а иногда и вообще непонятно как считать.
    5. Для заказчиков c большими познаниями в разработке — не стоит использовать «самый новый стандарт». Используйте стандарты, а не черновики. Сейчас стандарт токена ERC20. ERC223 — черновик. И он отнюдь не гарантирует тех преимуществ ради которых ERC223 был сделан. Он может работать только там где все взаимодействующие стороны договорились выполнять ERC223. А таких крайне мало. Однако в порядке исключения вы можете поддержать стандарт.
    6. Понятная система бонусов. Не нагружайте смарт-контракты хитрыми бонусами. В подавляющем большинстве случаев достаточно системы бонусов мотивирующей на время или на сумму или и то и другое. Т.е. мотивация так называемых ранних инвесторов и больших инвесторов. Все остальное это уже фантазии, усложняющие контракт и неприносящее очевидного профита. Также стоит отметить что разбираться в вашей системе бонусов инвестор не желает. Поэтому если не сможет разобраться разработчик, то инвестор и подавно. Делать принципиально разную систему бонусов на presale и ICO и других этапах нет смысла. В конце концов привлечением инвесторов занимается  PR и реклама. Бонусы лишь мотивируют привлеченных инвесторов вложиться раньше и больше.
    7. Не публикуйте точные цифры до окончания написания смарт-контракта или хотябы до согласования ТЗ. Иногда, в процессе написания смарт-контракта или согласования ТЗ выясняется, что заявленное в ТЗ просто нельзя выполнить в смарт-конракте. Или же вообще требования оказываются логически невыполнимы.
    8. Делайте softcap только там где он реально нужен. Я иногда сталкиваюсь с ТЗ в которых заказчики хотят softcap после всех presale, preICO, ICO  и прочих распродажах. Тут отсутствует логика, потому как средства после каждой распродажи начинают осваиваться и их уже не вернуть, а значит и softcap тут бесполезен.
    9. Используйте эмиссию во время распродажи, а не эмитируйте все токены сразу.
      Аргументы:

      • Иногда я слышал такую мотивацию выпустить токены сразу — инвесторы хотят увидеть цифру токенов. Если вы собираетсь сжигать, то в конце ваша цифра токенов никакой смысловой нагрузки не несет и вы вводите в заблуждение инвесторов. Вы можете указать в белой бумаге верхнюю границу. Количество токенов выше которого вы не выпустите.
      • Etherscan не отслеживает события отличные от стандарта ERC20, а значит сжигание токенов никак не отобразится в Etherscan.
      • Если токены эмитированы заранее, то многие процентные расчеты могут быть невыполнимы. Представьте что вы хотите выпустить баунти в процентах в конце ICO, а токены все раскупили. Вы заранее процент баунти не знаете. Технически конечно можно выйти из ситуации. Но это ненужные сложности в контракте (см. следующий пункт)
    10. Не пренебрегайте аргументом — «технически сложнее, можно сделать проще».
      Аргументы:

      • Это в первую очередь повлияет на вас. Чем сложнее контракт тем больше в нем потенциальных ошибок и ситуаций которые вы не учли.
      • Увеличивает сроки разработки и тестирования
      • увеличивает стоимость транзакций при работе с контрактами. Поскольку сейчас ICO проводятся постоянно, то нагрузка на сеть большая и дешевые транзакции уже не пройдут. Пожалейте мелких инвесторов — они по статистике вкладывают в ICO большую часть денег.

Здравая критика и дополнения — приветствуются!