RUNTIME ET PUBLICATION
Le runtime est le moteur à écrivain unique qui possède l'état de trading en direct — position, équité, accumulation de financement, fills, passes de liquidation. La publication est la discipline qui transforme cet état en direct en racines commitées sur lesquelles se règlent les contrats Base. Ensemble, ils sont la raison pour laquelle l'historique d'un trader, un rang de classement et un montant de paiement 90 / 10 ne peuvent pas être discrètement réécrits après coup : chaque transition d'état atterrit dans une seule séquence ordonnée, chaque racine est liée à la séquence ainsi qu'à la posture de configuration et d'oracle qui l'a produite, et chaque retrait se règle face à une racine que quiconque dispose d'un explorateur peut vérifier.
Le runtime valide le flux signé venant de la passerelle, applique les règles de risque et d'état de marché, met à jour les soldes et positions, fait avancer le financement (peer-to-peer avec une part admin de 1 % au-dessus de 1 000 $ par fenêtre de 8 h), et exécute les routines forcées — liquidation, ADL, le partage 50/50 du résidu keeper-et-assurance. Chaque transition d'état produit les références sur lesquelles la couche contractuelle se règlera plus tard. Le tableau ci-dessous est ce qui accompagne chaque commit ; une racine sans ces liaisons est rejetée par le vault.
| Élément publié | Ce qu'il lie |
|---|---|
| Racine d'état | Ancre l'état des comptes pour les preuves de règlement et de retrait sur Base |
| Identifiant et horodatage de racine | Place l'état dans un historique de publication explicite ; les deux sont monotones |
| Commitment de séquence | Lie l'ordonnancement des événements à l'état commité — pas de fills réordonnés |
| Hash de source d'oracle | Lie la posture de source de prix utilisée pendant l'avancée de l'état |
| Commitment de batch d'ordres | Lie le batch admis autour de cet état — pas d'ordres insérés ou retirés |
| Hash et version de configuration | Lient les règles de risque et de plateforme actives — barème de frais, palier de marge, liste de marchés |
#État d'échange à écrivain unique
Dexter exécute un seul chemin d'écriture. Les mises à jour de financement, les passes de liquidation, les routines de déséquilibre, les changements d'état de marché et la publication passent tous par un seul flux runtime ordonné — jamais par des écrivains concurrents. Sur une plateforme de dérivés, un mauvais séquencement coûte aussi cher qu'une mauvaise tarification : un tick de financement appliqué hors séquence peut falsifier l'équité, une liquidation en course avec un fill peut se régler face au mauvais mark. Le modèle à écrivain unique élimine ces deux classes de bug en faisant d'un seul runtime l'unique auteur de la séquence de transitions d'état que le reste du système lit.
Le même runtime qui met à jour les soldes prépare la matière que la publication ancrera ensuite. C'est pourquoi le contexte de règlement et l'état de trading ne peuvent pas diverger — ils proviennent du même processus, dans le même ordre, derrière le même commitment.
ordre IOC signé
-> contrôles d'admission et de risque
-> décision de prix et de fill
-> mises à jour ledger, position, frais et financement
-> écriture snapshot et modèle de lecture
-> precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment)
-> commitStateRootWithConfig(root, schemaVersion, configHash, configVersion)
-> le vault n'accepte la racine que tant que les garde-fous de publication restent satisfaits#La publication comme contexte de règlement
La publication existe pour que la couche contractuelle n'ait jamais à faire confiance à une affirmation vague d'opérateur sur l'état du runtime. Quand le runtime expédie une racine accompagnée des références de séquence, d'oracle, de batch et de configuration, le vault sur Base reçoit une description concrète de ce que la plateforme croyait au moment où l'état a avancé. Cette description est ce sur quoi reposent les retraits, contestations, preuves de fraude, réconciliations et revues a posteriori. Sans elle, le contrat ne saurait que qu'un processus off-chain a affirmé un solde ; avec elle, le contrat peut ancrer une vue runtime spécifique, la préserver dans l'historique et exiger que chaque action de règlement renvoie à quelque chose de concret.
La publication n'est pas traitée comme une action propre au runtime. Avant que le vault n'accepte une racine, le commitment du séquenceur, le hash de source d'oracle et le commitment de batch d'ordres doivent déjà être pré-commités via precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment). La racine est ensuite soumise via commitStateRootWithConfig(...), qui la lie à l'configHash et au configVersion actifs. Si la matière pré-commitée ne correspond pas à la racine, ou si le verrou de gouvernance côté contrat n'est pas satisfait, la publication est rejetée et la racine ne devient jamais contexte de règlement.
La posture de production est plus stricte qu'un simple commit de racine. Le verrou de gouvernance exige que l'ancre d'audit soit active, que setOrderCommitRequired(true) soit en vigueur, et que le chemin de publication maintienne au moins un rail de preuve durable — soit une exigence d'archive, soit une exigence d'attestor DA. Une racine qui existe en isolation n'est pas de niveau production ; elle doit rester liée à la chaîne d'audit qui explique comment l'état a été publié et à la même discipline d'admission qui a produit le flux d'ordres qui l'a généré. C'est ce qui rend sûr d'ancrer le runtime off-chain contre la garde on-chain.