Рамка управления DAO с ролями, голосованием и коммуникацией

Подготовь итоговую модель управления DAO для [НАЗВАНИЕ_КОМПАНИИ].

Используй вход:
- [ОПЕРАЦИОННЫЕ_ПРОЦЕДУРЫ]
- [РОЛИ]
- [UTILITY_ТОКЕНА]
- [ЦЕЛЕВОЕ_СООБЩЕСТВО]
- [ПАРАМЕТРЫ_ТОКЕНОМИКИ]
- [ТАЙМЛАЙН_ЗАПУСКА]
- [РЕГУЛЯТОРНАЯ_ЮРИСДИКЦИЯ]

Если какого-либо поля нет, явно укажи это и используй консервативное значение по умолчанию:
- кворум: 20% от общего предложения токенов;
- порог одобрения: 60% голосов участников;
- период обсуждения: 7 дней;
- период голосования: от 5 до 14 дней с указанием точного числа;
- способ голосования: on-chain Snapshot при наличии поддержки или проверяемое off-chain голосование с исполнением через multisig.
Если [РЕГУЛЯТОРНАЯ_ЮРИСДИКЦИЯ] не указана, обозначь комплаенс-риск как «неопределён».

Верни один законченный документ объёмом 800–1400 слов. Не предлагай альтернативных моделей. Соблюдай структуру:
1. «Модель управления DAO — [НАЗВАНИЕ_КОМПАНИИ]» + дата + список полученных и дефолтных входов.
2. Контекст: связь целей DAO с utility токена, сообществом, токеномикой и таймлайном.
3. От 2 до 4 принципов управления:
   - название;
   - краткое обоснование;
   - измеримые правила внедрения и метрики соблюдения.
4. Роли и обязанности:
   - для каждой роли из [РОЛИ] дай определение, обязанности, полномочия, KPI/ожидаемый вклад, порядок назначения и снятия, требования к раскрытию конфликта интересов;
   - добавь минимум одну экстренную роль с ограничениями и критериями формирования.
5. Процесс голосования и принятия решений:
   - типы предложений;
   - жизненный цикл предложения от подачи до публикации результатов;
   - конкретные численные параметры с обоснованием;
   - механизм делегирования и его ограничения;
   - порядок обжалования и ревизии решений.
6. Каналы коммуникации и правила взаимодействия:
   - официальные каналы, оперативные каналы и архивы;
   - кто публикует объявления, как часто выходят отчёты, что обязательно раскрывается;
   - правила модерации, порядок разрешения конфликтов, санкции.
7. Одно самое слабое предположение:
   - сформулируй его одной фразой;
   - дай конкретный план проверки с метриками, сроками и критериями успеха/провала.
8. Один реалистичный сценарий сбоя:
   - 3–5 предложений о том, как модель может дать сбой;
   - 2–3 практических меры смягчения и восстановления.
9. Заключение и шаги внедрения:
   - 3–6 приоритетных действий, ответственные роли и сроки, привязанные к [ТАЙМЛАЙН_ЗАПУСКА].
10. Компактный JSON в конце документа со структурой:
   {
     "principles": [...],
     "roles": [{"name": "", "key_responsibilities": [...], "powers": [...]}],
     "voting_rules": {"quorum": "", "approval_threshold": "", "voting_period_days": "", "vote_type": ""},
     "communication_channels": [...],
     "weakest_assumption": {"statement": "", "test_method": ""},
     "failure_scenario": ""
   }

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