GH GambleHub

Общая ликвидность в сети

(Раздел: Экосистема и Сеть)

1) Что такое «общая ликвидность» и зачем она нужна

Общая ликвидность — это совокупность денежных и токенизированных активов, распределенных по узлам/цепям/платежным рельсам и доступных участникам сети (операторы, провайдеры, студии, платежные/KYC-провайдеры, аффилиаты) по предсказуемым правилам. Цели:
  • Скорость и предсказуемость выплат/переводов при минимальном RTO/RPO.
  • Эффективное использование капитала: меньше «мертвых остатков» и двойного резервирования.
  • Интероперабельность между доменами: мосты, банки, PSP, стейблы, on/off-ramp.
  • Контролируемые риски: лимиты, буферы, страхование, мониторинг.

2) Модели ликвидности

2.1 Централизованная (custodial hub)

Единый «ликвидити-хаб» держит пулы по регионам/валютам/цепям. Просто внедрять, но выше контрагентский риск и SPOF-риски. Подходит для старта/малых сетей.

2.2 Децентрализованная (пулы по доменам)

Ликвидность хранится у множества провайдеров/маркет-мейкеров (ММ), обмен — по смарт-контрактам/каналам. Выше устойчивость, нужна продвинутая маршрутизация и on-chain правила.

2.3 Гибридная (рекомендуется)

Хабы для критичных валют/выплат + внешние ММ/мосты для масштабирования. Управление — через политику лимитов, залогов и страховой фонд.

3) Топология и объекты

Пулы ликвидности (LP): `LP{домен, валюта/актив}` с атрибутами: остаток, буфер, лимиты, стоимость капитала (CoC), комиссия.
Кредитные линии (CL): двусторонние/многосторонние лимиты с обеспечением и ценой за использование.
Мосты: механика lock/mint/burn/release или messaging-only + неттинг.
Ребра маршрутизации: допустимые пути перевода (on-us, между LP, через мост/банк/PSP).
Страховой фонд: покрывает дефициты в пределах политики.

4) Ключевые метрики и формулы

Liquidity Depth (LD) — доступный объем в пуле на горизонте `T`:
  • `LD_T = Balance_T - Reserved_T`
  • Utilization (U) — загрузка пула: `U = Used / (Balance)`
Coverage Ratio (CR) — покрытие 95-го перцентиля спроса:
  • `CR = Available / P95(Demand_T)` (целевое ≥ 1.5×)
Buffer % (BUF) — страховой буфер к дневному нетто-потоку:
  • `BUF = Buffer / P95(NetFlow_daily)`
  • Rebalance MTTR — медиана времени закрытия дисбаланса после триггера.
  • Cost-to-Serve (CTS per $) — суммарная комиссия/газ/спрэд на $ перевода.
  • Payout SLA Hit Rate — доля выплат ≤ целевой минуты/блоков.
Slippage/Quote Error —котировка − фактическая цена/ котировка.

SLO (ориентиры): Payout SLA hit ≥ 98–99%; CR ≥ 1.5×; Rebalance MTTR ≤ 30 мин; CTS per $ ↓ QoQ на 10–15%.

5) Маршрутизация (SOR — Smart Order Routing)

5.1 Цель

Выбрать путь с минимальной полной стоимостью и риском при соблюдении SLA/лимитов.

5.2 Стоимость пути

`TotalCost = Fee + Gas + Slippage + LiquidityPenalty + TimePenalty + RiskAdj`

LiquidityPenalty: штраф за U>70% или CR<целевого.
TimePenalty: за прогнозируемую финализацию/окно спора.
RiskAdj: санкционные/страно- и контрагентские риски.

5.3 Тактика

Split routing: делить крупные переводы по нескольким LP/мостам.
Pre-funding: предварительная зарядка LP в часах пиков.
Quote locking: фиксировать цену на короткое окно, с динамической наценкой при низком CR.
Retry/alt-path: идемпотентные повторы по резервным путям при деградации.

6) Комиссии и прайсинг

Base fee (bps) + priority fee при высоких SLA.
Dynamic spread: растет при U>80% или высокой волатильности.
Tiering: ниже для «хороших граждан» сети (низкий риск, стабильные обороты).
Negative fee промо: для стимуляции направления с дефицитом ликвидности (rebalance by demand).

7) Ребаланс ликвидности

7.1 Триггеры

Пороговый: `U>80%` или `CR<1.2`.
Прогнозный: всплески ожидаемого спроса (ML/сезонность).
Событийный: блокировки/форки/рост комиссий в целевом домене.

7.2 Стратегии

TWAP/VWAP-переливы: равномерно во времени/по объемам.
Atomic swap через мост/DEX (для токенов).
Неттинг: клиринг взаимных обязательств в конце окна (час/день).
Rebalance auctions: внешние ММ закрывают дисбаланс по аукционной цене.
Cross-currency hedge: хеджирующие сделки для стабилизации USD-эквивалента.

7.3 Политика приоритета

Деньги/выплаты > критичные операционные переводы > прочие.

8) Риск-менеджмент

Run-риски: всплеск заявок на вывод → лимиты скорости, динамический спрэд, временное удлинение SLA.
Концентрация: лимит экспозиции на контрагента/цепь/банк.
Юрисдикции и санкции: списки, гео-ограничения, off-ramp с KYC/KYB.
Технологические: отказ мостов/PSP, рост газ-цен, реорги/окна спора.
Операционные: утечки ключей, ошибочные мэппинги активов, неверные котировки.
Страхование: фонд риска + перестрахование; прозрачная политика покрытий.

9) Межцепная ликвидность и мосты

Модель доверия: предпочтительно light-client/ZK для денег; optimistic — с увеличенным окном.
Ликвидити-сети: каналы/ММ с HTLC/гарантированными квитанциями.
Пулинг стейблов: единый канонический реестр активов, учет decimals, адресов, курсов.
Неттинг по мостам: батч-клиринг для снижения газ-затрат и времени.

10) Комплаенс и аудит

KYC/KYB для влияющих ролей и крупных лимитов.
AML/санкции до и после перевода (velocity/поведенческие фильтры).
Аудит логов и конфигов: подписи, неизменяемые реестры решений.
Data residency/PII: шифрование, псевдонимизация, раздельные витрины.

11) Наблюдаемость, SLO и дашборды

SLI (пример):
  • p50/p95 Time-to-Payout, Success-Rate, CTS per $, Utilization%, CR, Backlog, Rebalance MTTR, Quote Error, Liquidity Utilization of pool.
SLO (пример):
  • Payout p95 ≤ 5 мин (межсеть — ≤ финализационного окна), Success-Rate ≥ 99.5%, CR ≥ 1.5×, Relay/Bridge availability ≥ 99.9%.
Дашборды:
  • Ops (час): Success-Rate, p95 TTP, U%, CR, backlog, burn-rate SLO.
  • Liquidity & Cost (день): TVL/Net-flow по доменам, CTS per $, fee доход, страховка.
  • Risk (неделя): экспозиции, санкционные хиты, near-run индикаторы, отказ мостов.

12) Примеры конфигураций (псевдо-YAML)

Политика пулов и лимитов

yaml liquidity:
pools:
- id: "LP:EU:EUR"
min_buffer_pct: 60 max_utilization_pct: 85 rebalance_threshold:
cr_min: 1. 3 utilization_max: 0. 80 fees_bps:
base: 8 priority: 5
- id: "LP:TR:TRY"
min_buffer_pct: 70 max_utilization_pct: 80 credit_lines:
- from: "LP:EU:EUR"
to:  "LP:TR:TRY"
limit: 2_000_000 collateral: "USDC"
rate_bps_daily: 1. 5 bridges:
- pair: ["ETH", "Polygon"]
finality:
mode: light_client confirmations: 20 rate_limits:
per_minute: 300 per_hour: 12000

SOR-параметры

yaml routing:
split_max_parts: 4 risk_adjustments:
utilization_penalty_bps: 25 # for every% over 70%
cr_penalty_bps: 50       # за CR<1. 2 time_penalty_ms_per_min: 5 prefer_paths: ["on-us", "light-client", "mm-auction"]

13) Примеры запросов (псевдо-SQL)

Загрузка и покрытие

sql
SELECT pool_id,
AVG(utilization) AS u_avg,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily) AS p95_demand,
AVG(available) / NULLIF(PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily),0) AS cr
FROM liquidity_snapshots
WHERE ts >= now() - INTERVAL '30 days'
GROUP BY pool_id;

SLA выплат

sql
SELECT date_trunc('hour', finished_at) AS h,
100. 0 AVG(CASE WHEN EXTRACT(EPOCH FROM (finished_at - created_at)) <= sla_sec THEN 1 ELSE 0 END) AS payout_sla_hit
FROM payouts
WHERE created_at >= now() - INTERVAL '7 days'
GROUP BY 1;

CTS per $

sql
SELECT date_trunc('day', ts) AS d,
SUM(fees + gas + slippage_cost) / NULLIF(SUM(amount_usd),0) AS cts_per_usd
FROM transfers_costs
WHERE ts >= current_date - INTERVAL '30 days'
GROUP BY 1;

14) Операционные регламенты

Ежедневно: сверка остатков LP, отчет по CR/U/MTTR, автоматический ребаланс по расписанию пиков.
Недельный комитет: корректировка лимитов, комиссий, маршрутов; анализ CTS и отказов.
Инциденты SEV: единый «стоп-кран» на пары доменов, публичные статусы, пост-мортем ≤ 72 ч.
Ротация ключей и конфигов: подписи, timelock, откаты.

15) Playbook инцидентов

CR падает < 1.2 и растет backlog

Включить приоритетные ребалансы TWAP, поднять комиссии/спрэд, включить split-routing; уведомить затронутых партнеров с ETA.

Run-сценарий (массовые выводы)

Активировать лимиты скорости/квоты, временно увеличить окна SLA, задействовать страховой фонд и аукцион ММ.

Отказ моста/рост финализации

Переключиться на альтернативный путь (messaging-only + неттинг или резервный мост), поднять K-confirmations, обновить котировки.

Санкционные/AML триггеры

Заморозить соответствующие пула/направления, ручной ревью, отчет комплаенсу, обновление правил скоринга.

Ошибка мэппинга актива/курса

Стоп торгов по активу, откат справочника, перерасчет аффектированных переводов, публичная заметка.

16) Чек-лист внедрения

1. Опишите пулы/лимиты/буферы и минимальные CR по доменам.
2. Включите SOR с учетом полной стоимости пути и рисков.
3. Настройте ребаланс (пороговый + TWAP/VWAP) и неттинг.
4. Определите SLI/SLO (SLA выплат, CR, MTTR, CTS) и дашборды.
5. Запустите страховой фонд и аукционы ММ для дефицитов.
6. Утвердите комплаенс-политику (KYC/KYB/AML/санкции).
7. Проведите chaos- и стресс-тесты (run, отказ мостов, газ-спайки).
8. Регулярно ревизируйте комиссии, маршруты и лимиты.

17) Глоссарий

LP (Liquidity Pool) — пул ликвидности в домене/валюте.
CR (Coverage Ratio) — коэффициент покрытия спроса пулом.
U (Utilization) — доля использованной ликвидности.
SOR (Smart Order Routing) — интеллектуальная маршрутизация платежей/трансферов.
TWAP/VWAP — стратегии плавного перелива по времени/объему.
CTS per $ — стоимость обслуживания $ перевода.
Run-risk — риск массового изъятия ликвидности.
Netting — клиринг взаимных обязательств батчами.

Итог: общая ликвидность — это управляемая система правил, пулов и маршрутов, где капитал работает эффективно, а выплаты выполняются быстро и предсказуемо. Комбинируя гибридную топологию, SOR, динамические комиссии, строгие SLO и дисциплину ребаланса, экосистема получает устойчивую, масштабируемую и экономически оптимальную сетевую ликвидность.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.