GH GambleHub

Liquidez total en la red

(Sección: Ecosistema y Red)

1) Qué es la «liquidez total» y por qué es necesaria

La liquidez total es el conjunto de activos monetarios y tokenizados distribuidos a través de nodos/cadenas/carriles de pago y disponibles para los miembros de la red (operadores, proveedores, estudios, proveedores de pago/CUS, afiliados) bajo reglas predecibles. Objetivos:
  • Velocidad y previsibilidad de pagos/transferencias con un mínimo de RTO/RPO.
  • Uso eficiente del capital: menos «saldos muertos» y doble reserva.
  • Interoperabilidad entre dominios: puentes, bancos, PSP, stables, on/off-ramp.
  • Riesgos controlados: límites, amortiguadores, seguros, monitoreo.

2) Modelos de liquidez

2. 1 Centralizado (hub custodial)

Un único «centro de liquidación» mantiene los grupos por región/moneda/cadena. Simplemente implementar, pero por encima del riesgo de contraparte y los riesgos SPOF. Adecuado para redes de arranque/pequeñas.

2. 2 Descentralizado (grupos por dominio)

La liquidez se almacena en muchos proveedores/creadores de mercado (MM), el intercambio es a través de contratos/canales inteligentes. Por encima de la estabilidad, se necesita un enrutamiento avanzado y reglas on-chain.

2. 3 Híbrido (recomendado)

Hubs para monedas/pagos críticos + MM/puentes externos para escalar. Gestión - a través de la política de límites, fianzas y fondo de seguros.

3) Topología y objetos

Grupos de liquidez (LP): 'LP {dominio, moneda/activo}' con atributos: saldo, amortiguador, límites, valor de capital (CoC), comisión.
Líneas de crédito (LC): límites bilaterales/multilaterales con garantía y precio por uso.
Puentes: mecánica lock/mint/burn/release o messaging-only + netting.
Costillas de enrutamiento: rutas de traducción válidas (on-us, entre LP, a través del puente/banco/PSP).
Fondo de seguros: cubre los déficits dentro de la póliza.

4) Métricas y fórmulas clave

Liquidity Depth (LD): volumen disponible en una agrupación en el horizonte 'T':
  • `LD_T = Balance_T - Reserved_T`
  • Utilidad (U): carga de la agrupación: 'U = Used/( Balance)'
Cobertura Ratio (CR) - Cobertura del percentil 95 de la demanda:
  • 'CR = Available/ P95 (Demand_T)' (objetivo ≥ 1. 5×)
Buffer% (BUF): búfer de seguro para flujo neto diario:
  • `BUF = Buffer / P95(NetFlow_daily)`
  • Rebalance MTTR es la mediana del tiempo de cierre del desequilibrio después del desencadenante.
  • Costo-a-Serve (CTS per $) es una comisión total/gas/sprade por $ de transferencia.
  • PayOut SLA Hit Rate - Porcentaje de pagos ≤ minutos/bloques objetivo.
Slippage/Quote Error —cotización − precio real/ cotización.

SLO (puntos de referencia): PayOut SLA hit ≥ 98-99%; CR ≥ 1. 5×; Rebalance MTTR ≤ 30 minutos; CTS per $ ↓ QoQ en un 10-15%.

5) Enrutamiento (SOR - Smart Order Routing)

5. 1 Objetivo

Elija una ruta con el costo total mínimo y el riesgo, respetando los límites/SLA.

5. 2 Costo de la ruta

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

LiquidityPenalty: penalización por U> 70% o CR <objetivo.
TimePenalty: por la finalización proyectada/ventana de disputa.
RiskAdj: riesgos sancionadores/pasivos y de contraparte.

5. 3 Tácticas

Split routing: dividir grandes traducciones a través de múltiples LP/puentes.
Pre-fundido: precarga del LP en horas de picos.
Quote locking: fijar el precio en una ventana corta, con un margen dinámico en un CR bajo.
Retry/alt-path: repeticiones idempotentes a lo largo de las vías de reserva durante la degradación.

6) Comisión y Prising

Base fee (bps) + prioridad fee en SLAs altos.
Dynamic spread: crece a U> 80% o alta volatilidad.
Tiering: más bajo para los «buenos ciudadanos» de la red (bajo riesgo, revoluciones estables).
Promo negative fee: para estimular una dirección con déficit de liquidez (rebalance by demand).

7) Reequilibrio de liquidez

7. 1 Disparadores

Umbral: 'U> 80%' o'CR <1. 2`.
Pronóstico: picos de demanda esperada (ML/estacionalidad).
Evento: bloqueos/forks/crecimiento de comisiones en el dominio de destino.

7. 2 Estrategias

Desbordamientos TWAP/VWAP: uniformemente en tiempo/volumen.
Atomic swap a través del puente/DEX (para tokens).
Netting: compensación de compromisos mutuos al final de la ventana (hora/día).
Subastas de rebalance: los MM externos cierran el desequilibrio en el precio de subasta.
Hedge cross-currency: operaciones de cobertura para estabilizar el equivalente a USD.

7. 3 Política de prioridad

Dinero/pagos> transferencias operacionales críticas> otros.

8) Gestión de riesgos

Riesgos de ejecución: aumento de solicitudes de retirada → límites de velocidad, spread dinámico, extensión temporal de SLA.
Concentración: límite de exposición por contraparte/cadena/banco.
Jurisdicciones y sanciones: listas, restricciones geográficas, off-ramp con KYC/KYB.
Tecnológico: falla de puentes/PSP, aumento de los precios del gas, reorgas/ventanas de disputa.
Operativo: fugas de claves, mappings erróneos de activos, cotizaciones incorrectas.
Seguros: fondo de riesgo + reaseguros; política transparente de recubrimientos.

9) Liquidez entre cadenas y puentes

Modelo de confianza: preferiblemente light-client/ZK para dinero; optimistic - con ventana ampliada.
Redes de liquidación: canales/MM con HTLC/recibos garantizados.
Puling Stables: registro canónico único de activos, contabilidad de decimals, direcciones, cursos.
Netting en los puentes: batch clearing para reducir los costos de gas y el tiempo.

10) Cumplimiento y auditoría

KYC/KYB para roles influyentes y grandes límites.
AML/sanciones antes y después de la traducción (velocity/filtros de comportamiento).
Auditoría de registros y confecciones: firmas, registros de soluciones inmutables.
Residencia de datos/PII: cifrado, pseudonimización, escaparates separados.

11) Observabilidad, SLO y dashboards

SLI (ejemplo):
  • p50/p95 Time-to-Payout, Success-Rate, CTS per $, Utilization%, CR, Backlog, Rebalance MTTR, Quote Error, Liquidity Utilization of pool.
SLO (ejemplo):
  • PayOut p95 ≤ 5 min (entre redes - ≤ de la ventana de finalización), Success-Rate ≥ 99. 5%, CR ≥ 1. 5×, Relay/Bridge availability ≥ 99. 9%.
Dashboards:
  • Ops (час): Success-Rate, p95 TTP, U%, CR, backlog, burn-rate SLO.
  • Liquidity & Cost (día): TVL/Net-flow por dominios, CTS per $, fee ingresos, seguro.
  • Risk (semana): exposiciones, golpes sancionadores, indicadores near-run, fallas en los puentes.

12) Ejemplos de configuraciones (pseudo-YAML)

Política de grupos y límites

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

Parámetros 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) Ejemplos de consultas (pseudo-SQL)

Carga y cobertura

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;

Pagos 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) Reglamentos operativos

Diariamente: conciliación de residuos de LP, informe CR/U/MTTR, rebalanceo automático en el horario de pico.
Comité semanal: ajuste de límites, comisiones, rutas; Análisis de CTS y fallos.
Incidentes SEV: una sola «parada de grúa» en pares de dominios, estados públicos, post mortem ≤ 72 h.
Rotación de claves y confecciones: firmas, timelock, retrocesos.

15) Incidentes de Playbook

CR cae <1. 2 y crece backlog

Habilitar reajustes de prioridad TWAP, subir comisiones/sprad, habilitar split-routing; notificar a los socios afectados con ETA.

Escenario de ejecución (conclusiones masivas)

Active los límites de velocidad/cuota, aumente temporalmente las ventanas de SLA, implique un fondo de seguros y una subasta de MM.

Falla del puente/crecimiento de la finalización

Cambiar a una ruta alternativa (messaging-only + netting o puente de respaldo), elevar K-confirmations, actualizar las cotizaciones.

Activadores de sanciones/AML

Congelar los grupos/direcciones correspondientes, el rugido manual, el informe de cumplimiento, la actualización de las reglas de puntuación.

Error de mapeo de activos/cursos

Pare la negociación del activo, revierta el directorio, recalcula las transferencias afectadas, nota pública.

16) Lista de verificación de implementación

1. Describa los grupos/límites/búferes y los CR mínimos por dominio.
2. Incluya SOR teniendo en cuenta el costo total de la ruta y los riesgos.
3. Configure el rebalance (umbral + TWAP/VWAP) y el netting.
4. Identificar SLI/SLO (SLA de pago, CR, MTTR, CTS) y dashboards.
5. Ponga en marcha un fondo de seguros y subastas MM para los déficits.
6. Aprobar la política de cumplimiento (KYC/KYB/AML/sanciones).
7. Realice pruebas de chaos y estrés (run, fallas en los puentes, spikes de gas).
8. Revisa regularmente las comisiones, rutas y límites.

17) Glosario

LP (Liquidity Pool): grupo de liquidez en el dominio/moneda.
CR (Coverage Ratio) es el coeficiente de cobertura de la demanda de pool.
U (Utilización) es la parte de liquidez utilizada.
SOR (Smart Order Routing): enrutamiento inteligente de pagos/transferencias.
TWAP/VWAP - Estrategias de desbordamiento suave en tiempo/volumen.
CTS per $ - Costo de mantenimiento $ traducción.
Run-risk es el riesgo de desinversión masiva de liquidez.
Netting - Compensación de obligaciones recíprocas por batches.

En pocas palabras: la liquidez total es un sistema gestionado de reglas, agrupaciones y rutas donde el capital funciona de manera eficiente y los pagos se realizan de manera rápida y previsible. Al combinar topología híbrida, SOR, comisiones dinámicas, estrictos SLO y disciplina de rebalance, el ecosistema obtiene liquidez de red sostenible, escalable y económicamente óptima.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.