Token-Based Governance: разделение технических и community-решений
Оригинал: Token-Based Governance: Splitting Technical and Community Decisions
Архитектура выглядит осуществимой, и использование DAO DAO поверх существующего стека CosmWasm кажется практичным подходом.
Но несколько вопросов все же требуют прояснения: — кто классифицирует неоднозначные предложения? — как решается проблема концентрации китов? — кто оценивает результаты и результаты оффчейн?
Без четких ответов на эти вопросы DAO может утвердить решения, которые действительны в сети, но беспорядочны на практике.
Спасибо. Все три являются обоснованными опасениями. У меня есть некоторые мысли по каждому из них, и я могу поделиться ими позже, но я предпочитаю сначала услышать другие позиции и точки зрения, прежде чем предлагать конкретные решения. Было бы здорово обсудить с сообществом и рассмотреть различные варианты.
Все три вопроса @paranjko (https://github.com/paranjko) касаются одного и того же пробела: предлагаемое разделение работает на уровне контракта (x/gov для технического, DAO DAO для сообщества), но мост между правильностью внутри сети и реальностью вне сети остается неопределенным. «Действительно в цепочке, но беспорядочно на практике» — это архитектура управления режимом сбоя, в которую попадают всякий раз, когда мост остается неформальным.
Мост — это тонкий уровень криптографической аттестации, создаваемый в виде типизированных событий Cosmos SDK, который прослушивается контрактами голосования и казначейства без принятия новых предположений о доверии. Три типа событий охватывают поднятые вопросы и один неявный пробел в текущем предложении параметров.
1. Происхождение классификации: кто решил: Технический или Общественный.
Сегодня решение о классификации невидимо. Кто-то маршрутизирует предложение, потом оказывается, что это должен был быть другой трек, без записи, кто и на каком основании сделал звонок.
Подписанная классификационная записка от предлагающего во время подачи исправляет это. Примечание представляет собой запись, подписанную Ed25519, содержащую идентификатор предложения, выбранную версию, хэш текста обоснования, рассмотренные факторы и альтернативные версии, отклоненные с указанием причин. Он не запрещает никому изменять маршрутизацию (это остается решением руководства), он просто делает историю доступной для проверки.
Форма события Cosmos SDK:
ProposalClassificationAttested { Offer_id, Offerer_pubkey, объявленный_трек, // "технический" | "community"rationale_hash, // sha256 текста рассуждения Factors_considered, // например, ["spend_size", "chain_upgrade_involvement"] альтернативы_rejected, // другие треки + почему-не уверенность, // самооценка 0-1, помечает подпись неоднозначности }
Событие генерируется небольшим обработчиком ante (размещается рядом с существующим шаблоном ante_validation.go), который проверяет подпись перед тем, как предложение попадет в любой модуль голосования. Если проверка не удалась, заявка отклоняется с явной ошибкой. Если он пройдет успешно, его смогут использовать индексы событий и последующие инструменты (обозреватели предложений, информационные панели аудита, боты управления).
Неоднозначные предложения проявляются через низкие оценки достоверности и заполненные массивы отклоненных альтернатив. Относиться к доверию ниже порогового уровня как к обязательной проверке довольно просто. Пороговое значение — это выбор уровня управления для Gonka.
2. Аттестация весовой категории: параметры управления в зависимости от размера предложения.
Один пробел, который находится не в вопросах Паранько, а в разделе «Открытые вопросы» предложения, намекает на: # 1008 (https://github.com/gonka-ai/gonka/discussions/1008) использует фиксированный кворум в 5% и депозит в размере 500 GNK независимо от размера предложения, но грант GNK в размере 50 тысяч и казначейский сбор GNK в размере 10 миллионов, вероятно, не должны проходить под одним и тем же порогом участия.
В аттестации весового класса указывается размер сегмента предложения при подаче (малый/средний/большой по расходам GNK или более тонкая схема), а в контракте DAO применяются соответствующие правила кворума и порогового значения для сегмента. Та же инфраструктура подписи, что и классификация, другое событие:
ProposalWeightClassAttested { Offer_id, Weight_class, // "маленький" | "средний" | "большой" объявленный_spend_gnk, class_thresholds_expected, // кворум + порог, по мнению предлагающего, применяется подпись }
Любой проверяющий может сверить заявленные расходы с текстом предложения во время голосования. Намеренное искажение информации становится доказательством, а не невидимой игрой. Сами группы (пороги расходов, соответствующие кворумы) будут жить в конфигурации контракта DAO и оставаться регулируемыми с точки зрения управления.
Стоит упомянуть две разумные интерпретации весового класса: приведенная выше версия с ограниченными параметрами размера или класс приемлемости, при котором расчетный вес предлагающего или поставленный GNK должен превышать минимум, чтобы предложение было приемлемым. Обе формы работоспособны, а события отличаются только полезной нагрузкой. Стоит внести вклад в ветку, на которую рассчитано предложение.
3. Оценка результатов: кто подтверждает отгруженную работу.
Это самый большой из трех. DAO голосует на первой неделе, работа отправляется на шестой неделе или позже, и текущая модель не имеет внутрисетевого сигнала о том, что «то, что было профинансировано, действительно произошло». Высвобождение средств подразумевается при прохождении голосования. Разрыв между «голосование пройдено» и «результат выполнен» покрывается доверием сообщества, а не проверкой.
Трехсторонняя подписанная отчетная запись устраняет разрыв, при этом контракт DAO не меняет способ хранения средств:
Отчет заявителя (подписанный предлагающим): заявленная доставка, расхождение с заявленным намерением
Отчет оценщика (подписанный назначенным оценщиком): независимая оценка, отклонение от ожидаемого результата
Отчет судьи (подписан арбитром, только если первые два не согласны с решением)
Консенсус рассчитывается автоматически, когда оценки расхождения между предлагающим и оценщиком совпадают в пределах допуска (0,15 — разумное начальное значение, которое можно регулировать). Консенсус запускает событие выпуска, которое ожидает казначейский контракт DAO. В общем случае судья не требуется. Спорные дела обостряются автоматически.
ProposalDeliverableAttested { Offer_id, Offerer_report: { result_hash, divergence_score, подпись }, evaluator_report: { evaluator_pubkey, result_hash, divergence_score, подпись }, adjudicator_report?: { adjudicator_pubkey, result_hash, подпись }, консенсус: bool }
Открытый вопрос, заслуживающий внимания в ветке: закреплен ли оценщик за каждым предложением во время утверждения, или он назначен самим предложением и ратифицирован одновременно с утверждением? Оба сочиняют в форме пластинки:
- Закрепление каждого предложения при утверждении. Назначенный оценщик (или список оценщиков) прикрепляется к предложению в момент его принятия. Предлагающий не может выбрать дружественного рецензента постфактум. Более четкое определение полномочий, небольшие накладные расходы во время утверждения, поскольку сообщество должно договориться о том, кто именно.
- Предложение выдвинуто, одобрено. Предлагающий назначает оценщика в составе тела предложения. Голосование за ратификацию охватывает как расходы, так и оценщика. Меньше накладных расходов, но у авторов предложений появляется стимул назначать предсказуемых рецензентов, что переводит игру с этапа поставки на этап номинации.
Мой инстинкт — фиксация каждого предложения. Игровая поверхность меньше, а ответственность оценщика яснее. Но модель «выдвинут, а затем ратифицирована» также имеет реальные аргументы, особенно для предложений со специализированным техническим охватом, где лишь немногие члены сообщества имеют опыт для оценки.
О концентрации китов.
Уровень аттестации не исправляет это напрямую. Вес голоса находится внутри dao-voting-token-staked, и это уровень контракта, а не уровня аттестации. Делегирование куратора (киты, делегирующие право голоса экспертам предметной области) — это смягчение последствий, облегчающее аттестацию: запись делегирования становится подписанным событием с монотонным сужением области действия, делегатор сохраняет полномочия отзыва, полномочия делегата подлежат проверке. Но киты делегируют полномочия только тогда, когда захотят. Квадратичное голосование или голосование по убеждению более непосредственно сузит концентрацию; оба варианта являются изменениями модуля голосования на уровне контракта.
Это стоит назвать вопросом, на который уровень аудита не имеет однозначного ответа, вместо того, чтобы делать вид, что это не так.
О реализации.
Буду рад внести свой вклад в го-сайд, если # 1008 (https://github.com/gonka-ai/gonka/discussions/1008) двинется вперед с такой формой:
- Библиотека Go для проверки подписи Ed25519 по трем записям аттестации, которую можно повторно использовать в обработчиках анте и любых других потребителях.
- Эталонная схема обработчика ante, которая проверяет аттестации классификации и весового класса при отправке предложения (соответствует существующему шаблону ante_validation.go)
- Вспомогательный контракт CosmWasm, который проверяет доставляемые аттестации и генерирует события выпуска, которые контракт казначейства DAO может прослушивать, живя в той же среде CosmWasm Управление на основе токенов: разделение технических и общественных решений № 1008 (https://github.com/gonka-ai/gonka/discussions/1008) уже обязуется
Все три — небольшие, конкретные части, которые сочетаются с существующими цепочками x/gov, DAO DAO и ante, не требуя изменений ни в одной из них.
Примитивы подписи, оценки и трехстороннего консенсуса уже существуют в виде эталонных реализаций TypeScript и Python. Адаптер Cosmos SDK Go — это конкретный недостающий мост, и, несмотря на это, он работает в форме Gonka (не то, что может повторно использоваться потребителем, не использующим Cosmos). Стоит сначала сделать все правильно для Gonka, а затем обобщать, если другие проекты Cosmos спросят позже.
Спасибо, это действительно интересный ракурс. Структура уровня аттестации имеет смысл: рассмотрение классификации, весового класса и проверки результатов поставки как подписанных записей, которые располагаются рядом с существующими контрактами, а не внутри них, сохраняет поверхность небольшой и компонуемой.
Я бы сказал, что это полный, самодостаточный вариант набора проблем, которые необходимо здесь решить, и его определенно стоит держать на столе по мере развития дискуссии. Все еще хочу услышать, куда приземляются другие, прежде чем сойтись в определенном направлении, но ценю, что вы написали это так подробно.
Управление на основе токенов: разделение технических решений и решений сообщества
Мотивация
Управление Gonka в настоящее время работает через стандартный модуль Cosmos SDK x/gov. Сила голоса зависит от вычислительного веса — балла, который каждый хост зарабатывает в результате действия Proof of Compute (доставлены одноразовые номера, завершена работа по выводу). На практике это означает, что в управлении участвуют только активные хосты (операторы узлов), и их влияние пропорционально вкладу их оборудования.
Это создает фундаментальное несоответствие между типом решения и лицом, принимающим решения:
- Хосты являются операторами инфраструктуры. Их вычислительный вес отражает реальный вклад в сеть — мощность вывода, время безотказной работы, надежность. Предоставление им полномочий по принятию технических решений имеет смысл.
- Хозяева — не единственные заинтересованные стороны. Казначейские ассигнования, маркетинговые бюджеты, экосистемные гранты и решения о партнерстве влияют на всех держателей GNK — майнеров, заработавших GNK в результате работы по выводам, разработчиков, использующих сеть, и всех, кто владеет GNK. Ни один из этих участников сегодня не имеет официального голоса в принятии решений сообщества.
По мере роста Gonka (больше хостов, больше разработчиков, больше держателей GNK) это несоответствие будет только обостряться. Решения сообщества должны приниматься сообществом.
Решение высокого уровня
Разделите управление на два направления в зависимости от типа решения, каждое из которых имеет соответствующий набор избирателей:
Хосты сохраняют полную власть над техническими решениями — обновлениями программного обеспечения, параметрами консенсуса, конфигурациями узлов. Их вычислительный вес отражает реальный вклад в сеть и является правильным сигналом для принятия решений на уровне протокола.
Все остальные решения — как расходуются средства сообщества, какие партнерства утверждаются, какие маркетинговые инициативы финансируются — переходят в DAO на основе токенов, где любой держатель GNK вкладывает свои токены в контракт DAO и голосует пропорционально своему поставленному балансу, при этом результаты автоматически фиксируются смарт-контрактом.
Почему это возможно сейчас
CosmWasm уже активен в основной сети Gonka. Контракт на общественную продажу и контракт на пул ликвидности подтверждают, что модуль x/wasm работает. DAO на основе токенов в DAO DAO — это смарт-контракты CosmWasm — для их развертывания не требуется обновление протокола.
Команда разработчиков Gonka уже имеет опыт развертывания и поддержки контрактов CosmWasm. Это не создание новой инфраструктуры, а расширение уже существующей.
Почему dao-voting-token-staked подходит Gonka: этот контракт предназначен для собственных токенов, которые не используются для сетевой безопасности Proof of Stake (например, ION на Juno, токены IBC). Gonka не использует традиционные ставки PoS — сетевая безопасность обеспечивается за счет вычислительного веса через Sprint PoW и PoC V2. GNK — это токен вознаграждения/полезности, а не токен ставки PoS, что делает dao-voting-token-staked подходящим модулем для этого варианта использования.
Технические детали
Текущая архитектура
Все предложения → x/gov → Голосование принимающей стороны (взвешенное по подсчетам) → Исполнение
Предлагаемая архитектура
Технические предложения → x/gov (без изменений) → Голосование хоста → Исполнение Предложения сообщества → DAO на основе токенов → Голосование всех держателей GNK → Исполнение смарт-контракта
Как работает голосование
DAO на основе токенов использует контракт dao-voting-token-Stake. Чтобы участвовать в управлении, держатели GNK должны внести свои токены в контракт DAO. Это действие отличается от хранения GNK в кошельке — стейкинг фиксирует токены в контракте и предоставляет право голоса, пропорциональное поставленной сумме.
Когда предложение создается, в моментальных снимках контракта сохраняются балансы на этой высоте блока. В голосовании учитываются только токены, поставленные до создания предложения. Это предотвращает атаки с подкупом голосов, когда кто-то приобретает GNK после просмотра предложения.
Что это означает для участников:
- Сделайте ставку один раз — токены остаются в ставке для нескольких предложений. Нет необходимости делать повторную ставку за каждый голос
Отмена ставки — токены могут быть сняты с ставки в любое время (в зависимости от периода отвязки, если настроено)
- Никакой узел не требуется — любой кошелек может делать ставки и голосовать. Нет холодного ключа учетной записи, нет оборудования, нет требований к бесперебойной работе.
- Стейкинг ≠ блокировка навсегда — это ставка управления в контракте DAO, а не делегирование PoS-валидатора.
Компоненты DAO на основе токенов
DAO DAO использует три контракта CosmWasm для создания DAO на основе токенов:
Классификация решений
Правило классификации по умолчанию: если предложение явно не попадает в одну дорожку, по умолчанию оно переходит в категорию сообщества (DAO на основе токенов). Обоснование: решения сообщества влияют на большее количество заинтересованных сторон, а более широкий круг избирателей обеспечивает более репрезентативный результат. Любой участник может оспорить классификацию, подав встречное предложение в другой вариант — приоритет имеет тот, кто первым наберет кворум.
Предлагаемые параметры управления (DAO на основе токенов)
Примечание о кворуме: акции GNK, хранящиеся на централизованных биржах, не могут быть включены в контракт DAO и, следовательно, не могут голосовать. Кворум в 5% рассчитывается на основе доли GNK в DAO, а не общего оборотного предложения — это делает порог достижимым, но при этом требует значимого участия.
Примечание о риске вето: при голосовании с взвешиванием токенов крупные держатели теоретически могут наложить вето на предложения в одностороннем порядке, если они владеют> 33% акций GNK. Это известное свойство всех систем управления, взвешенных по токенам. Смягчением является широкое участие в ставках: чем больше держателей акций, тем меньше концентрация любого отдельного избирателя. Сообщество должно следить за распределением ставок после развертывания и корректировать порог вето посредством голосования руководства, если концентрация становится проблемой.
Все параметры настраиваются голосованием сообщества после развертывания.
План реализации
Неделя 1–2 — Подготовка и тестирование
- Проведите аудит существующего развертывания CosmWasm от Gonka — подтвердите разрешения x/wasm и доступные идентификаторы кода.
- Развертывание и настройка пакета контрактов DAO DAO в локальной среде.
Настройте ставку dao-voting-token-token против собственного номинала GNK
Проверка ставок, моментальных снимков, механизма голосования и автоматического исполнения
Неделя 3 — Предложение по управлению 5. Отправьте внутрисетевое предложение x/gov, чтобы разрешить развертывание контракта DAO DAO в основной сети 6. Период проверки сообществом
Неделя 4 — Развертывание основной сети 7. Развертывание контрактов в основной сети 8. Перевести первоначальный субфонд управления в размере 10 000 000 GNK из пула сообщества (120 млн GNK) в казначейство DAO на основе токенов через x/gov. Предложение о расходах пула сообщества 9. x/gov остается активным для принятия технических решений — в DAO переходят только решения сообщества.
90-дневный параллельный период Обе системы работают одновременно. Сообщество укрепляет доверие к новому DAO, прежде чем расширять возможности казначейства. В этот период:
- Предложения сообщества проходят через Token-Based DAO с первоначальным субфондом.
- Технические предложения продолжают поступать через x/gov, как и прежде.
- В конце параллельного периода голосование руководства определяет, расширять ли казначейство DAO или сохранить текущее распределение.
Что не меняется
- Хозяева сохраняют полную власть над техническими решениями.
- Существующий интерфейс управления остается для технических предложений.
- Решения по консенсусу, безопасности и обновлению продолжаются через x/gov.
- Никаких изменений в экономике хоста, вознаграждениях или операциях узлов.
Открытые вопросы
- Размер субфонда — предложено 10 000 000 GNK (~ 8,3% от пула сообщества) в качестве первоначальной казны DAO. Это правильная сумма для параллельного периода? Слишком большой риск? Слишком мало, чтобы быть полезным?
- Порог депозита — 500 GNK. Создает ли это барьер для более мелких членов сообщества при подаче предложений?
- Кворум — 5% предложенной доли ГНК. Это зависит от того, сколько держателей действительно вложили средства в DAO. Должен ли быть установлен минимальный порог ставок, прежде чем DAO станет активным?
- Владельцы CEX — GNK, хранящиеся на биржах, не могут быть размещены на ставках или проголосованы. Это известное ограничение всех систем управления в цепочке. Это предложение выходит за рамки.
- Период отсоединения — если отсоединение от DAO имеет время восстановления (например, 7 дней)? Это предотвращает атаки типа «голосование и сброс», но добавляет трений для участников.
Бюджет
Этап 1 (данное предложение): Никаких расходов казначейства не требуется.
Первоначальное развертывание, настройка и тестирование будут осуществляться командой, предлагающей предложение. Это предложение разрешает план миграции управления и развертывание контрактов DAO DAO в основной сети.
Этап 2 (отдельное предложение после проверки):
Бюджет этапа 2 будет представлен в виде отдельного предложения по расходам внутрисетевого пула сообщества x/gov после подтверждения реализации в течение недель 1–2.
Ссылки
- DAO DAO Token-Based DAO — архитектура и контрактная документация. Источник: docs.daodao.zone (https://docs.daodao.zone)
- DAO Контракты DAO — идентификаторы кодов контрактов развернуты в цепочках Cosmos. Источник: github.com/DA0-DA0/dao-contracts (https://github.com/DA0-DA0/dao-contracts).
- dao-voting-token-staked — собственный модуль ставок токенов для управления DAO DAO. Источник: crates.io/crates/dao-voting-token-staked (https://crates.io/crates/dao-voting-token-staked)
- CosmWasm на Gonka — подтверждена активность посредством контрактов на продажу сообщества и пула ликвидности. Источник: gonka-ai/gonka Releases (https://github.com/gonka-ai/gonka/releases)
- Cosmos SDK x/gov — существующий модуль управления, сохраненный для принятия технических решений. Источник: docs.cosmos.network/main/modules/gov (https://docs.cosmos.network/main/modules/gov).
- Gonka Tokenomics — распределение поставок GNK, пул сообщества. Источник: docs/tokenomics.md (https://github.com/gonka-ai/gonka/blob/main/docs/tokenomics.md)
Архитектура выглядит осуществимой, и использование DAO DAO поверх существующего стека CosmWasm кажется практичным подходом.
Но несколько вопросов все же требуют прояснения: — кто классифицирует неоднозначные предложения? — как решается проблема концентрации китов? — кто оценивает результаты и результаты оффчейн?
Без четких ответов на эти вопросы DAO может утвердить решения, которые действительны в сети, но беспорядочны на практике.
Спасибо. Все три являются обоснованными опасениями. У меня есть некоторые мысли по каждому из них, и я могу поделиться ими позже, но я предпочитаю сначала услышать другие позиции и точки зрения, прежде чем предлагать конкретные решения. Было бы здорово обсудить с сообществом и рассмотреть различные варианты.
Все три вопроса @paranjko (https://github.com/paranjko) касаются одного и того же пробела: предлагаемое разделение работает на уровне контракта (x/gov для технического, DAO DAO для сообщества), но мост между правильностью внутри сети и реальностью вне сети остается неопределенным. «Действительно в цепочке, но беспорядочно на практике» — это архитектура управления режимом сбоя, в которую попадают всякий раз, когда мост остается неформальным.
Мост — это тонкий уровень криптографической аттестации, создаваемый в виде типизированных событий Cosmos SDK, который прослушивается контрактами голосования и казначейства без принятия новых предположений о доверии. Три типа событий охватывают поднятые вопросы и один неявный пробел в текущем предложении параметров.
1. Происхождение классификации: кто решил: Технический или Общественный.
Сегодня решение о классификации невидимо. Кто-то маршрутизирует предложение, потом оказывается, что это должен был быть другой трек, без записи, кто и на каком основании сделал звонок.
Подписанная классификационная записка от предлагающего во время подачи исправляет это. Примечание представляет собой запись, подписанную Ed25519, содержащую идентификатор предложения, выбранную версию, хэш текста обоснования, рассмотренные факторы и альтернативные версии, отклоненные с указанием причин. Он не запрещает никому изменять маршрутизацию (это остается решением руководства), он просто делает историю доступной для проверки.
Форма события Cosmos SDK:
ProposalClassificationAttested { Offer_id, Offerer_pubkey, объявленный_трек, // "технический" | "community"rationale_hash, // sha256 текста рассуждения Factors_considered, // например, ["spend_size", "chain_upgrade_involvement"] альтернативы_rejected, // другие треки + почему-не уверенность, // самооценка 0-1, помечает подпись неоднозначности }
Событие генерируется небольшим обработчиком ante (размещается рядом с существующим шаблоном ante_validation.go), который проверяет подпись перед тем, как предложение попадет в любой модуль голосования. Если проверка не удалась, заявка отклоняется с явной ошибкой. Если он пройдет успешно, его смогут использовать индексы событий и последующие инструменты (обозреватели предложений, информационные панели аудита, боты управления).
Неоднозначные предложения проявляются через низкие оценки достоверности и заполненные массивы отклоненных альтернатив. Относиться к доверию ниже порогового уровня как к обязательной проверке довольно просто. Пороговое значение — это выбор уровня управления для Gonka.
2. Аттестация весовой категории: параметры управления в зависимости от размера предложения.
Один пробел, который находится не в вопросах Паранько, а в разделе «Открытые вопросы» предложения, намекает на: # 1008 (https://github.com/gonka-ai/gonka/discussions/1008) использует фиксированный кворум в 5% и депозит в размере 500 GNK независимо от размера предложения, но грант GNK в размере 50 тысяч и казначейский сбор GNK в размере 10 миллионов, вероятно, не должны проходить под одним и тем же порогом участия.
В аттестации весового класса указывается размер сегмента предложения при подаче (малый/средний/большой по расходам GNK или более тонкая схема), а в контракте DAO применяются соответствующие правила кворума и порогового значения для сегмента. Та же инфраструктура подписи, что и классификация, другое событие:
ProposalWeightClassAttested { Offer_id, Weight_class, // "маленький" | "средний" | "большой" объявленный_spend_gnk, class_thresholds_expected, // кворум + порог, по мнению предлагающего, применяется подпись }
Любой проверяющий может сверить заявленные расходы с текстом предложения во время голосования. Намеренное искажение информации становится доказательством, а не невидимой игрой. Сами группы (пороги расходов, соответствующие кворумы) будут жить в конфигурации контракта DAO и оставаться регулируемыми с точки зрения управления.
Стоит упомянуть две разумные интерпретации весового класса: приведенная выше версия с ограниченными параметрами размера или класс приемлемости, при котором расчетный вес предлагающего или поставленный GNK должен превышать минимум, чтобы предложение было приемлемым. Обе формы работоспособны, а события отличаются только полезной нагрузкой. Стоит внести вклад в ветку, на которую рассчитано предложение.
3. Оценка результатов: кто подтверждает отгруженную работу.
Это самый большой из трех. DAO голосует на первой неделе, работа отправляется на шестой неделе или позже, и текущая модель не имеет внутрисетевого сигнала о том, что «то, что было профинансировано, действительно произошло». Высвобождение средств подразумевается при прохождении голосования. Разрыв между «голосование пройдено» и «результат выполнен» покрывается доверием сообщества, а не проверкой.
Трехсторонняя подписанная отчетная запись устраняет разрыв, при этом контракт DAO не меняет способ хранения средств:
Отчет заявителя (подписанный предлагающим): заявленная доставка, расхождение с заявленным намерением
Отчет оценщика (подписанный назначенным оценщиком): независимая оценка, отклонение от ожидаемого результата
Отчет судьи (подписан арбитром, только если первые два не согласны с решением)
Консенсус рассчитывается автоматически, когда оценки расхождения между предлагающим и оценщиком совпадают в пределах допуска (0,15 — разумное начальное значение, которое можно регулировать). Консенсус запускает событие выпуска, которое ожидает казначейский контракт DAO. В общем случае судья не требуется. Спорные дела обостряются автоматически.
ProposalDeliverableAttested { Offer_id, Offerer_report: { result_hash, divergence_score, подпись }, evaluator_report: { evaluator_pubkey, result_hash, divergence_score, подпись }, adjudicator_report?: { adjudicator_pubkey, result_hash, подпись }, консенсус: bool }
Открытый вопрос, заслуживающий внимания в ветке: закреплен ли оценщик за каждым предложением во время утверждения, или он назначен самим предложением и ратифицирован одновременно с утверждением? Оба сочиняют в форме пластинки:
- Закрепление каждого предложения при утверждении. Назначенный оценщик (или список оценщиков) прикрепляется к предложению в момент его принятия. Предлагающий не может выбрать дружественного рецензента постфактум. Более четкое определение полномочий, небольшие накладные расходы во время утверждения, поскольку сообщество должно договориться о том, кто именно.
- Предложение выдвинуто, одобрено. Предлагающий назначает оценщика в составе тела предложения. Голосование за ратификацию охватывает как расходы, так и оценщика. Меньше накладных расходов, но у авторов предложений появляется стимул назначать предсказуемых рецензентов, что переводит игру с этапа поставки на этап номинации.
Мой инстинкт — фиксация каждого предложения. Игровая поверхность меньше, а ответственность оценщика яснее. Но модель «выдвинут, а затем ратифицирована» также имеет реальные аргументы, особенно для предложений со специализированным техническим охватом, где лишь немногие члены сообщества имеют опыт для оценки.
О концентрации китов.
Уровень аттестации не исправляет это напрямую. Вес голоса находится внутри dao-voting-token-staked, и это уровень контракта, а не уровня аттестации. Делегирование куратора (киты, делегирующие право голоса экспертам предметной области) — это смягчение последствий, облегчающее аттестацию: запись делегирования становится подписанным событием с монотонным сужением области действия, делегатор сохраняет полномочия отзыва, полномочия делегата подлежат проверке. Но киты делегируют полномочия только тогда, когда захотят. Квадратичное голосование или голосование по убеждению более непосредственно сузит концентрацию; оба варианта являются изменениями модуля голосования на уровне контракта.
Это стоит назвать вопросом, на который уровень аудита не имеет однозначного ответа, вместо того, чтобы делать вид, что это не так.
О реализации.
Буду рад внести свой вклад в го-сайд, если # 1008 (https://github.com/gonka-ai/gonka/discussions/1008) двинется вперед с такой формой:
- Библиотека Go для проверки подписи Ed25519 по трем записям аттестации, которую можно повторно использовать в обработчиках анте и любых других потребителях.
- Эталонная схема обработчика ante, которая проверяет аттестации классификации и весового класса при отправке предложения (соответствует существующему шаблону ante_validation.go)
- Вспомогательный контракт CosmWasm, который проверяет доставляемые аттестации и генерирует события выпуска, которые контракт казначейства DAO может прослушивать, живя в той же среде CosmWasm Управление на основе токенов: разделение технических и общественных решений № 1008 (https://github.com/gonka-ai/gonka/discussions/1008) уже обязуется
Все три — небольшие, конкретные части, которые сочетаются с существующими цепочками x/gov, DAO DAO и ante, не требуя изменений ни в одной из них.
Примитивы подписи, оценки и трехстороннего консенсуса уже существуют в виде эталонных реализаций TypeScript и Python. Адаптер Cosmos SDK Go — это конкретный недостающий мост, и, несмотря на это, он работает в форме Gonka (не то, что может повторно использоваться потребителем, не использующим Cosmos). Стоит сначала сделать все правильно для Gonka, а затем обобщать, если другие проекты Cosmos спросят позже.
Спасибо, это действительно интересный ракурс. Структура уровня аттестации имеет смысл: рассмотрение классификации, весового класса и проверки результатов поставки как подписанных записей, которые располагаются рядом с существующими контрактами, а не внутри них, сохраняет поверхность небольшой и компонуемой.
Я бы сказал, что это полный, самодостаточный вариант набора проблем, которые необходимо здесь решить, и его определенно стоит держать на столе по мере развития дискуссии. Все еще хочу услышать, куда приземляются другие, прежде чем сойтись в определенном направлении, но ценю, что вы написали это так подробно.
Token-Based Governance: Splitting Technical and Community Decisions
Motivation
Gonka governance currently works through the standard Cosmos SDK x/gov module. Voting power is derived from compute weight — a score each host earns through Proof of Compute activity (nonces delivered, inference work completed). In practice, this means only active hosts (node operators) participate in governance, and their influence is proportional to their hardware contribution.
This creates a fundamental mismatch between decision type and decision-maker:
- Hosts are infrastructure operators. Their compute weight reflects real contribution to the network — inference capacity, uptime, reliability. Giving them authority over technical decisions makes sense.
- Hosts are not the only stakeholders. Treasury allocations, marketing budgets, ecosystem grants, and partnership decisions affect all GNK holders — miners who earned GNK through inference work, developers who use the network, and anyone who holds GNK. None of these participants have a formal voice in community decisions today.
As Gonka grows — more hosts, more developers, more GNK holders — this mismatch will only become more acute. Community decisions should be made by the community.
High-Level Solution
Split governance into two tracks based on decision type , each with the appropriate voter set:
Hosts retain full authority over technical decisions — software upgrades, consensus parameters, node configurations. Their compute weight reflects real contribution to the network and is the right signal for protocol-level decisions.
All other decisions — how community funds are spent, which partnerships are approved, which marketing initiatives are funded — move to a Token-Based DAO where any GNK holder stakes their tokens into the DAO contract and votes proportionally to their staked balance, with results enforced automatically by smart contract.
Why This Is Feasible Now
CosmWasm is already active on Gonka mainnet. The community sale contract and liquidity pool contract confirm that the x/wasm module is operational. Token-Based DAOs on DAO DAO are CosmWasm smart contracts — no protocol upgrade is required to deploy them.
Gonka's development team already has experience deploying and maintaining CosmWasm contracts. This is not introducing new infrastructure — it is extending what already exists.
Why dao-voting-token-staked fits Gonka: This contract is designed for native tokens that are not used for Proof of Stake network security (e.g. ION on Juno, IBC tokens). Gonka does not use traditional PoS staking — network security is provided by compute weight via Sprint PoW and PoC V2. GNK is a reward/utility token, not a PoS staking token, which makes dao-voting-token-staked the correct module for this use case.
Technical Details
Current Architecture
All proposals → x/gov → Host vote (weighted by compute) → Execution
Proposed Architecture
Technical proposals → x/gov (unchanged) → Host vote → Execution Community proposals → Token-Based DAO → All GNK holders vote → Smart contract execution
How Voting Works
The Token-Based DAO uses the dao-voting-token-staked contract. To participate in governance, GNK holders must stake their tokens into the DAO contract . This is a separate action from holding GNK in a wallet — staking locks tokens in the contract and grants voting power proportional to the staked amount.
When a proposal is created, the contract snapshots staked balances at that block height . Only tokens staked before the proposal was created count toward the vote. This prevents vote-buying attacks where someone acquires GNK after seeing a proposal.
What this means for participants:
- Stake once — tokens remain staked across multiple proposals. No need to re-stake for each vote
Unstaking — tokens can be unstaked at any time (subject to an unbonding period, if configured)
- No node required — any wallet can stake and vote. No Cold Account Key, no hardware, no uptime requirement
Staking ≠ locking forever — this is governance staking into the DAO contract, not PoS validator delegation
Token-Based DAO Components
DAO DAO uses three CosmWasm contracts to power a Token-Based DAO:
Decision Classification
Default classification rule: If a proposal does not clearly fall into a single track, it defaults to the Community track (Token-Based DAO). The rationale: community decisions affect more stakeholders, and the wider voter set provides a more representative outcome. Any participant can challenge a classification by submitting a counter-proposal to the other track — the first to reach quorum takes precedence.
Proposed Governance Parameters (Token-Based DAO)
Note on quorum: GNK held on centralized exchanges cannot be staked into the DAO contract and therefore cannot vote. The 5% quorum is calculated against staked GNK in the DAO, not total circulating supply — this makes the threshold achievable while still requiring meaningful participation.
Note on veto risk: With token-weighted voting, large holders could theoretically veto proposals unilaterally if they hold >33% of staked GNK. This is a known property of all token-weighted governance systems. The mitigation is broad staking participation — as more holders stake, the concentration of any single voter decreases. The community should monitor staking distribution after deployment and adjust the veto threshold via governance vote if concentration becomes a concern.
All parameters are adjustable by community vote after deployment.
Implementation Plan
Week 1–2 — Preparation and Testing
Audit Gonka's existing CosmWasm deployment — confirm x/wasm permissions and available code IDs
Deploy and configure DAO DAO contract suite in a local environment
Configure dao-voting-token-staked against GNK native denom
Validate staking, snapshotting, voting mechanics, and automatic execution
Week 3 — Governance Proposal 5. Submit on-chain x/gov proposal to authorize DAO DAO contract deployment on mainnet 6. Community review period
Week 4 — Mainnet Deployment 7. Deploy contracts to mainnet 8. Transfer an initial governance sub-fund of 10,000,000 GNK from the Community Pool (120M GNK) to the Token-Based DAO treasury via x/gov Community Pool Spend proposal 9. x/gov remains active for technical decisions — only community decisions migrate to the DAO
90-Day Parallel Period Both systems run simultaneously. Community builds confidence in the new DAO before expanding treasury scope. During this period:
Community proposals go through the Token-Based DAO with the initial sub-fund
Technical proposals continue through x/gov as before
- At the end of the parallel period, a governance vote determines whether to expand the DAO treasury or maintain the current allocation
What Does Not Change
Hosts retain full authority over technical decisions
The existing governance interface remains for technical proposals
Consensus, security, and upgrade decisions continue through x/gov
No changes to host economics, rewards, or node operations
Open Questions
- Sub-fund size — 10,000,000 GNK proposed (~8.3% of Community Pool) as the initial DAO treasury. Is this the right amount for the parallel period? Too much risk? Too little to be useful?
- Deposit threshold — 500 GNK proposed. Does this create a barrier for smaller community members to submit proposals?
- Quorum — 5% of staked GNK proposed. This depends on how many holders actually stake into the DAO. Should there be a minimum staking threshold before the DAO becomes active?
- CEX holders — GNK held on exchanges cannot be staked or vote. This is a known limitation of all on-chain governance systems. Out of scope for this proposal.
- Unbonding period — Should unstaking from the DAO have a cooldown (e.g. 7 days)? This prevents vote-and-dump attacks but adds friction for participants.
Budget
Phase 1 (this proposal): No treasury spend requested.
Initial deployment, configuration, and testing will be contributed by the proposing team. This proposal authorizes the governance migration plan and the deployment of DAO DAO contracts on mainnet.
Phase 2 (separate proposal after validation):
The Phase 2 budget will be submitted as a separate on-chain x/gov Community Pool Spend proposal once the implementation is validated during Weeks 1–2.
References
- DAO DAO Token-Based DAO — architecture and contract documentation. Source: docs.daodao.zone (https://docs.daodao.zone)
- DAO DAO contracts — deployed contract code IDs across Cosmos chains. Source: github.com/DA0-DA0/dao-contracts (https://github.com/DA0-DA0/dao-contracts)
- dao-voting-token-staked — native token staking module for DAO DAO governance. Source: crates.io/crates/dao-voting-token-staked (https://crates.io/crates/dao-voting-token-staked)
- CosmWasm on Gonka — confirmed active via community sale and liquidity pool contracts. Source: gonka-ai/gonka releases (https://github.com/gonka-ai/gonka/releases)
- Cosmos SDK x/gov — existing governance module, retained for technical decisions. Source: docs.cosmos.network/main/modules/gov (https://docs.cosmos.network/main/modules/gov)
- Gonka Tokenomics — GNK supply distribution, community pool. Source: docs/tokenomics.md (https://github.com/gonka-ai/gonka/blob/main/docs/tokenomics.md)
The architecture looks feasible, and using DAO DAO on top of the existing CosmWasm stack seems like a practical approach.
But a few questions still need to be clarified: — who classifies ambiguous proposals? — how is whale concentration handled? — who evaluates off-chain deliverables and outcomes?
Without clear answers to these questions, the DAO could approve decisions that are valid on-chain but messy in practice.
Thanks. All three are valid concerns. I have some thoughts on each and can share them later, but I'd rather hear other positions and points of view first before proposing specific solutions. Would be great to discuss with the community and look at different options.
@paranjko (https://github.com/paranjko) 's three questions all land on the same gap: the proposed split works at the contract level (x/gov for technical, DAO DAO for community) but the bridge between on-chain correctness and off-chain reality is left unspecified. "Valid on-chain but messy in practice" is the failure mode governance architectures fall into whenever the bridge stays informal.
The bridge is a thin cryptographic attestation layer, emitted as typed Cosmos SDK events, that the voting and treasury contracts listen to without taking on new trust assumptions. Three event types cover the questions raised and one implicit gap in the current parameter proposal.
1. Classification provenance: who decided Technical vs Community.
Today the classification decision is invisible. Someone routes a proposal, later it turns out it should have been the other track, no record of who made the call or on what grounds.
A signed classification note from the proposer at submission time fixes this. The note is an Ed25519-signed record carrying the proposal ID, the chosen track, a hash of the rationale text, factors considered, and alternative tracks rejected with reasons. It doesn't block anyone from re-routing (that stays a governance decision), it just makes the history auditable.
Cosmos SDK event shape:
ProposalClassificationAttested { proposal_id, proposer_pubkey, declared_track, // "technical" | "community" rationale_hash, // sha256 of the reasoning text factors_considered, // e.g., ["spend_size", "chain_upgrade_involvement"] alternatives_rejected, // other tracks + why-not confidence, // 0-1 self-rating, flags ambiguity signature }
The event is emitted by a small ante handler (slots alongside the existing ante_validation.go pattern) that verifies the signature before the proposal enters either voting module. If verification fails, the submission rejects with a clear error. If it passes, the event indexes and downstream tooling (proposal explorers, audit dashboards, governance bots) can consume it.
Ambiguous proposals surface through low confidence scores plus populated alternatives-rejected arrays. Treating confidence below a threshold as mandatory-review is straightforward. The threshold value is a governance-layer choice for Gonka.
2. Weight-class attestation: proposal-size-scoped governance parameters.
One gap that isn't in paranjko's questions but the Open Questions section of the proposal hints at: #1008 (https://github.com/gonka-ai/gonka/discussions/1008) uses a flat 5% quorum and 500 GNK deposit regardless of proposal size, but a 50K GNK grant and a 10M GNK treasury sweep probably shouldn't pass under the same participation threshold.
A weight-class attestation declares the proposal's size bucket at submission (Small / Medium / Large by GNK spend, or a finer scheme) and the DAO contract applies bucket-appropriate quorum and threshold rules. Same signature infrastructure as classification, different event:
ProposalWeightClassAttested { proposal_id, weight_class, // "small" | "medium" | "large" declared_spend_gnk, class_thresholds_expected, // quorum + threshold the proposer believes apply signature }
Any verifier can cross-check declared spend against the proposal body at vote time. Intentional misdeclaration becomes evidence rather than invisible gaming. The bands themselves (spend thresholds, corresponding quorums) would live in the DAO contract config and stay governance-adjustable.
Two reasonable interpretations of weight-class worth surfacing: the size-scoped-parameters version above, or an eligibility class where the proposer's compute weight or staked GNK has to exceed a minimum for the proposal to be admissible. Both shapes are workable, and the events differ only in payload. Worth the thread's input on which the proposal intends.
3. Deliverable evaluation: who confirms the work shipped.
This is the biggest of the three. The DAO votes in Week 1, the work ships in Week 6 or later, and the current model has no on-chain signal for "the thing that was funded actually happened." Release of funds is implicit in the passing vote. The gap between "vote passed" and "deliverable met" is covered by community trust rather than verification.
A three-way signed outcome record closes the gap without the DAO contract changing how it holds funds:
Proposer report (signed by proposer): claimed delivery, divergence from declared intent
Evaluator report (signed by designated evaluator): independent assessment, divergence from expected outcome
Adjudicator report (signed by an arbiter, only if the first two disagree beyond tolerance)
Consensus is auto-computed when proposer and evaluator divergence scores align within a tolerance (0.15 is a reasonable starting value, adjustable). Consensus triggers the release event the DAO treasury contract listens for. No adjudicator needed in the common case. Disputed cases escalate automatically.
ProposalDeliverableAttested { proposal_id, proposer_report: { outcome_hash, divergence_score, signature }, evaluator_report: { evaluator_pubkey, outcome_hash, divergence_score, signature }, adjudicator_report?: { adjudicator_pubkey, outcome_hash, signature }, consensus: bool }
Open question worth the thread's input: is the evaluator pinned per-proposal at approval time, or nominated by the proposal itself and ratified alongside approval? Both compose with the record shape:
- Per-proposal pinning at approval. A named evaluator (or slate of evaluators) is attached to the proposal at the moment it passes. The proposer can't pick a friendly reviewer after the fact. Cleaner authority scoping, slight overhead at approval time because the community has to agree on who.
- Proposal-nominated, approval-ratified. The proposer nominates an evaluator in the proposal body. The ratification vote covers both the spend and the evaluator. Less overhead, but creates an incentive for proposers to nominate predictable reviewers, which shifts gaming from the deliverable stage to the nomination stage.
My instinct is per-proposal pinning. The gaming surface is smaller and the evaluator's accountability is clearer. But the nominated-then-ratified model has real arguments too, particularly for proposals with specialized technical scope where few community members have the expertise to evaluate.
On whale concentration.
The attestation layer doesn't fix this directly. Vote weight lives inside dao-voting-token-staked , and that's contract-level, not attestation-level. Curator delegation (whales delegating voting power to domain experts) is the attestation-friendly mitigation: the delegation record becomes a signed event with monotonic scope narrowing, delegator keeps revocation authority, delegate's authority is auditable. But whales delegate only when they choose to. Quadratic or conviction voting would narrow concentration more directly, both are contract-level changes to the voting module.
Worth naming as the question where the audit layer doesn't have a clean answer, rather than pretending otherwise.
On implementation.
Happy to contribute the Go-side pieces if #1008 (https://github.com/gonka-ai/gonka/discussions/1008) moves forward with this shape:
- Go library for Ed25519 signature verification over the three attestation records, reusable across ante handlers and any other consumer
- Reference ante handler wiring that validates classification and weight-class attestations at proposal submission (fits the existing ante_validation.go pattern)
- CosmWasm helper contract that validates deliverable attestations and emits release events the DAO treasury contract can listen to, living in the same CosmWasm environment Token-Based Governance: Splitting Technical and Community Decisions #1008 (https://github.com/gonka-ai/gonka/discussions/1008) already commits to
All three are small, specific pieces that sit alongside the existing x/gov, DAO DAO, and ante chain without requiring changes to any of them.
The signing, scoring, and three-way consensus primitives already exist as TypeScript and Python reference implementations. The Cosmos SDK Go adapter is the specific missing bridge, and it's Gonka-shaped work regardless (not something that gets reused by a non-Cosmos consumer). Worth doing right for Gonka first, then generalizing if other Cosmos projects ask later.
Thanks, this is a really interesting angle. The attestation layer framing makes sense: treating classification, weight-class, and deliverable verification as signed records that sit alongside the existing contracts rather than inside them keeps the surface small and composable.
I'd say this is a full, self-contained option for the set of problems that need to be solved here, and definitely one worth keeping on the table as the discussion develops. Still want to hear where others land before converging on a specific direction, but appreciate you writing it up in this much detail.
Управление на основе токенов: разделение технических решений и решений сообщества
Мотивация
Управление Gonka в настоящее время работает через стандартный модуль Cosmos SDK x/gov. Сила голоса зависит от вычислительного веса — балла, который каждый хост зарабатывает в результате действия Proof of Compute (доставлены одноразовые номера, завершена работа по выводу). На практике это означает, что в управлении участвуют только активные хосты (операторы узлов), и их влияние пропорционально вкладу их оборудования.
Это создает фундаментальное несоответствие между типом решения и лицом, принимающим решения:
По мере роста Gonka (больше хостов, больше разработчиков, больше держателей GNK) это несоответствие будет только обостряться. Решения сообщества должны приниматься сообществом.
Решение высокого уровня
Разделите управление на два направления в зависимости от типа решения, каждое из которых имеет соответствующий набор избирателей:
Хосты сохраняют полную власть над техническими решениями — обновлениями программного обеспечения, параметрами консенсуса, конфигурациями узлов. Их вычислительный вес отражает реальный вклад в сеть и является правильным сигналом для принятия решений на уровне протокола.
Все остальные решения — как расходуются средства сообщества, какие партнерства утверждаются, какие маркетинговые инициативы финансируются — переходят в DAO на основе токенов, где любой держатель GNK вкладывает свои токены в контракт DAO и голосует пропорционально своему поставленному балансу, при этом результаты автоматически фиксируются смарт-контрактом.
Почему это возможно сейчас
CosmWasm уже активен в основной сети Gonka. Контракт на общественную продажу и контракт на пул ликвидности подтверждают, что модуль x/wasm работает. DAO на основе токенов в DAO DAO — это смарт-контракты CosmWasm — для их развертывания не требуется обновление протокола.
Команда разработчиков Gonka уже имеет опыт развертывания и поддержки контрактов CosmWasm. Это не создание новой инфраструктуры, а расширение уже существующей.
Почему dao-voting-token-staked подходит Gonka: этот контракт предназначен для собственных токенов, которые не используются для сетевой безопасности Proof of Stake (например, ION на Juno, токены IBC). Gonka не использует традиционные ставки PoS — сетевая безопасность обеспечивается за счет вычислительного веса через Sprint PoW и PoC V2. GNK — это токен вознаграждения/полезности, а не токен ставки PoS, что делает dao-voting-token-staked подходящим модулем для этого варианта использования.
Технические детали
Текущая архитектура
Все предложения → x/gov → Голосование принимающей стороны (взвешенное по подсчетам) → Исполнение
Предлагаемая архитектура
Технические предложения → x/gov (без изменений) → Голосование хоста → Исполнение Предложения сообщества → DAO на основе токенов → Голосование всех держателей GNK → Исполнение смарт-контрактаКак работает голосование
DAO на основе токенов использует контракт dao-voting-token-Stake. Чтобы участвовать в управлении, держатели GNK должны внести свои токены в контракт DAO. Это действие отличается от хранения GNK в кошельке — стейкинг фиксирует токены в контракте и предоставляет право голоса, пропорциональное поставленной сумме.
Когда предложение создается, в моментальных снимках контракта сохраняются балансы на этой высоте блока. В голосовании учитываются только токены, поставленные до создания предложения. Это предотвращает атаки с подкупом голосов, когда кто-то приобретает GNK после просмотра предложения.
Что это означает для участников:
Отмена ставки — токены могут быть сняты с ставки в любое время (в зависимости от периода отвязки, если настроено)
Компоненты DAO на основе токенов
DAO DAO использует три контракта CosmWasm для создания DAO на основе токенов:
Классификация решений
Правило классификации по умолчанию: если предложение явно не попадает в одну дорожку, по умолчанию оно переходит в категорию сообщества (DAO на основе токенов). Обоснование: решения сообщества влияют на большее количество заинтересованных сторон, а более широкий круг избирателей обеспечивает более репрезентативный результат. Любой участник может оспорить классификацию, подав встречное предложение в другой вариант — приоритет имеет тот, кто первым наберет кворум.
Предлагаемые параметры управления (DAO на основе токенов)
Примечание о кворуме: акции GNK, хранящиеся на централизованных биржах, не могут быть включены в контракт DAO и, следовательно, не могут голосовать. Кворум в 5% рассчитывается на основе доли GNK в DAO, а не общего оборотного предложения — это делает порог достижимым, но при этом требует значимого участия.
Примечание о риске вето: при голосовании с взвешиванием токенов крупные держатели теоретически могут наложить вето на предложения в одностороннем порядке, если они владеют> 33% акций GNK. Это известное свойство всех систем управления, взвешенных по токенам. Смягчением является широкое участие в ставках: чем больше держателей акций, тем меньше концентрация любого отдельного избирателя. Сообщество должно следить за распределением ставок после развертывания и корректировать порог вето посредством голосования руководства, если концентрация становится проблемой.
Все параметры настраиваются голосованием сообщества после развертывания.
План реализации
Неделя 1–2 — Подготовка и тестирование
Настройте ставку dao-voting-token-token против собственного номинала GNK
Проверка ставок, моментальных снимков, механизма голосования и автоматического исполнения
Неделя 3 — Предложение по управлению 5. Отправьте внутрисетевое предложение x/gov, чтобы разрешить развертывание контракта DAO DAO в основной сети 6. Период проверки сообществом
Неделя 4 — Развертывание основной сети 7. Развертывание контрактов в основной сети 8. Перевести первоначальный субфонд управления в размере 10 000 000 GNK из пула сообщества (120 млн GNK) в казначейство DAO на основе токенов через x/gov. Предложение о расходах пула сообщества 9. x/gov остается активным для принятия технических решений — в DAO переходят только решения сообщества.
90-дневный параллельный период Обе системы работают одновременно. Сообщество укрепляет доверие к новому DAO, прежде чем расширять возможности казначейства. В этот период:
Что не меняется
Открытые вопросы
Бюджет
Этап 1 (данное предложение): Никаких расходов казначейства не требуется.
Первоначальное развертывание, настройка и тестирование будут осуществляться командой, предлагающей предложение. Это предложение разрешает план миграции управления и развертывание контрактов DAO DAO в основной сети.
Этап 2 (отдельное предложение после проверки):
Бюджет этапа 2 будет представлен в виде отдельного предложения по расходам внутрисетевого пула сообщества x/gov после подтверждения реализации в течение недель 1–2.
Ссылки