ARCHITECTURE
Dexter est un seul produit pour le trader — connecter un wallet, acheter un pack de 49 à 299 $, trader, être payé — et cinq couches en dessous. Chaque couche possède exactement une tâche et détient exactement l'autorité que cette tâche requiert. Un oracle dégradé ne peut pas mettre en pause un retrait. Un wallet d'exploitation bloqué ne peut pas figer le collatéral. Le moteur de challenge ne peut pas réécrire un fill du moteur de matching. Le règlement s'effectue sur Base, la garde réside dans des contrats dédiés, et chaque paiement remonte à une racine d'état publiée que n'importe qui peut vérifier dans un explorateur.
L'interface paraît unique, mais l'exécution, la publication et la garde restent clairement séparées.
Une seule plateforme visible.
La politique avant l'exécution.
Prix, matching, risque, financement, publication.
L'état est expédié avec son contexte.
Le collatéral reste borné.
Lisez le tableau comme une carte de permissions. La première colonne de chaque couche est ce qu'elle est autorisée à faire ; la troisième colonne est ce qu'elle ne peut pas faire, par construction. Rien dans le tableau ne déplace les fonds de l'utilisateur sans un appel de contrat correspondant sur Base.
| Couche | Tâche principale | Ce qu'elle ne peut pas faire |
|---|---|---|
| Surface produit | Afficher les marchés, graphiques, saisie d'ordres, positions, actifs et vues de compte | Pas de matching, pas de garde, pas de règlement |
| Passerelle et modèle de lecture | Normaliser la sortie persistée du runtime en une API stable ; conditionner l'entrée signée avec authentification d'agent, IOC et politique d'order-commit | Pas de décision de fill, pas d'autorité sur les soldes |
| Moteur runtime | Flux à écrivain unique : valider les ordres signés, appliquer le risque, fixer le prix, fill, faire avancer le financement, préparer la publication | Pas de garde directe, pas de retraits unilatéraux, pas de changement de paramètres |
| Publication | Commit des racines d'état avec liaisons de séquence, oracle, batch et configuration que le vault règle | Pas de boucle de matching, pas d'écriture de soldes |
| Contrats sur Base | Détenir le collatéral, mettre en file les retraits, conserver l'historique des racines, imposer le multi-sig sur les actions de trésorerie | Pas de matching d'ordres en direct, pas d'autorité off-chain |
#Une plateforme, des couches d'opération séparées
Un trader voit une plateforme. L'implémentation divise cette plateforme sur cinq couches parce que forcer une exécution rapide, un état produit lisible et des permissions critiques de garde dans un seul composant est la manière dont les plateformes de dérivés perdent les fonds des utilisateurs. La surface produit possède la clarté. La passerelle possède la normalisation et la politique d'admission sur le flux signé. Le runtime possède l'état d'échange en direct sous un modèle d'écrivain unique. La publication possède les liaisons entre l'état off-chain et le règlement on-chain. Les contrats sur Base possèdent la garde et les portes multi-sig sur le mouvement de trésorerie.
Les surfaces tierces — dashboards, rails de copy-trading, clients mobiles, consommateurs d'API institutionnels — lisent depuis la même passerelle que l'app interne. Elles ne constituent pas une nouvelle couche de protocole ; elles consomment le même état persisté. C'est la raison structurelle pour laquelle un bot de copy-trading, une interface mobile retail et un desk quant voient des fills cohérents.
Dexter est livré en mode vAMM sans liquidité. La plateforme en direct ne dépend pas d'un inventaire maker au repos ; la pression d'exécution, le skew, le spread et la posture d'inventaire sont gérés à l'intérieur du runtime face à la courbe vAMM. Les droits de garde et de retrait restent liés aux contrats quelle que soit la posture prise par le runtime. Un mauvais appel d'inventaire ne peut pas coûter sa marge à un trader.
surface produit
-> passerelle et modèle de lecture
-> runtime off-chain
-> commitments publiés
-> contrats de vault, trésorerie et règlement sur Base#Où se situe réellement la frontière de confiance
Dexter ne prétend pas que chaque composant est on-chain. Il prétend quelque chose de plus étroit et de plus utile : l'exécution peut être rapide off-chain tant que la garde, les références de règlement et la valeur détenue par le protocole résident on-chain avec des règles explicites. Le collatéral utilisateur, les demandes de retrait, l'historique de nonces, les soldes de frais, la réserve d'assurance et la comptabilité côté revenus résident tous dans un stockage gouverné par contrat sur Base parce que ce sont les endroits où la propriété doit rester sans ambiguïté.
Le runtime fait avancer l'état et publie le contexte de règlement que lit le vault. Il ne redéfinit pas la garde après coup, et il n'autorise pas un retrait que les contrats n'honoreraient pas par eux-mêmes. Les mouvements de trésorerie supérieurs à 10 000 $ exigent un multi-sig 2-sur-3 ; les mouvements d'assurance et de gouvernance exigent un 3-sur-5 avec un signataire externe. Le runtime ne peut contourner aucune de ces portes. C'est ce qui fait du partage off-chain / on-chain une véritable frontière architecturale au lieu d'un langage marketing posé sur un backend en boîte noire.