SURVEILLANCE ET RÉCUPÉRATION
Quand un oracle tombe, qu'une racine de règlement traîne, qu'une file s'engorge, ou qu'un événement de stress élargit les spreads, la seule question qui compte pour un trader financé est de savoir si le cashier fonctionne encore. Cette page liste les quatre pistes de surveillance qui surveillent chaque pipeline de paiement, la posture de récupération pour chaque classe de défaillance, l'autorité de pause gardien qui peut halter les dépôts ou les retraits en une seule transaction, et le SLA publié pour restaurer le service. Les cibles sont concrètes : une fenêtre de paiement de 24 heures après validation d'un KYC de type Sumsub, détection sous la minute sur chaque signal de flux et de file, et une réconciliation post-incident entièrement visible postée sur le canal opérations.
Quatre pistes de surveillance tournent en continu. Chacune a un seuil de détection défini, une règle de routage de garde, et une posture de réponse documentée — un état dégradé de la plateforme devient toujours visible avant qu'il n'atteigne les pipelines de retrait.
| Signal opérationnel | Cible de détection | Posture de réponse |
|---|---|---|
| Fraîcheur des flux et posture du marché | Péremption oracle au-dessus du budget de fraîcheur par source ; divergence inter-sources au-dessus de la tolérance ; dérive du mark par rapport aux échanges de référence | Les marchés affectés passent en mode contraint (levier max réduit, bandes élargies, pas de nouvelles ouvertures) en un bloc |
| Publication et liveness des racines | Temps depuis le dernier commitSettlement, profondeur de file des retraits en attente, et lag de publication du runtime | Page-out opérations au seuil ; pause gardien armée si le lag dépasse disputeWindowSec sans récupération de publication |
| Santé de la passerelle et de l'auth | Taux d'erreur d'auth par palier, tentatives de fuite de permission inter-paliers, tentatives de replay d'ordre signé, saturation des rate-limits | Disjoncteur de niveau surface par palier ; les défaillances de palier d'admission ne cascadent jamais vers les surfaces opérateur ou multi-sig |
| État de trésorerie et de réconciliation | Dérive de solde wallet d'exploitation vs deep-cold-vault, variance comptable du balayage de frais, ratio d'exposition de la réserve d'assurance | Rapport de réconciliation quotidien au multi-sig opérations ; toute dérive non réconciliée au-dessus de 1 000 $ bloque le prochain balayage de frais jusqu'à résolution |
#Ce que la plateforme surveille en continu
Chaque signal alimente le même pager de garde — une rotation unique à travers l'équipe fondatrice et le lead d'ingénierie. Il n'y a pas d'heure de silence. Les alarmes oracle et flux routent directement vers la garde trading-services ; les alarmes de racine et de publication routent vers la garde runtime avec le lead opérations en CC ; les anomalies de passerelle et d'auth routent vers la garde plateforme ; la dérive de trésorerie et de réconciliation route vers les signataires multi-sig opérations, parce que tout ce qui finit en transaction Base a besoin du signataire qu'on demandera de co-signer la remédiation.
Chaque signal alimente aussi la surface publique de la plateforme. Les marchés contraints affichent leur état sur chaque ticket d'ordre et dans l'en-tête du carnet, avec la raison (péremption oracle, divergence de source, dérive du mark) étiquetée. Les retraits en attente affichent la condition de porte (racine pas encore commit, disputeWindowSec en cours, revue manuelle, KYC en attente) pour qu'un trader financé puisse lire pourquoi son cashier est en pause sans contacter le support. Une plateforme dégradée qui se présente encore comme normale est traitée comme une défaillance pire que la dégradation sous-jacente.
Les mises à jour suivent la même discipline. Les changements de runtime et de contrat passent par des suites de régression et de smoke avant le déploiement ; les mises à niveau de contrat passent par une fenêtre de revue de sécurité supplémentaire avec le multi-sig gouvernance 3-sur-5 et un délai de visibilité de proposition de 24 heures. La dérive opérationnelle — un tuning de file, un changement de poids de source de flux, une rotation de permission — est journalisée dans le canal ops avec le signataire responsable et le chemin de rollback. Le protocole n'est pas sécurisé par le code seul ; il est sécurisé par la discipline avec laquelle le code est changé, publié et surveillé en production.
le signal devient malsain
-> la posture du marché se resserre ou le disjoncteur de passerelle trip
-> les surfaces affectées étiquettent leur état pour les utilisateurs
-> garde appelée, ensemble de signataires notifié pour les événements classe trésorerie
-> pause gardien armée si la dégradation franchit le seuil de sécurité
-> la récupération attend données fraîches + publication saine + trésorerie réconciliée
-> seul le multi-sig gouvernance 3-sur-5 peut remettre en marche un halt gardien#Comment la récupération est censée fonctionner
La récupération est échelonnée, pas basculée. Avant qu'une surface protégée ne retourne à pleine autorité, quatre conditions doivent tenir simultanément : la fraîcheur oracle a été continuellement dans le budget pendant au moins la fenêtre de soak post-récupération, le runtime a commit une racine de règlement que le contrat accepte comme étant dans l'historique, la santé des paliers de la passerelle est verte à travers les surfaces publique, authentifiée, d'ordre signé et opérateur, et la réconciliation wallet-d'exploitation vers deep-cold-vault correspond sans dérive non résolue. Toute condition unique manquante garde la surface affectée en mode contraint.
Pour les traders financés, le SLA publié est la borne qui compte. Les retraits jusqu'à 5 000 $ hors du top trois du podium du classement visent une libération dans les 24 heures suivant la validation d'un KYC de type Sumsub, et dans les quatre heures suivant la levée de la condition de porte pour les utilisateurs déjà passés par la revue de premier paiement. Les retraits au-dessus de 5 000 $ ou dans le top trois du podium visent la même fenêtre de 24 heures à partir du moment où le multi-sig opérations 2-sur-3 ouvre le ticket de revue — la queue plus longue est le temps de revue, pas le temps de signature. Après tout incident qui met en pause les retraits, la remise en marche est accompagnée d'une réconciliation publiée montrant la cause, l'état du solde impacté et la remédiation par compte. Aucun paiement qui était dû avant l'incident n'est réduit à cause de lui ; les réserves d'assurance compensent tout manque produit par la récupération.
C'est le standard auquel Dexter opère. Détection en secondes, changements de posture en un bloc, transparence sur chaque surface dégradée, récupération uniquement après que les conditions indépendantes reconvergent, et une cible cashier de 24 heures que le multi-sig honorera ou dont il publiera la raison de ne pas l'avoir pu.