ADMISSION, SIGNATURES ET COMMITMENTS D'ORDRES

Six exigences conditionnent chaque ordre. Elles s'exécutent dans un ordre fixe et toute défaillance abandonne la requête avant que la couche de tarification ne la voie. Les trois premières sont des contrôles signataire-et-payload ; les trois dernières concernent le timing, le commitment et la politique de forme d'exécution.

#Flux signé autorisé

Un client ne peut pas signer un ordre et espérer que la plateforme l'accepte. Le compte enregistre d'abord une politique propre via POST /agent/authorize, qui consigne la clé signataire spécifique autorisée à agir en son nom. Cette séparation compte en pratique : la clé de retrait du compte, le lien KYC et le cash de parrainage n'ont jamais besoin de toucher une session de trading — un wallet matériel, une clé de session ou un client API prend en charge la surface de signature sans que le reste du wallet ne soit jamais exposé.

Une fois l'autorisation en place, chaque ordre arrive comme un payload typé EIP-712 plutôt que comme une instruction non signée. La structure signée porte le marché, le côté, la taille, le prix limite, la fenêtre de validité (createdAtTs, goodTilTs), et le seq monotone du compte. Le moteur rejette à la porte les signataires non autorisés, les seq manquants, les horodatages expirés ou en avance dans le futur et les payloads non IOC — aucune de ces défaillances n'atteint la couche de tarification ou de risque. En production, cela est imposé par GATEWAY_REQUIRE_IOC à la passerelle et par le validateur de payload du runtime, de sorte que la même règle est vérifiée deux fois sur des chemins de code indépendants.

#Séquencement et preuves de commit on-chain

Le séquencement monotone donne au runtime un ordre d'événements déterministe. Le seq de chaque compte avance strictement vers le haut, donc deux observateurs indépendants rejouant la même chaîne voient le même ordre de fills. Le runtime rejette tout payload dont le seq n'est pas strictement supérieur au seq précédemment accepté pour ce compte — un rejeu, un réordonnancement réseau ou une retentative dupliquée s'effondrent tous en un seul événement accepté.

Quand la garde de commit est active en production, la passerelle ancre le hash d'ordre sur le contrat OrderCommitRegistry sur Base via commitOrder (unitaire) ou commitOrders (batch) avant que le runtime ne soit autorisé à matcher. Cela réalise deux choses distinctes en une seule étape. Cela resserre l'admission : le runtime ne tarifiera pas un ordre dont le commit est manquant. Et cela produit un enregistrement public, horodaté et on-chain attestant que l'ordre existait dans la forme à laquelle le signataire a souscrit, avant qu'un fill n'ait pu être généré — c'est ce que vérifie la revue de contestation ultérieure.

 POST /agent/authorize
   -> la politique de signataire devient active pour le compte
   -> le client signe un payload IOC EIP-712 (marché, côté, taille, prix, createdAtTs, goodTilTs, seq)
   -> la passerelle applique GATEWAY_REQUIRE_IOC et valide la forme du payload
   -> commitOrder(orderHash) atterrit sur OrderCommitRegistry sur Base
   -> le runtime re-vérifie signataire, monotonie seq, horodatages et présence du commit
   -> seulement alors la tarification vAMM et la logique de fill s'exécutent

#Revoir la frontière d'admission

La pile d'admission n'est pas une cérémonie. Elle existe pour qu'un évaluateur technique puisse répondre à trois questions à partir de l'état public seul : quel signataire était autorisé à agir pour ce compte au moment de l'ordre, dans quel ordre les requêtes sont arrivées les unes par rapport aux autres, et si le runtime a matché un payload qui avait déjà été ancré on-chain. Si l'une de ces réponses est « on ne peut pas le dire », la plateforme opère en dehors de son propre contrat d'admission. Avec l'autorisation d'agent, le seq monotone et l'ancre OrderCommitRegistry, les trois réponses proviennent de données qu'un évaluateur peut récupérer sans avoir à faire confiance à la parole de la plateforme.

#Pourquoi cela compte pour le classement et les paiements

• L'historique de trades est ancré sur Base. Le hash de chaque ordre frappe l'OrderCommitRegistry via commitOrder avant que le runtime ne le matche. Une arrivée sur le podium ou un paiement financé 90 / 10 peut être reproduit depuis la chaîne — la plateforme ne peut pas réécrire l'historique sur lequel un paiement a été calculé, parce que l'horodatage de chaque commit est antérieur au fill qu'il justifie.
• Le seq monotone empêche le double comptage. Une retentative réseau, une course de relayer ou un bug client qui renvoie un payload s'effondrent tous en un seul événement accepté car le seq a déjà avancé. Le classement ne peut pas compter deux fois un fill, et un retrait de partage de bénéfices ne peut pas être contesté par une réclamation de fill dupliqué arrivant plus tard.
• L'autorisation d'agent isole la surface de trading. Le wallet qui détient les inscriptions au challenge, les paiements financés et les jetons DXTR n'a pas besoin de signer les trades. POST /agent/authorize lie un signataire séparé — wallet matériel, clé de session, client API — à la politique du compte. Si la clé de trading fuit, les retraits, le lien KYC et le cash de parrainage restent sur le wallet d'origine et hors de portée de l'attaquant.
• createdAtTs / goodTilTs bloquent les fenêtres de rejeu. Une signature n'est valide qu'à l'intérieur de sa fenêtre de validité déclarée. Un payload signé capturé il y a 10 minutes ne peut pas être rejoué aujourd'hui, même si la clé signataire est ensuite compromise — le runtime le rejette sur la garde d'horodatage avant tout autre contrôle.
• La même porte pour tout le monde. Un client de copy-trading, une intégration API institutionnelle et un wallet retail autorisent, signent, commitent et soumettent tous via la même frontière. Il n'y a pas de voie privilégiée qui permettrait à la plateforme d'admettre une classe d'ordres sous une règle différente.