Liquidité totale sur le réseau
(Section : Écosystème et réseau)
1) Qu'est-ce que la « liquidité totale » et pourquoi il est nécessaire
La liquidité totale est un ensemble d'actifs monétaires et tokénisés répartis sur les nœuds/chaînes/rails de paiement et disponibles pour les membres du réseau (opérateurs, fournisseurs, studios, fournisseurs de paiement/CUS, affiliations) selon des règles prévisibles. Objectifs :- Rapidité et prévisibilité des paiements/transferts avec un minimum de RTO/RPO.
- Utilisation efficace du capital : moins de « soldes morts » et double réservation.
- Interopérabilité entre les domaines : ponts, banques, PSP, stables, on/off-ramp.
- Risques contrôlés : limites, tampons, assurances, surveillance.
2) Modèles de liquidité
2. 1 Centralisé (custodial hub)
Une seule « liquidité » maintient les pools par région/monnaie/chaîne. Il est facile de mettre en œuvre, mais au-dessus du risque de contrepartie et des risques SPOF. Convient pour le démarrage/petits réseaux.
2. 2 Décentralisé (pools par domaine)
La liquidité est stockée chez de nombreux fournisseurs/market maker (MM), l'échange est par des contrats/canaux intelligents. Plus de résilience, vous avez besoin d'un routage avancé et de règles en ligne.
2. 3 Hybride (recommandé)
Hobs pour les devises critiques/paiements + MM externes/ponts pour l'échelle. Gouvernance - par le biais de la politique de limitation, des garanties et de la caisse d'assurance.
3) Topologie et objets
Pools de liquidité (LP) : 'LP {domaine, monnaie/actif}' avec attributs : solde, tampon, limites, coût du capital (CoC), commission.
Lignes de crédit (CL) : limites bilatérales/multilatérales avec garantie et prix d'utilisation.
Ponts : mécanique lock/mint/burn/release ou messaging-only + netting.
Côtes de routage : chemins de traduction valides (on-us, entre LP, via pont/banque/PSP).
Fonds d'assurance : couvre les déficits dans les limites de la politique.
4) Mesures et formules clés
Liquide Depth (LD) est le volume disponible dans le pool à l'horizon "T' :- `LD_T = Balance_T - Reserved_T`
- Utilisation (U) - chargement du pool : 'U = Used/( Balance)'
- 'CR = Disponible/ P95 (Demand_T) '(cible ≥ 1. 5×)
- `BUF = Buffer / P95(NetFlow_daily)`
- Rebalance MTTR est la médiane du temps de fermeture du déséquilibre après le déclenchement.
- Cost-to-Serve (CTS per $) est une commission totale/gaz/sprade sur le transfert de $.
- Payout SLA Hit Rate - part de paiement ≤ la minute/bloc cible.
SLO (repères) : Payout SLA hit ≥ 98-99 %; CR ≥ 1. 5×; Rebalance MTTR ≤ 30 min ; CTS per $ ↓ QoQ de 10 à 15 %.
5) Routage (DORS - Smart Order Routing)
5. 1 Objectif
Choisissez un chemin avec un coût total minimum et un risque tout en respectant les SLA/limites.
5. 2 Coût du trajet
`TotalCost = Fee + Gas + Slippage + LiquidityPenalty + TimePenalty + RiskAdj`
LiquiditéPénalité : pénalité pour U> 70 % ou CR <cible.
TimePenalty : pour la finalisation/fenêtre de litige prévue.
RiskAdj : risques de sanctions/stran et de contrepartie.
5. 3 Tactiques
Split routing : diviser les traductions majeures sur plusieurs LP/ponts.
Pre-funding : pré-charge LP en heures de pointe.
Quote locking : fixez le prix d'une fenêtre courte, avec une marge dynamique à faible CR.
Retry/alt-path : répétitions idempotentes sur les voies de secours en cas de dégradation.
6) Commissions et prix
Base fee (bps) + priority fee à SLA élevé.
Spread dynamique : grandit à U> 80 % ou volatilité élevée.
Tiering : plus bas pour les « bons citoyens » du réseau (faible risque, chiffre d'affaires stable).
Negative fee promo : pour stimuler la direction avec un déficit de liquidité (rebalance by demand).
7) Rebalance des liquidités
7. 1 Déclencheurs
Seuil : 'U> 80 %' ou 'CR <1. 2`.
Prévisions : flambées de la demande attendue (ML/saisonnalité).
Evénement : verrouillages/forks/augmentation des commissions dans le domaine cible.
7. 2 Stratégies
Débordements TWAP/VWAP : uniformément dans le temps/en volume.
Swap Atomic via bridge/DEX (pour tokens).
Netting : compensation des obligations réciproques à la fin de la fenêtre (heure/jour).
Rebalance auctions : les MM externes comblent le déséquilibre sur le prix des enchères.
Cross-currency hedge : opérations de couverture pour stabiliser l'équivalent USD.
7. 3 Politique de priorité
Argent/décaissements> transferts d'exploitation critiques> autres.
8) Gestion des risques
Risques de course : augmentation des demandes de retrait → limites de vitesse, sprady dynamique, allongement temporaire des SLA.
Concentration : limite d'exposition par contrepartie/chaîne/banque.
Juridictions et sanctions : listes, géo-restrictions, off-ramp avec KYC/KYB.
Technologique : défaillance des ponts/PSP, hausse des prix du gaz, réorgues/fenêtres de litige.
Opérations : fuites de clés, mappings d'actifs erronés, cotations erronées.
Assurance : fonds de risque + réassurance ; une politique transparente de revêtement.
9) Liquidités et ponts inter-chaînes
Modèle de confiance : de préférence light-client/ZK pour l'argent ; optimistic - avec fenêtre agrandie.
Réseaux de liquidités : canaux/MM avec HTLC/reçus garantis.
Pooling stabls : un registre canonique unique des actifs, la comptabilité des décimales, des adresses, des cours.
Netting on Bridges : compensation par batch pour réduire les coûts et le temps de gaz.
10) Conformité et audit
KYC/KYB pour les rôles influents et les limites importantes.
AML/sanctions avant et après la traduction (velocity/filtres comportementaux).
Audit des logs et des configues : signatures, registres de solutions immuables.
Data residency/PII : cryptage, pseudonyme, vitrines séparées.
11) Observabilité, SLO et dashboards
SLI (exemple) :- p50/p95 Time-to-Payout, Success-Rate, CTS per $, Utilization%, CR, Backlog, Rebalance MTTR, Quote Error, Liquidity Utilization of pool.
- Payout p95 ≤ 5 min (Interset - ≤ de la fenêtre de finalisation), Success-Rate ≥ 99. 5%, CR ≥ 1. 5×, Relay/Bridge availability ≥ 99. 9%.
- Ops (час): Success-Rate, p95 TTP, U%, CR, backlog, burn-rate SLO.
- Liquidité & Cost (jour) : TVL/Net-flow par domaine, CTS per $, revenu fee, assurance.
- Risk (semaine) : expositions, succès de sanctions, indicateurs de près, défaillance des ponts.
12) Exemples de configurations (pseudo-YAML)
Politique de pools et limites
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
Paramètres du DORS
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) Exemples de requêtes (pseudo-SQL)
Téléchargement et couverture
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;
Paiement 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) Règlements opérationnels
Quotidien : rapprochement des résidus LP, rapport CR/U/MTTR, rééquilibrage automatique selon l'horaire des pics.
Comité hebdomadaire : ajustement des limites, des commissions, des itinéraires ; analyse des CTS et des pannes.
Incidents SEV : un seul « robinet stop » sur les paires de domaines, les statuts publics, post-mortem ≤ 72 h.
Rotation des clés et des configues : signatures, timelock, retraits.
15) Playbook des incidents
CR descend <1. 2 et backlog grandit
Inclure les rééquilibres prioritaires de TWAP, augmenter les commissions/sprady, inclure le split-routing ; aviser les partenaires touchés de l'ETA.
Run-script (conclusions massives)
Activer les limites de vitesse/quotas, augmenter temporairement les fenêtres SLA, activer le fonds d'assurance et la vente aux enchères MM.
Échec du pont/croissance de la finalisation
Passer à un autre chemin (messaging-only + netting ou pont de secours), soulever K-confirmations, mettre à jour les cotations.
Déclencheurs de sanctions/AML
Geler les pools/directions appropriés, la rhubarbe manuelle, le rapport à la conformité, la mise à jour des règles de notation.
Erreur de mappage de l'actif/du cours
Stop aux appels d'offres sur l'actif, retour au répertoire, recalculer les traductions afférentes, note publique.
16) Chèque de mise en œuvre
1. Décrivez les pools/limites/tampons et les CR minimales par domaine.
2. Inclure le DORS en tenant compte du coût total de la voie et des risques.
3. Ajustez la réalance (seuil + TWAP/VWAP) et le netting.
4. Identifier les SLI/SLO (SLA de paiement, CR, MTTR, CTS) et les dashboards.
5. Lancez le fonds d'assurance et les enchères MM pour les déficits.
6. Approuver la politique de conformité (KYC/KYB/AML/sanctions).
7. Effectuer des tests de choc et de stress (run, défaillance des ponts, spike de gaz).
8. Vérifiez régulièrement les commissions, les itinéraires et les limites.
17) Glossaire
LP (Liquidity Pool) est un pool de liquidités dans un domaine/une monnaie.
CR (Coverage Ratio) est le taux de couverture de la demande par le pool.
U (Utilisation) est la part des liquidités utilisées.
DORS (Smart Order Routing) est un routage intelligent de paiements/transferts.
TWAP/VWAP - Stratégie de débordement en douceur en temps/volume.
CTS per $ est le coût du service de traduction $.
Run-risk - risque de retrait massif de liquidités.
Netting - compensation des obligations réciproques avec des trampolines.
Résultat : la liquidité totale est un système gérable de règles, de pools et d'itinéraires où le capital fonctionne efficacement et les paiements sont effectués rapidement et de manière prévisible. En combinant topologie hybride, DORS, commissions dynamiques, SLO rigoureux et discipline de rééducation, l'écosystème obtient une liquidité réseau durable, évolutive et économiquement optimale.