Документация смарт-контракта для dev и compliance

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

Входные данные
- [CODE_SNIPPETS]
- [FUNCTIONALITIES_SUMMARY]
- [COMPLIANCE_GUIDELINES]
- [SECURITY_MEASURES]
- [TOKEN_UTILITY]

Формат ответа
- Язык: русский.
- Тон: точный, нейтральный, пригодный для разработчиков и сотрудников compliance.
- Объём: 600-1200 слов, при большом объёме входных данных допускается до 2000.
- Используй заголовки 1-13 строго в таком порядке:
  1. Краткое введение
  2. Исходные данные
  3. Обзор кода: функции и переменные
  4. Основные функциональные возможности
  5. Меры безопасности и уязвимости
  6. Протоколы обновления и управление
  7. Руководящие принципы по обслуживанию и операционные чек-листы
  8. Соответствие требованиям комплаенса
  9. Структура документации и материалы для разных аудиторий
  10. Токен: утилита и экономические свойства
  11. Самая слабая гипотеза и проверка
  12. Один реалистичный сценарий неправильной интерпретации
  13. Краткая итоговая контрольная таблица

Требования
- В разделе 2 явно перечисли, какие элементы были предоставлены, а какие отсутствуют.
- В разделе 3 для каждого фрагмента укажи ключевые функции и переменные с сигнатурой или типом, уровнем доступа, назначением и граничными условиями.
- В разделе 4 выдели 3-5 основных возможностей и риски неверной реализации.
- В разделе 5 опиши риски вроде reentrancy, overflow, improper access control, front-running и другие релевантные случаи: источник, влияние, рекомендация и приоритет.
- В разделе 6 опиши или предложи паттерны апгрейда, управление ролями и безопасную процедуру релиза и отката.
- В разделе 8 сопоставь контракт с [COMPLIANCE_GUIDELINES] и раздели требования на выполненные, частично выполненные и отсутствующие.
- В разделе 9 предложи структуру README, API reference, security appendix, upgrade guide, changelog и examples, а также рекомендованные диаграммы.
- В конце обязательно назови одну слабую гипотезу, план её проверки и один правдоподобный сценарий неправильного толкования.

Ограничения
- Не давай юридических заключений.
- Не придумывай детали, которых нет в коде или во входных данных.