Токен с выплатами держателям: что я предложил изменить в чужой архитектуре

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

Что было в запросе

Задача: выпустить токен, держатели которого регулярно получают выплаты в стабильной монете. Заказчик прислал своё видение. Собственная программа на блокчейне, проверка личности через перехватчик переводов, снимок держателей и раздача по дереву Меркла, пять этапов работ.

Видение грамотное, человек разбирается в предмете. Но в трёх местах решения выбраны из соображений элегантности, а не выживаемости проекта. Про них и написал.

Первое: не писать свою программу на старте

Собственная программа на блокчейне — это всегда собственный аудит. Аудит стоит дороже разработки и занимает время, а до него код не имеет права держать чужие деньги.

Есть готовые открытые механизмы раздачи по дереву Меркла. Они проверены и уже прошли аудит. Для проверки гипотезы их достаточно: механика выплат будет та же, а дорогой аудит собственного кода откладывается до момента, когда в проекте появятся реальные деньги.

Обратная сторона названа прямо: готовый механизм ограничивает в нестандартных правилах. Если выплаты придётся считать по сложной формуле прямо в блокчейне, своё писать всё равно придётся. Но это решение лучше принимать, увидев первые выплаты.

Второе: проверка личности состоянием аккаунта

В присланной архитектуре проверка личности сделана через перехватчик переводов: каждый перевод проходит через дополнительную программу, которая смотрит, прошёл ли получатель проверку.

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

Предложил другой механизм: состояние аккаунта по умолчанию. Новые аккаунты создаются замороженными и размораживаются после проверки. Это стандартная возможность, её понимают и биржи, и кошельки, отдельного кода она не требует.

У этого решения есть цена, и я назвал её прямо, а не спрятал в примечание. Право заморозки остаётся у эмитента. Публичного пула на бирже не будет. Об этом инвесторам надо говорить заранее, до того как они купили. Ограничение, о котором сказали честно, проект переживает. Ограничение, вскрывшееся после покупки, заканчивается претензиями.

Третье: снимок держателей — самое уязвимое место

Снимок выглядит простой операцией: зафиксировали, кто сколько держит, посчитали доли, раздали. Именно здесь каждая мелочь превращается в спор с держателями. Перечислил шесть дыр.

Токены в эскроу вестинга. Они формально не на адресе держателя. Решение о том, участвуют они в распределении или нет, надо принять заранее и записать, иначе после первой выплаты начнётся выяснение.

Покупка за минуту до снимка. Если момент снимка известен, его будут использовать: купить перед, получить выплату, продать после. Нужно правило, которое это обесценивает, — например, усреднение за период вместо одной точки.

Казначейские адреса. Токены проекта, лежащие в его собственном резерве, нельзя включать в делитель. Иначе проект платит сам себе, а доля настоящих держателей размывается.

Срок получения выплаты. Часть людей не придёт за деньгами никогда. Надо заранее решить, сколько ждать и что делать с невостребованным: возвращать в фонд, переносить в следующий период или оставлять доступным бессрочно.

Монета на комиссию сети. Чтобы забрать выплату, получателю нужно немного основной монеты сети на комиссию. У новичка её может не быть, и он физически не сможет получить своё. Это надо предусмотреть.

Публикация списка адресов. Корень дерева публикуется в блокчейне, но без исходного списка его никто не перепроверит. Список надо выкладывать: это единственный способ дать держателям проверить расчёт самостоятельно.

Юридическая часть, которую нельзя отложить

Отдельным разделом написал жёстко: смарт-контракт сам по себе ничего не обещает. Код исполняет то, что в него заложили, но обещание регулярных выплат — это обязательство, и живёт оно в юридических документах, а не в коде.

В России такие инструменты попадают под закон о цифровых финансовых активах и требуют оператора из реестра. В США к подобным конструкциям применяется тест Хоуи, и его результат определяет, чем токен является для регулятора.

Вывод простой: заключение юриста нужно до запуска в основную сеть. Разработка под конструкцию, которую потом признают неподходящей, выбрасывается целиком.

Что не входит в цену

Отдельный раздел предложения — про то, за что я не отвечаю и что заказчик оплачивает сам. Это дороже самой разработки. Если не сказать сразу, разговор рано или поздно закончится скандалом.

Этот раздел неприятно и писать, и читать. Но он превращает предложение из рекламной бумаги в документ, по которому можно планировать бюджет.

Этапы: начинать с дешёвого «да»

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

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

Оформил всё в PDF с обложкой и колонтитулами. Такой документ пересылают дальше, показывают партнёрам и юристам, и вид влияет на то, дочитают ли его до раздела с ограничениями.

Частые вопросы

Не отпугнёт ли заказчика такой честный разбор?

Может отпугнуть, и это нормальный исход. Заказчик, которому нужно только согласие, всё равно приведёт к конфликту на середине работ. Тому, кому нужен результат, названные ограничения показывают, что подрядчик понимает предмет.

Почему нельзя просто разослать выплаты всем адресам?

Прямая рассылка означает комиссию за каждый перевод и растёт вместе с числом держателей. Раздача по дереву Меркла переносит эту работу на получателя: он забирает сам, и проект платит только за публикацию корня.

Замороженные по умолчанию аккаунты — это не отпугнёт держателей?

Отпугнёт часть из них, и это надо принять как условие задачи. Инструмент с обязательной проверкой личности по определению не для анонимной аудитории. Важно только одно: сказать об этом до покупки, а не после.

Можно ли обойтись без проверки личности вообще?

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

Зачем публиковать список адресов, если корень уже в блокчейне?

Корень доказывает, что список не менялся после публикации, но не показывает, что в нём. Без исходных данных держатель не может убедиться, что его доля посчитана правильно. Публикация списка — это то, что делает расчёт проверяемым.

Коротко о главном

В предложении важнее всего честно назвать границы работ и риски, а не красиво описать технологию. Красивое описание выигрывает первый разговор и проигрывает третий, когда всплывает то, о чём не сказали.

Технически разбор свёлся к трём заменам: готовый механизм раздачи вместо собственной программы, состояние аккаунта вместо перехватчика переводов и закрытые дыры в снимке держателей. Каждое решение с названной обратной стороной.

Если у вас есть готовая архитектура и нужен взгляд со стороны до начала работ — пришлите её описание. Разберу по частям и скажу, где она сломается и что это будет стоить. Напишите в Telegram, MAX или VK.