Предложение GEP-02: Введение децентрализованной системы вознаграждения участников голосований и компенсации комиссий

GEP-02: Введение децентрализованной системы вознаграждения участников голосований и компенсации комиссий

Краткое описание

Предложение по внедрению механизма ежеквартального поощрения активных пользователей платформы «Голос». За каждое участие в голосовании (отправку транзакции с выбором варианта) на адрес участника начисляется 1 жетон «Благо» и компенсация в TON для покрытия сетевых издержек. Выплаты осуществляются децентрализованно через мультикошелек ДАО Градосфера.

Цели

  • Повышение мотивации сообщества к активному участию в жизни платформы.
  • Стабилизация достижения необходимого кворума (не менее 2/3 голосов).
  • Снижение финансовых барьеров для пользователей за счет компенсации газа в сети TON.

Текущая проблема

Для принятия легитимных решений на платформе «Голос» установлен строгий кворум — не менее 2/3 от общего числа голосов за один из вариантов. В настоящее время пользователи самостоятельно оплачивают сетевую комиссию в размере ~0.01 TON за каждую транзакцию голосования. Отсутствие материального стимула в сочетании с прямыми расходами снижает явку избирателей, что затягивает утверждение важных инициатив.

Предлагаемое решение

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

  • Жетоны «Благо»: Начисление 1 жетона за каждый отданный голос. 1 жетон «Благо» эквивалентен 1 часу волонтерской помощи внутри экосистемы.
  • Компенсация TON: Отправка TON на адреса проголосовавших для полного покрытия комиссий (0.01 TON за транзакцию), затраченных на прошлые голосования.

Формула расчета квартального пула наград

Для предотвращения неконтролируемой эмиссии и планирования бюджета фонда мультикошелька устанавливается жесткий лимит максимального квартального пула наград (Pool_{max}).

Расчет фонда на один квартал производится по следующим формулам:

1. Пул жетонов «Благо»

Pool_{Благо} = N_{votes} \times 1 \text{ Благо}

2. Пул компенсации TON

Pool_{TON} = (N_{votes} \times Fee_{vote}) + Fee_{distrib}Где:

  • N_{votes} — фактическое суммарное количество учтенных адресов во всех завершенных голосованиях за отчетный квартал.
  • Fee_{vote} — фиксированная стоимость транзакции голосования для пользователя (0.01 \text{ TON}).
  • Fee_{distrib} — закладываемый резерв на оплату газа для самой процедуры массовой мультиотправки наград с мультикошелька.

Максимальный возможный объем фонда (Pool_{max}) ограничен предельным количеством официальных голосований, которые физически могут быть проведены платформой за 3 месяца (V_{max}), и общим числом верифицированных участников (U).

Механизм управления и распределения

  • Децентрализованный фонд: Средства на вознаграждения аккумулируются на специальном мультикошельке, где принимаются коллегиальные решения о создании и наполнении фонда наград.
  • Защита от централизации: Кошелек управляется по схеме 3 из 5. Каждая транзакция по выделению средств требует подписи минимум троих независимых владельцев ключей, что исключает единоличное управление бюджетом.
  • Периодичность выплат: Начисление наград и компенсаций происходит фиксированно один раз в квартал.
  • Оптимизация расходов: Распределение запускается строго после утверждения квартального бюджета. Для минимизации издержек используется механизм массовой отправки (упаковка множества транзакций в один пакет), что существенно экономит TON на оплату газа при дистрибуции.

Риски и меры защиты (Анти-Сибил / Защита от накрутки)

Введение материального поощрения создает риск атаки Сибилы (создание множества пустых кошельков одним пользователем для искусственного увеличения количества голосов и получения наград). Для защиты платформы вводятся следующие правила:

  1. Критерий минимального баланса: Награда и компенсация TON начисляются только на те адреса, чей баланс токенов управления платформы составляет не менее 10 TON (или эквивалентного количества токенов управления «Голос») на момент фиксации блока голосования. Пустые или созданные непосредственно перед голосованием кошельки исключаются (снимок состояния на момент голосования по каждому предложению).
  2. Исключение дубликатов: Если смарт-контракт фиксирует создание серии транзакций с пересекающимися исходными средствами или от одного и того же провайдера ликвидности (без прохождения уникальной идентификации), такие адреса исключаются из списка на выплату решением владельцев мультикошелька ДАО (3 из 5).
  3. Лимит на одно голосование: Один уникальный пользователь (даже при наличии нескольких суб-кошельков) может получить не более 1 награды за одно конкретное голосование. Разделение веса голоса на несколько транзакций не увеличивает итоговую награду.

Публичный аудит списков

Для обеспечения полной прозрачности и исключения ошибок перед непосредственной отправкой жетонов вводится обязательный этап проверки:

  • Публикация реестра: В конце каждого квартала сформированный список адресов-получателей и сумм начислений выкладывается в открытый доступ (GitHub-репозиторий платформы и официальные каналы сообщества).
  • Период рецензирования: Сообществу предоставляется 7 календарных дней на аудит реестра. Любой участник может оспорить список, указав на пропущенный адрес или замеченную аномалию (признаки накрутки).
  • Утверждение: Мультисиг-активация транзакции (сбор 3 из 5 подписей) происходит строго после истечения аудиторского окна и устранения подтвержденных разногласий.

Техническая реализация

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

Ожидаемый эффект

  • Стабильный рост явки избирателей до целевого уровня кворума (66.6%+).
  • Повышение ценности токена «Благо» за счет его привязки к реальной полезной активности на платформе.
  • Формирование нулевой стоимости участия в управлении платформой для конечных пользователей.

Сроки и этапы

  1. Разработка логики распределения и аудит: 5 дней.
  2. Тестирование массовой отправки: 3 дня.
  3. Активация системы и запуск первого квартального цикла: Сразу после одобрения предложения.