Перейти к основному содержанию
Стратегическая дорожная карта. Эта страница описывает целевой дизайн для конфигурации стратегии под управлением сообщества в модели Agent Economy. Текущие развёрнутые контракты пока не включают StrategyConfig в описанной здесь форме — см. Overview для деталей перехода V1/V2.

Роль Strategy Layer

Strategy Layer — единственное место в Agent Economy, где живёт дискреция — и эта дискреция принадлежит сообществу, не любому индивиду или команде. Он определяет границы, внутри которых работают агенты. Агенты оптимизируют как и когда. Strategy определяет что и сколько. Каждый параметр, который мог бы внести оценочное суждение, риск или мнение по выбору активов, поднимается на этот слой и управляется futarchy. Слой агентов намеренно лишён выборов уровня политики.

StrategyConfig — on-chain конфигурация

Каждая управляемая поверхность (RWT Vault, Liquidity Nexus, Areal Treasury) поддерживает свой собственный PDA StrategyConfig. Агенты читают этот конфиг при каждом действии и проверяют, что действие остаётся внутри его границ.

RWT Vault StrategyConfig — ключевые параметры

pub struct RwtVaultStrategyConfig {
    // — Вселенная активов —
    pub allowed_ot_mints: Vec<Pubkey>,            // whitelist OT, которые vault может приобретать
    pub allowed_swap_venues: Vec<Pubkey>,         // адреса пулов DEX, через которые агенты могут маршрутизировать

    // — Границы аллокации —
    pub max_alloc_per_ot_bps: u16,                // лимит концентрации одного OT (напр. 2500 = 25%)
    pub max_total_ot_exposure_bps: u16,           // суммарные OT vs резерв (напр. 8000 = 80%)
    pub min_reserve_usdc_bps: u16,                // минимум ликвидного USDC (напр. 1000 = 10%)

    // — Рамки исполнения —
    pub max_daily_swap_volume_usdc: u64,          // дневной circuit breaker (в USDC)
    pub max_single_swap_volume_usdc: u64,         // лимит на транзакцию
    pub max_slippage_bps: u16,                    // допуск slippage на сделку

    // — Триггеры ребалансировки —
    pub rebalance_deviation_bps: u16,             // минимальный дрейф аллокации перед действием
    pub rebalance_cooldown_secs: u32,             // минимальный промежуток между последовательными ребалансировками

    // — Распределение доходности —
    pub yield_split: YieldSplit {
        book_value_bps: u16,                      // по умолчанию 7000 → рост NAV
        arl_treasury_bps: u16,                    // по умолчанию 1500
        nexus_bps: u16,                           // по умолчанию 1500
    },

    // — Безопасность —
    pub kill_switch_active: bool,                 // когда true, все мутирующие действия агентов отклоняются
    pub last_config_update_ts: i64,               // время блока последнего применённого обновления
    pub config_version: u64,                      // монотонный счётчик
    pub timelock_tier: Tier,                      // Operational | Critical — определяет следующее время разблокировки
    pub pending_update_unlock_ts: Option<i64>,    // если установлено, агенты видят старый конфиг до этого времени
    pub bump: u8,
}

Nexus StrategyConfig

pub struct NexusStrategyConfig {
    pub master_pool_funding_priority: Vec<Pubkey>,   // упорядоченный список: какой мастер-пул заполняется первым
    pub max_active_zone_width: u16,                  // лимит на ACTIVE_ZONE_WIDTH для grow_liquidity
    pub min_nexus_usdc_reserve_bps: u16,             // никогда не разворачивать ниже этого уровня
    pub geometric_density_r_bps: u16,                // текущий параметр r (по умолчанию 8500 = 0.85)
    pub permanent_tail_refill_enabled: bool,         // разрешает ли governance пополнение хвоста
    pub kill_switch_active: bool,
    pub config_version: u64,
    // ... те же поля метаданных
}

Treasury StrategyConfig

pub struct TreasuryStrategyConfig {
    pub allowed_ot_holdings: Vec<Pubkey>,            // OT, которые Treasury может накапливать независимо от RWT Vault
    pub max_treasury_ot_exposure_bps: u16,
    pub runway_months_minimum: u8,                   // резерв USDC, достаточный на N месяцев операций
    pub allowed_third_party_venues: Vec<Pubkey>,
    pub kill_switch_active: bool,
    pub config_version: u64,
    // ... те же поля метаданных
}
Каждая инструкция, вызываемая агентом, читает соответствующий PDA StrategyConfig и отклоняется с типизированной ошибкой (StrategyConfigViolation, KillSwitchActive, TimelockNotElapsed), если любая граница нарушена. Это не «бот проверяет» — это «контракт отклоняет». Агенты не могут произвести состояние вне границ даже если скомпрометированы.

Двухуровневый timelock

Не все изменения параметров несут равный риск. Ужесточение slippage на 10 bps — рутина. Добавление нового OT в whitelist — решение об аллокации капитала с асимметричным риском. Модель timelock отражает это:

Operational-уровень — timelock 24ч

Параметры, изменение которых влияет только на поведение исполнения внутри уже одобренной вселенной. Обновления применяются через 24 часа после разрешения предложения futarchy.Включает:
  • max_slippage_bps
  • rebalance_deviation_bps
  • rebalance_cooldown_secs
  • max_daily_swap_volume_usdc / max_single_swap_volume_usdc
  • geometric_density_r_bps
  • max_active_zone_width

Critical-уровень — 7-дневный timelock

Параметры, изменение которых расширяет вселенную разрешённых действий или переформирует экономику. Обновления применяются через 7 дней после разрешения предложения — время для держателей выйти, если они не согласны.Включает:
  • allowed_ot_mints (любое добавление или удаление)
  • allowed_swap_venues / allowed_third_party_venues
  • max_alloc_per_ot_bps
  • max_total_ot_exposure_bps
  • min_reserve_usdc_bps / runway_months_minimum
  • yield_split (любое перераспределение)

Kill switch — мгновенно вкл, медленно выкл

Поле kill_switch_active — единственный параметр с асимметричным timelock:

Активация: мгновенно

Три независимых пути могут выставить kill_switch_active = true с нулевой задержкой: (1) Halt Bond — любой вносит стейк 1% от supply ARL как залог под остановку, (2) Pause Authority (Team Multisig) как операционная страховка, или (3) разрешённое аварийное предложение futarchy. У каждого пути свой компромисс доверие / скорость.

Деактивация: 7-дневный timelock

Повторное включение активности агентов требует полного 7-дневного timelock, даже если активация была запущена по ошибке. Безопасность склоняется к осторожности. Деактивация — governance-действие уровня critical; ни один останавливающий не может в одностороннем порядке отменить свою остановку.

Halt Bond — экономический триггер остановки

Вместо выборного органа стражей протокол использует модель со ставкой в игре. Любой может запустить аварийную остановку, но должен внести реальную экономическую ставку как залог под легитимность вызова остановки. Плохие решения дороги; хорошие — вознаграждаются.

Размер залога — 1% от supply ARL

Вносится в токенах ARL, рассчитывается относительно текущего supply в обращении на момент отправки. Достаточно велик, чтобы отпугнуть спам (существенный капитал под риском); достаточно мал, чтобы решительные держатели или координирующиеся группы могли его собрать при необходимости.

Мгновенная остановка при стейке

Та же транзакция, которая блокирует залог, выставляет kill_switch_active = true. Протокол останавливается в пределах одного блока. Никакой координации, никакого multisig, никаких выборов — экономического обязательства достаточно.

Обзор — была ли остановка оправдана

В течение 7-дневного окна обзора назначенный ревьюер (V1: Team Multisig / V2: предложение futarchy) оценивает, была ли остановка обоснована. Доказательства публикуются on-chain; вердикт обязателен к исполнению.

Асимметричные исходы

Оправдан → залог возвращается вызывающему + опциональный бонус из Treasury, масштабируемый к предотвращённому ущербу. Не оправдан → залог полностью уходит в Казначейство Areal. Никаких промежуточных исходов.

Поток активации

1

Обнаружение

Любой участник наблюдает аномалию через on-chain мониторы, отчёты сообщества, отправки bug bounty или аудит-события.
2

Стейк залога

Вызывающий отправляет инструкцию activate_kill_switch_with_bond, переводящую 1% от supply ARL в обращении в токенах ARL в замороженный PDA HaltBondEscrow. Та же транзакция выставляет kill_switch_active = true.
3

Автоматическая остановка

Все инструкции агентов в RWT Vault, Nexus и Treasury отклоняются с KillSwitchActive на следующем вызове. Пользовательские операции не затронуты.
4

Открытие окна обзора

7 дней. Вызывающий публикует обоснование (on-chain memo в транзакции стейка). Ревьюер (Team Multisig в V1, futarchy в V2) изучает доказательства и выносит вердикт.
5

Вердикт: Оправдан

Залог освобождается обратно вызывающему. Опциональный бонус выплачивается из Казначейства Areal, пропорциональный предотвращённому ущербу (задаётся governance, предлагаемый потолок 5% от предотвращённой потери). Вызывающий может предложить повторную активацию через стандартный 7-дневный поток governance.
6

Вердикт: Не оправдан

Залог полностью уходит в Казначейство Areal. Вызывающий добавляется в список cooldown’а на кошелёк (30 дней до того, как тот же кошелёк может внести стейк для другой остановки). Timelock повторной активации продолжается.

Параметры

ПараметрЗначениеОбоснование
Размер залога1% от ARL в обращении (измеряется на момент транзакции)Высокий барьер для ложных остановок; достижим для скоординированного ответа на реальные угрозы
Окно обзора7 днейСимметрично с timelock повторной активации kill switch
Потолок бонуса5% от предотвращённого ущерба (задаётся governance)Осмысленная награда без перекоса в сторону избыточных остановок
Cooldown после потери30 дней на кошелёкПредотвращает цикл повторяющегося нарушителя
Деноминация стейкаARL (не USDC)Интересы останавливающего согласованы с выживанием протокола

Почему экономический залог лучше выборного совета

Прошлый дизайн рассматривал выборный сообществом Safety Council (7 членов, supermajority 4-of-7). Модель залога строго проще и экономически чище:
ПроблемаSafety CouncilHalt Bond
Кто может запустить7 конкретных людейЛюбой с 1% ARL
Накладные расходы выборовЕжегодно на каждое местоНет
Личное раскрытиеТребуетсяНе нужно
КомпенсацияЕжемесячная стипендия из TreasuryНет; останавливающий финансируется своим стейком
Исход плохой остановкиУщерб репутации, возможное удалениеTreasury получает 1% от supply
Устойчивость к griefingРепутационная ставка1% от supply под риском
Согласованность с этикой futarchyЛичная ответственностьЭкономическая ответственность
Модель залога также самофинансируется: неоправданные остановки растят Treasury, а не стоят стипендий. Если механизм хорошо откалиброван, плохие акторы финансируют рост протокола.

Резервные полномочия

Два параллельных пути остаются для сценариев, где Halt Bond слишком медленный или неуместный:
  • Pause Authority (Team Multisig) — независимая мгновенная остановка без требования залога, зарезервирована для zero-day эксплойтов, наблюдаемых во время активной атаки, где даже сборка 1% ARL занимает слишком долго
  • Аварийное предложение governance — остановка через futarchy без залога, но медленнее (требует жизненный цикл предложения для разрешения)
Три пути с разными компромиссами скорости/стоимости. Любой может действовать; ни один не может блокировать другие.

Жизненный цикл предложения futarchy

┌──────────────────┐
│  1. Отправка     │  Держатель ARL отправляет предложение StrategyUpdate,
│     предложения  │  ссылающееся на текущую версию StrategyConfig и запрошенные дельты
└──────────────────┘


┌──────────────────┐
│  2. Открытие     │  Открываются два рынка: pass-ARL и fail-ARL
│     условных     │  Оба получают равную начальную ликвидность из Treasury
│     рынков       │
└──────────────────┘


┌──────────────────┐
│  3. Период       │  Участники торгуют по ожидаемой цене токена при каждом исходе
│     торговли     │  Длительность: 72 часа (operational) / 168 часов (critical)
└──────────────────┘


┌──────────────────┐
│  4. Разрешение   │  Time-weighted average prices сравниваются в конце окна
│     по TWAP      │  Если pass-TWAP > fail-TWAP + epsilon: предложение проходит
└──────────────────┘


┌──────────────────┐
│  5. Окно         │  Ожидающий конфиг записывается on-chain с unlock_ts
│     timelock     │  Агенты продолжают читать старый конфиг в течение окна
└──────────────────┘


┌──────────────────┐
│  6. Применение   │  По unlock_ts любой может permissionless вызвать
│     (permission- │  apply_strategy_update — новый конфиг становится действующим
│      less crank) │  config_version инкрементируется; эмитируются события
└──────────────────┘

Разбор — обновление operational-уровня

Предложение #83: Ужесточить max_slippage_bps с 100 (1%) до 50 (0.5%) на RWT Vault.
  1. Держатель ARL отправляет с полезной нагрузкой {surface: RwtVault, param: max_slippage_bps, from: 100, to: 50}
  2. Рынки pass / fail открываются с начальной ликвидностью 5k ARL на сторону
  3. 72-часовое окно торговли. Pass-TWAP оседает на 1.084, fail-TWAP на 1.076 — pass выигрывает
  4. Timelock 24ч (operational-уровень)
  5. После истечения 24ч crank apply_strategy_update запускается: config_version 18 → 19
  6. Следующее действие агента читает config v19, принудительно применяет новый slippage 50 bps

Разбор — обновление critical-уровня

Предложение #91: Добавить новый OT PROJ2K3mint... в allowed_ot_mints на RWT Vault.
  1. Отправка включает полное обоснование и ожидаемую цель аллокации
  2. Рынки pass / fail открываются с начальной ликвидностью 20k ARL на сторону (больше для critical)
  3. 168-часовое окно торговли. Разрешается в пользу pass
  4. Timelock 7 дней
  5. В течение 7 дней:
    • pending_update_unlock_ts виден on-chain
    • Держатели, которые не согласны, имеют полную неделю для выхода через DEX или через путь погашения mint_rwt (если включён)
    • Агенты не читают ожидающее обновление
  6. После 7 дней apply_strategy_update делает изменение whitelist действующим

Матрица покрытия параметров

ПараметрПоверхностьУровеньОбоснование
allowed_ot_mintsRWT VaultCritical (7д)Расширяет вселенную разрешённых приобретений
allowed_swap_venuesRWT Vault, Nexus, TreasuryCritical (7д)Подвергает капитал контрактам новых контрагентов
max_alloc_per_ot_bpsRWT VaultCritical (7д)Лимиты концентрации ограничивают максимальную потерю по одному активу
max_total_ot_exposure_bpsRWT VaultCritical (7д)Отношение резерва к развёрнутому капиталу
min_reserve_usdc_bpsRWT VaultCritical (7д)Минимум ликвидности
yield_splitRWT VaultCritical (7д)Перераспределяет экономические потоки
max_daily_swap_volume_usdcRWT Vault, NexusOperational (24ч)Circuit breaker — ужесточение или ослабление
max_single_swap_volume_usdcRWT Vault, NexusOperational (24ч)Лимит на транзакцию
max_slippage_bpsВсеOperational (24ч)Параметр качества исполнения
rebalance_deviation_bpsNexusOperational (24ч)Чувствительность триггера
rebalance_cooldown_secsNexusOperational (24ч)Anti-thrash
geometric_density_r_bpsNexusOperational (24ч)Форма density в существующем диапазоне
kill_switch_active (→ on)ВсеМгновенноБезопасность не может ждать
kill_switch_active (→ off)ВсеCritical (7д)Повторная активация серьёзна

Почему не один большой timelock

Единый длинный timelock (скажем, все изменения занимают 7 дней) кажется безопаснее, но ломается операционно: если параметр slippage выставлен слишком широко и агенты теряют ценность на MEV, протокол не может реагировать неделю. Единый короткий timelock (24ч на всё) теряет свойство окна выхода для критических изменений. Многоуровневая модель сохраняет оба:
  • Операционные параметры настраиваются в течение дня — протокол остаётся гибким
  • Критические параметры дают несогласным держателям полную неделю голосовать ногами
  • Kill switch всегда мгновенен — безопасность не торгуема
Это прямая аналогия ускоренного vs обычного процесса поправок, на котором сошлись хорошо спроектированные DAO-governance рамки (Compound, MakerDAO, Uniswap) — классифицированные по радиусу поражения, а не по единообразной политике.

Что не может быть изменено governance

Некоторые инварианты захардкожены в слое контракта и не могут быть изменены даже успешными предложениями futarchy. Попытка требует обновления программы, подписанного upgrade authority (Team Multisig при запуске) — отдельный, более медленный путь. Примеры жёстких инвариантов:
  • Fund conservation во время compress_liquidity (общий капитал не должен уменьшаться)
  • Kill switch не может быть обойдён никакой инструкцией
  • Пропуск комиссии на пути mint применяется только к подлинным маршрутам mint
  • Permanent tail bins никогда не списываются
  • NAV RWT не может быть снижен ниже MIN_CAPITAL_FLOOR (предотвращает NAV = 0)
Они живут в Contract Layer и представляют пол защиты держателей, который никакой исход governance не может подорвать.

Резюме

Агенты, связанные governance

Каждый агент читает StrategyConfig как жёсткие ограничения — не может превысить границы даже при компрометации

Двухуровневый timelock

24ч operational / 7д critical — баланс между гибкостью и возможностью выхода держателей

Мгновенный kill switch

Активация имеет нулевую задержку. Деактивация — 7-дневный timelock. Безопасность асимметрична по дизайну.

Конфиг на поверхность

RWT Vault, Nexus и Treasury — у каждого свой StrategyConfig — независимые пути обновления

Аудит-след встроен

Каждое изменение параметра несёт ID предложения, свидетельство TWAP, версию конфига, временную метку разблокировки

Захардкоженные инварианты

Fund conservation, достижимость kill switch и критические проверки безопасности не могут быть изменены governance