SOURCES ET REPLI
Chaque fill, chaque contrôle de drawdown, chaque rang du classement et chaque paiement USDC remonte à un prix que Dexter a accepté à un timestamp spécifique. Un seul éditeur qui s'éteint ne peut pas être le même événement qu'un marché qui gèle ou un paiement refusé — la couche source est conçue pour que la défaillance du principal bascule sur un chemin redondant pré-validé dans le même tick, et ne fasse basculer le marché en réduit ou clôture-seule que quand aucun chemin ne passe les portes de déviation, fraîcheur et profondeur. Ci-dessous, l'échelle complète des sources, comment le mux promeut un chemin actif, les conditions exactes qui font basculer un marché en posture dégradée, et ce qui arrive à vos positions ouvertes et à votre horloge de challenge de 30 jours quand cela se produit.
L'opération normale sur chaque marché Dexter exige deux chemins sains en même temps : un flux push principal Hermes/Pyth et un mux oracle HTTP indépendant que le runtime sonde et contre-vérifie face au principal à chaque tick. L'opération à source unique n'est pas un état stable — c'est une surcharge de liveness explicite engagée uniquement quand le runtime a journalisé la défaillance, enregistré l'exception de politique, et rétrogradé le marché en posture dégradée pour la durée. L'échelle ci-dessous est donc un plan de basculement ordonné, pas un buffet dans lequel le mux pioche.
| Chemin de source | Rôle dans la plateforme |
|---|---|
| Hermes / Pyth (principal) | Ancre de référence push à faible latence pour chaque marché supporté ; agrège l'ensemble d'éditeurs que Pyth vérifie on-chain |
| Mux oracle HTTP (contre-vérification) | Chemin pull indépendant qui doit s'accorder avec Hermes dans la bande de déviation à chaque tick avant que le mark ne soit promu |
| Surcharge de liveness à chemin unique | Engagée uniquement quand une famille est en panne et que le runtime accepte un quorum réduit ; le marché bascule simultanément en réduit ou clôture-seule |
| Maintien contrôlé du dernier connu | Si aucun chemin n'est acceptable, le moteur tient le dernier mark validé, arrête la nouvelle exécution et émet un événement de dégradation pour les opérations et l'état publié |
#Comment une source devient active
L'existence d'un chemin de repli n'est pas la même chose que sa confiance. Le mux de source prend une décision par tick par marché : quelle combinaison de chemins disponibles passe la fenêtre de fraîcheur, s'accorde dans les bornes de déviation, passe le plafond de lag par marché et respecte la garde de profondeur/spread. Cette décision est une politique, pas une heuristique — les mêmes entrées produisent toujours le même résultat, et l'ensemble de sources choisi est enregistré dans le log du runtime et stampé dans la prochaine racine de règlement.
Le conservatisme est l'option par défaut explicite. Quand le principal s'affaiblit, le mux essaie d'abord de maintenir les deux chemins en direct en élargissant la tolérance de latence dans le plafond configuré. Si la contre-vérification échoue toujours à la bande de déviation, le runtime préfère rétrograder le marché — en réduit, puis clôture-seule, puis halt — plutôt que promouvoir un ensemble de sources appauvri en posture normale. La commodité et de jolis chiffres d'uptime ne sont pas des raisons valables pour continuer à trader sur un chemin que le reste de la politique ne soutient pas.
Quand un repli est engagé, deux choses se produisent simultanément. D'abord, le moteur de matching continue de filler les ordres reduce-only contre le chemin survivant pour que les utilisateurs puissent gérer le risque ouvert. Ensuite, l'état du marché est publié comme dégradé pour que chaque client connecté, le moteur de règles et le cashier voient la même posture. Un reviewer lisant le log du runtime plus tard peut répondre à une question sans ambiguïté : à chaque tick, quel chemin était actif, pourquoi, et sous quelle posture le marché a-t-il tradé ?
le tick T arrive
-> le mux lit Hermes principal + contre-vérification HTTP
-> portes de fraîcheur, déviation, lag, profondeur évaluées
-> si les deux passent : mark promu, marché reste live
-> si l'un échoue : le mux retente dans le plafond de latence
-> si toujours en échec : la posture du marché rétrograde
réduit -> clôture-seule -> halt
-> ensemble de sources sélectionné et hash de posture
commit dans la prochaine racine d'état#Pourquoi la sélection de source compte pour le règlement
L'ensemble de sources actif n'est pas une note de bas de page opérationnelle — il fait partie du registre de règlement on-chain. Le runtime hash les métadonnées de posture de source (éditeurs actifs, engagement du repli, déviation observée, marge de fraîcheur, posture du marché) et commit ce hash dans chaque racine d'état que le contrat du vault accepte. Un retrait finalisé contre la racine R est donc lié à la configuration oracle exacte qui a produit les soldes à l'intérieur de R.
C'est la différence entre « la plateforme dit qu'elle a utilisé Hermes » et « le contrat peut prouver de quelle posture de flux dépendait chaque paiement ». C'est aussi ce qui rend la couche de prix auditable au même titre que le ledger des soldes : un reviewer post-incident lisant les racines d'état sur Base peut répondre non seulement à combien valait un compte à la racine R, mais aussi à quels chemins de source étaient live, lesquels étaient dégradés, et sous quelle posture le moteur de matching tournait quand cet instantané a été scellé. Les détails de construction du mark continuent sur Construction du mark ; les transitions de session et d'état dégradé sont documentées sur Sessions et états dégradés.