Перейти к основному содержимому

Аренда позиций ликвидности для продуктовых доступов

Метаданные​

ПараметрЗначение
Дата создания2026-07-28
Дата последнего изменения2026-07-28
Статус апрува⏳ На рассмотрении
Дата апрува—

Компания держит позиции ликвидности Uniswap V3. Пользователь, купивший продуктовый доступ (первый продукт — VIP), на ограниченное время получает право забирать комиссии, которые эта позиция зарабатывает. Сегодня покупка VIP не приносит дохода вовсе: клеймить можно только выигрыш VIP-лотереи, никак не связанный ни с VIP-статусом, ни со сроком его действия.

Полный технический дизайн: docs/superpowers/specs/2026-07-28-liquidity-rent-design.md.

2.1. Пользовательские сценарии​

  1. Покупка доступа. Пользователь оплачивает VIP. В той же транзакции ему выдаётся свободная позиция из пула, накопленный ею ранее доход уходит компании, стартует отсчёт аренды.
  2. Бесплатная активация. Пользователь с access-grant нажимает «Активировать», получает от бэкенда подпись и отправляет транзакцию активации.
  3. Клейм во время аренды. Пользователь забирает заработок позиции — одним токеном, если план так настроен, но не больше установленного потолка.
  4. Клейм после окончания. Заработанное фиксируется снапшотом, позиция сразу уходит следующему пользователю, а бывший арендатор ещё какое-то время может забрать снапшот. Окна для платных и бесплатных доступов разные.
  5. Сгорание. Не забрал до конца окна — остаток уходит компании.
  6. Завершение по доходности. Опционально доступ живёт не по таймеру, а пока пользователю не выплачен заданный процент от вложенной суммы (например, 200%).
  7. Лимит покупок. Не больше N покупок продукта на пользователя за настраиваемый период.

2.2. Бизнес-логика​

  • Позиции принадлежат контракту, управляются только админом.
  • Один арендатор на позицию; число одновременных доступов равно числу позиций в группе.
  • Потолок выплаты и процент доходности считаются в токене выплаты (payoutToken).
  • В порог доходности засчитывается только фактически выплаченное пользователю: срезанный потолком остаток уходит компании и к порогу не приближает.
  • В режиме «до X% доходности» действует жёсткий максимум времени — иначе низкодоходная позиция навсегда занимает слот.
  • Все параметры (длительности, окна клейма, потолок, процент, конвертация, лимит покупок) настраиваются в админке.

2.3. UI/UX требования​

  • /admin/vip — секция «Аренда ликвидности»: позиции и их состояние, планы аренды, лимит покупок.
  • /vip — карточка доступа: таймер, накопленный доход, прогресс к порогу, остаток потолка, кнопка «Забрать» с настройкой проскальзывания, предупреждение о сгорании.

3.1. Архитектура​

Новый контракт MagnetLiquidityRent (UUPS, contracts/MagnetLiquidity/) хранит позиции, планы и аренды. Он продукт-агностичен: VIP — лишь первый потребитель, второй продукт добавляется новым планом и своим хуком-грантором.

VipPaymentHook ужимается до кассы продукта — цена, лимит покупок, вызов аренды — и сохраняет прежний внешний ABI как view-прокси в аренду, поэтому бэкенд и админка не переписываются.

3.2. Описание технической реализации​

См. разделы 5–10 дизайн-документа: модель данных, жизненный цикл аренды, изменения хука, бэкенд-модуль liquidity-rent с кронами закрытия и зачистки, правки модуля vip, экраны фронтенда.

4. Проблемы и компромиссы​

4.1. Известные ограничения​

  1. Нет оракула цен
    • «Вложенная сумма» задаётся админом вручную в токене выплаты.
    • При сильном движении цены значение нужно пересматривать вручную.
  2. Доход не гарантирован
    • Позиция вне ценового диапазона не зарабатывает.
    • Требуется явное предупреждение в интерфейсе.

4.2. Технический долг​

  • Ручная «вложенная сумма» вместо оракула — вернуться, если появится надёжный источник цены.
  • Автоматическая ребалансировка позиций — в первой версии только вручную админом.

4.3. Риски​

  • MEV на свопе при клейме — проскальзывание задаёт пользователь, при закрытии аренды свопа нет вовсе.
  • Превышение лимита байткода 24 КБ — вынос тяжёлых операций в отдельный ops-контракт через delegatecall, паттерн уже применён в MagnetLiquidityShared.
  • Простой крона — ленивое закрытие просроченных аренд при следующей выдаче, окно клейма считается от времени закрытия, а не от вызова крона.

5. Вопросы на дополнительное обсуждение​

Разработку не блокируют, значения по умолчанию заданы в дизайне (раздел 15).

  • Стартовые параметры планов: сроки, окна клейма, потолок выплаты, целевой процент.
    • Кому адресовано: владелец продукта.

6. План реализации​

6.1. Этапы разработки​

  • Этап 1: Контракт аренды и hardhat-тесты
  • Этап 2: Правки VipPaymentHook (лимит покупок, вызов аренды, view-прокси)
  • Этап 3: Бэкенд: модуль liquidity-rent, кроны, правки модуля vip
  • Этап 4: Фронтенд: админка и карточка аренды на /vip
  • Этап 5: Деплой, настройка планов и позиций

6.2. Критические зависимости​

  • Ликвидность для первых позиций и решение по стартовым параметрам планов.
  • Операторский кошелёк с газом на Polygon для кронов закрытия и зачистки.

8. Документация​

  • Swagger для эндпоинтов liquidity-rent
  • Раздел в engineering-документации о механике аренды
  • Инструкция для админов по управлению позициями и планами

9. Ссылки​

  • Дизайн: docs/superpowers/specs/2026-07-28-liquidity-rent-design.md
  • Смежное: apps/docs/docs/tz/active/liquidity-nft.md