Как выбрать подрядчика по смарт-контрактам: 12 красных флагов

Хорошего подрядчика по смарт-контрактам отличает не красивое портфолио, а то, как он говорит о рисках: кто будет держать ключи, что будет при ошибке, как проходит аудит и кто отвечает после запуска. Если исполнитель обещает «безопасный контракт за неделю» и не задаёт вопросов про роли и деньги, ищите дальше. Ниже — красные флаги, вопросы для отбора и пункты договора.

Общие правила выбора подрядчика на разработку мы разбирали в статье как выбрать подрядчика и не попасть. Здесь — то, что специфично для блокчейна, где ошибку в развёрнутом коде часто нельзя исправить.

Красные флаги

Вопросы для первой встречи

1. Какие контракты из вашего портфолио сейчас работают в сети? Дайте адреса и ссылки на исходники.
2. Кто их проверял внешне? Покажите отчёты и что было исправлено.
3. Как вы тестируете: модульные тесты, тесты отказов, фаззинг, тесты на форке сети?
4. Как вы предлагаете распределить роли администратора и паузы?
5. Что вы делаете, если после запуска находится ошибка?
6. Что входит в передачу проекта: репозиторий, скрипты деплоя, документация, доступы?
7. Кто конкретно будет писать код и кто его проверит внутри?

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

Что прописать в договоре

• Права на исходный код переходят заказчику; репозиторий на аккаунте заказчика.
• Результат — не только контракт, но и тесты, скрипты деплоя, документация по ролям.
• Все административные роли при деплое назначаются на адреса заказчика, лучше на мультиподпись.
• Внешний аудит — отдельный этап; исполнитель исправляет находки в рамках договора.
• Порядок приёмки: тестовая сеть, сценарии, подписание акта.
• Гарантийный период и порядок реагирования на найденные ошибки.
• Конфиденциальность: исполнитель не хранит ключи и не публикует детали до запуска.

Как принимать работу

1. Разверните контракты в тестовой сети по скриптам из репозитория сами или руками другого разработчика.
2. Пройдите основные сценарии через интерфейс и через прямые вызовы.
3. Проверьте, что все роли назначены на ваши адреса и что у исполнителя не осталось прав.
4. Сверьте код в репозитории с тем, что прошёл аудит: коммит должен совпадать.
5. Проверьте документацию: сможет ли другая команда продолжить работу по ней.
6. Только после этого — деплой в основную сеть и подписание акта.

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

Как сравнивать коммерческие предложения

Как читать сметы вообще — в статье смета на разработку: как читать КП. Бриф для запроса предложений можно собрать в генераторе брифа.

Тестовое задание: стоит ли просить

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

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

Как проверить, что код в сети тот же, что в репозитории

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

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

Зелёные флаги: что говорит в пользу исполнителя

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

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

Где мы можем помочь

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