> For the complete documentation index, see [llms.txt](https://docs.pots.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pots.money/ru/sozdanie-pots/upravlenie.md).

# Управление

#### Философия децентрализованного управления

POTS не управляется командой. Им управляет сообщество — через прозрачный ончейн-процесс, который гарантирует, что ни один отдельный участник не сможет в одиночку направить будущее протокола.

Наша модель управления опирается на лучшие практики Compound, Curve и Olympus DAO, при этом вводя новый механизм — vIBS — специально разработанный для ограничений протокола, в котором права управления, once issued, не могут быть уничтожены.

{% hint style="info" %}
💡 Основной принцип

Сила управления должна отражать долгосрочную приверженность, а не размер капитала. Те, кто стейкает больше и дольше, получают пропорционально большее влияние — но ранние участники не могут навсегда доминировать в системе.
{% endhint %}

#### Что может управляться?

Управление POTS охватывает три области:

<table><thead><tr><th width="251.8203125">Область</th><th>Примеры</th></tr></thead><tbody><tr><td>Параметры протокола</td><td>Ставки эмиссии, ставки налога на слэшинг, диапазоны RBS, пороги MCL, длительность эпохи</td></tr><tr><td>Распределение казны</td><td>Размещение Safety Treasury, стратегия пула заявок PBM, перемещения средств через мультисиг</td></tr><tr><td>Бюджет грантов для рынка</td><td>Гранты на создание рынков прогнозов, развитие экосистемы, инициативы сообщества</td></tr></tbody></table>

#### Процесс управления

**Шаг 1 — Обсуждение на форуме (≥ 3 дней)**

Все предложения по управлению начинают как неформальные обсуждения на форуме сообщества POTS. Минимальный срок обсуждения — 3 дня. Это позволяет сообществу выявить проблемы, предложить улучшения и выработать консенсус до подачи формального предложения.

**Шаг 2 — Черновик предложения (требуется белый список мультисиг)**

Только адреса из белого списка мультисиг казны могут подавать формальные предложения в Snapshot. Это предотвращает спам и гарантирует, что предложения будут рассмотрены ответственными сторонами до выхода на голосование сообщества.

{% hint style="success" %}
🔐 Зачем нужен белый список?

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

**Шаг 3 — Голосование в Snapshot (окно 5 дней)**

Голосование проводится в Snapshot — безгазовой платформе голосования вне цепи. Любой адрес, владеющий vIBS, может голосовать. Окно голосования — 5 дней.

* Кворум: для действительности голосования должно участвовать 10% от общего объёма vIBS.
* Порог принятия: требуется >50% голосов «За».
* Вес голоса: пропорционален балансу vIBS на блоке снимка.

**Шаг 4 — Задержка timelock (24 часа)**

Принятые предложения переходят в 48-часовой timelock перед исполнением. Этот буфер безопасности позволяет сообществу выявить и отреагировать на любые вредоносные или ошибочные предложения, которые могли пройти голосование.

**Шаг 5 — Исполнение в цепи**

В зависимости от типа предложения:

* Автоматизированные параметры: исполняются напрямую смарт-контрактом.
* Перемещения казны: требуют одобрения мультисигом (25 из 50 подписантов).

Отклонённые предложения возвращаются на форум для доработки и повторного обсуждения.

#### vIBS — учётное право управления

vIBS — это непередаваемый управленческий пропуск протокола POTS. Он выпускается, когда пользователь стейкает IBS, и никогда не уничтожается — даже после окончания периода стейкинга.

**Формула выпуска**

Когда пользователь стейкает $$N$$ IBS на $$D$$ дней в эпохе протокола $$E$$:

$$\text{vIBS}(N, D, E) = N \times \frac{D}{90} \times \alpha(E)$$

Где:

* $$N$$ = количество застейканных IBS
* &#x20;$$D$$= срок блокировки в днях
* $$\frac{D}{90}$$ = множитель длительности (90 дней = 1×, 180 дней = 2×, 360 дней = 4×)
* $$\alpha(E)$$ = коэффициент инфляции эпохи на момент выпуска

**Множитель длительности**

| Срок блокировки | Множитель $D/90$ | Пример: 100 IBS  |
| --------------- | ---------------- | ---------------- |
| 90 дней         | 1×               | 100 базовых vIBS |
| 180 дней        | 2×               | 200 базовых vIBS |
| 270 дней        | 3×               | 300 базовых vIBS |
| 360 дней        | 4×               | 400 базовых vIBS |

#### Коэффициент инфляции эпохи

Поскольку vIBS нельзя уничтожить, чисто аддитивная система позволила бы ранним участникам навсегда доминировать в управлении по мере накопления ими vIBS. Коэффициент инфляции эпохи $$\alpha(E)$$ решает эту проблему.

**Дизайн**

Каждая эпоха длится 1 неделю. Коэффициент инфляции растёт геометрически:

$$\alpha(E) = r^{E-1}, \quad r = 10^{1/51} \approx 1.0462$$

Это означает, что в каждой новой эпохе коэффициент инфляции увеличивается примерно на +4,62%.

**Целевое размывание**

Система откалибрована так, что к Эпохе 52 (\~1 год после запуска):

$$\frac{\alpha(1)}{\alpha(52)} = \frac{1}{10} = 10%$$

Позиция, выпущенная в Эпоху 1 (самую первую неделю), имеет коэффициент инфляции 1,0. Позиция, выпущенная в Эпоху 52, имеет коэффициент инфляции 10,0. При идентичных параметрах стейкинга ( $$N$$ IBS, $$D$$ дней), позиция из Эпохи 1 обладает ровно 10% от силы голосования позиции из Эпохи 52.

Это гарантирует, что ранние участники получают вознаграждение за свою приверженность, но не могут навсегда доминировать в управлении по мере роста сообщества.

<figure><img src="/files/2e1edf2281d9a419e2c930b7921357da1b4630e3" alt=""><figcaption></figcaption></figure>

**Числовой пример**

<table data-header-hidden><thead><tr><th width="156.2734375"></th><th width="95.9765625"></th><th width="107.88671875"></th><th width="101.30859375"></th><th width="94.51171875"></th><th></th></tr></thead><tbody><tr><td>Позиция</td><td>IBS</td><td>Блокировка</td><td>Эпоха</td><td><span class="math">\alpha(E)</span></td><td>Выпущено vIBS</td></tr><tr><td>Алиса (ранняя)</td><td>100</td><td>360д</td><td>E=1</td><td>1.00</td><td>400</td></tr><tr><td>Боб (средний)</td><td>100</td><td>360д</td><td>E=26</td><td>3.16</td><td>1,265</td></tr><tr><td>Кэрол (поздняя)</td><td>100</td><td>360д</td><td>E=52</td><td>10.00</td><td>4,000</td></tr></tbody></table>

В Эпохе 52 400 vIBS у Алисы составляют 10% от 4 000 vIBS у Кэрол — несмотря на идентичные параметры стейкинга. Это и есть механизм размывания в действии.

{% hint style="success" %}
📐 Почему такой дизайн?

Традиционные модели veToken (Curve, Convex) решают размывание через временной спад: ваша сила голосования уменьшается по мере приближения срока блокировки к завершению. POTS не может использовать этот механизм, потому что vIBS выпускается задним числом и не может быть уничтожен. Коэффициент инфляции эпохи достигает того же экономического результата — постепенного размывания ранних позиций — другим математическим путём.
{% endhint %}

#### Параметры управления

| Параметр                         | Символ   | Начальное значение           | Управление        |
| -------------------------------- | -------- | ---------------------------- | ----------------- |
| Длительность эпохи               | $$\tau$$ | 1 неделя                     | настраивается DAO |
| Темп роста инфляции              | $$r$$    | $$10^{1/51} \approx 1.0462$$ | настраивается DAO |
| Целевое размывание (Эпоха 52)    | —        | 10%                          | настраивается DAO |
| Минимальное обсуждение на форуме | —        | 3 дня                        | настраивается DAO |
| Окно голосования                 | —        | 5 дней                       | настраивается DAO |
| Порог кворума                    | —        | 10% от общего объёма vIBS    | настраивается DAO |
| Порог принятия                   | —        | >50% «За»                    | настраивается DAO |
| Задержка timelock                | —        | 48 часов                     | настраивается DAO |
| Порог мультисиг                  | —        | 25 из 50                     | настраивается DAO |

> Все параметры подлежат управлению DAO. См. таблицу справки по параметрам.
