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

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

Путь предложения: от черновика до исполнения

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

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

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

Структура текста

  1. Заголовок и краткое изложение. Три-четыре строки, из которых понятно, что меняется и зачем.
  2. Проблема. Данные и даты, а не оценки: что происходит сейчас, с какого момента, в каких числах.
  3. Суть изменения. Точные параметры: адреса, значения, сроки. Формулировка должна читаться однозначно.
  4. Обоснование. Расчёт выгоды и ссылки на источники, включая обсуждение черновика.
  5. Издержки и риски. Расход средств сообщества, работа исполнителей, что будет при отказе.
  6. План исполнения. Кто делает, в какие сроки, как проверить результат.
  7. Варианты голосования: за, против, воздержаться — и что означает каждый исход.
Схема из пяти шагов: черновик в открытой ветке, предварительный опрос о настроении, проверка порога внесения и кворума, формальное внесение текста, исполнение после задержки
Схема из пяти шагов: черновик в открытой ветке, предварительный опрос о настроении, проверка порога внесения и кворума, формальное внесение текста, исполнение после задержки

Порог поддержки и сроки обсуждения

Четыре параметра решают судьбу предложения, и все четыре заданы в контракте. Документация OpenZeppelin на 17 октября 2026 года описывает их так: задержка перед началом голосования, длительность голосования, порог для внесения предложения и кворум как доля от общего выпуска токена. Отсчёт идёт в блоках либо во времени — контракт определяет режим по токену сам.

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

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

Что публикуют вместе с предложением

Для машинного чтения сложился отдельный стандарт. Черновик ERC-4824 от 17 февраля 2022 года — он до сих пор проходит рецензирование — задаёт набор адресов, по которым сообщество публикует свои данные: список участников, список предложений, журнал действий, документацию по управлению, перечень контрактов. Автору это полезно как перечень того, чего не хватает в собственном тексте.

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

Чего предложение не должно содержать

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

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

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

Чек-лист перед внесением

  • Черновик обсуждён в открытой ветке, возражения учтены
  • Порог внесения и кворум проверены в параметрах контракта
  • Сроки задержки и голосования посчитаны в блоках или датах
  • Формулировка изменения однозначна: адреса, значения, сроки
  • Издержки и риски названы числами
  • Интерес автора раскрыт
  • План исполнения и способ проверки результата описаны
  • Ссылки на ветку обсуждения и свои прошлые голосования собраны в таблице активностей

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

Можно ли править предложение после внесения?

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

Сколько длится голосование?

Зависит от настроек сообщества. В примерах документации OpenZeppelin задержка перед голосованием указана как 7200 блоков, то есть примерно сутки, а длительность голосования — 50 400 блоков, около недели. Свои значения смотрят в контракте: единого правила для всех сообществ нет.

Что делать, если не хватает голосов для внесения?

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

Нужен ли технический текст изменения?

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

Материалы по теме

Первоисточники: документация OpenZeppelin по контракту управления и черновик стандарта ERC-4824.

Вердикт

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

Разборы голосований и предложений сообществ — в нашем канале: t.me/cryptium_ru.