PASSERELLE ET MODÈLE DE LECTURE
La passerelle est la frontière publique entre chaque client de trading et le runtime. Les ordres de challenge pendant la fenêtre d'évaluation à 49–299 $, les fills financés sous le partage 90 / 10, les lectures de classement, les demandes de retrait — tous passent par la même entrée et lisent depuis le même état persisté. Un bot de copy-trading, une app mobile retail et un client API institutionnel voient la même surface, c'est pourquoi des tiers peuvent construire des dashboards sur Dexter sans demander la permission et pourquoi les règles ne peuvent pas être discrètement assouplies pour un seul consommateur.
La passerelle sert des réponses stables depuis une sortie de runtime persistée, jamais depuis l'état en mémoire du runtime. C'est ce qui lui permet de mettre en cache, de versionner, de basculer en repli et de rester déterministe sous charge — chaque lecture passe par le même chemin de code que le runtime soit occupé, inactif ou en redémarrage. En production, c'est aussi la frontière d'entrée étroite pour le flux de trading signé : l'autorisation d'agent, les contrôles de timing, l'application de l'IOC et la soumission de l'order-commit se font tous ici avant qu'un seul octet n'atteigne la boucle de matching.
| Surface exposée par la passerelle | Source sous-jacente |
|---|---|
| Résumés de marché et carnets d'ordres | Snapshots de runtime, enregistrements de carnet d'ordres, état du mark et de l'index |
| Compte, fills, historique de financement | Résumés de comptes persistés, journaux de fills, enregistrements de règlement de financement |
| Publication et vivacité | Historique des racines, fenêtres de fraîcheur, métadonnées de commitment de séquence et de configuration |
| Signaux de posture de la plateforme | Snapshots de santé, sorties d'état de marché, santé des sources d'oracle |
| Entrée de trading signée | Politique de signataire POST /agent/authorize ; fenêtres createdAtTs / goodTilTs ; discipline IOC ; soumission requise d'order-commit |
#Ce que la passerelle possède réellement
La passerelle possède la présentation, la normalisation et la politique d'admission sur l'entrée signée. Elle ne possède pas le matching, la construction du mark, la garde ou la finalité du règlement — ceux-ci résident dans le runtime et les contrats Base. Sa tâche est d'exposer une interface stable sur un état déjà persisté et de garder la porte d'entrée du trading suffisamment étroite pour que les règles d'entrée soient explicites et inspectables.
La séparation entre les lectures de marché publiques, les vues de compte authentifiées et les routes de service restreintes est imposée par trois modèles de permissions différents, pas un. Un wallet qui peut lire ses propres positions ne peut pas lire les positions d'un autre wallet ; un consommateur non authentifié peut lire le carnet d'ordres mais ne peut pas lire l'historique des fills ; une route de service interne ne peut pas être invoquée depuis l'entrée publique du tout. La passerelle fait donc partie de la frontière de sécurité, pas seulement de la couche UI.
Les surfaces tierces — rails de copy-trading, clients mobiles, consommateurs d'API institutionnels — lisent les mêmes enregistrements sous le même modèle de permissions que l'app interne. Ce sont des consommateurs en aval d'une seule frontière, pas des couches de protocole parallèles. Il n'y a pas de palier « partenaire » avec un accès discret à des endpoints privés.
#Le rôle du modèle de lecture persisté
Le runtime écrit en continu des snapshots, fills, enregistrements de financement, résumés de marché, résumés de comptes et signaux de santé dans un magasin persisté. La passerelle lit depuis ce magasin, jamais depuis la mémoire de processus du runtime. Deux conséquences en découlent : chaque consommateur voit le même état au même point de séquence, et un redémarrage du runtime ne produit jamais une lecture périmée ou en split-brain.
flux utilisateur signé
-> POST /agent/authorize définit la politique de signataire
-> la passerelle vérifie createdAtTs / goodTilTs / IOC / politique de séquence
-> la passerelle soumet le commitment d'ordre requis
-> le runtime met à jour l'état d'échange
-> snapshots, fills, financement et santé sont persistés
-> la passerelle normalise ces enregistrements
-> chaque app et consommateur d'API lit une seule surface stableLes plateformes hybrides deviennent non révisables quand chaque écran est adossé à une source invisible différente. Le modèle de lecture est ce qui empêche cela chez Dexter. La passerelle explique la plateforme ; elle ne décide pas de la plateforme. Quiconque reproduit le PnL d'un trader, un rang de classement ou un solde d'assurance peut le faire depuis les mêmes enregistrements persistés que la passerelle sert.