> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # IntentionKernel > La couche d’exécution : un jeu d’instructions fermé d’opérations financières, exécuté comme une séquence fixe d’étapes sur un bloc entériné par le consensus. IntentionKernel est l’endroit où un bloc entériné se transforme en état de trading. Ce n’est pas une machine virtuelle généraliste qui exécute des programmes arbitraires — son jeu d’instructions est l’ensemble énuméré des opérations financières dont a besoin une plateforme de dérivés, et chacune d’elles a un effet défini que le protocole comprend. Cette distinction est la raison pour laquelle le réseau peut affirmer quoi que ce soit sur le trading. Une chaîne généraliste peut vous dire qu’une transaction a été signée et n’a pas échoué. Elle ne peut pas vous dire que cette transaction était l’annulation d’un ordre précis à une place précise dans le carnet, parce que le sens de l’appel lui est opaque. Ici, le sens est l’instruction.

Exécution en monde clos

Fermer le jeu d'instructions n'est qu'une occurrence d'un geste que le noyau répète quatre fois. À chaque fois, l'espace de ce qui peut arriver est énuméré à l'avance, et ce qui tombe en dehors est refusé plutôt que traité.
Opérations
Une charge utile qui n'appartient pas à l'ensemble énuméré — rejetée à la validation, pas à l'exécution
Ce qui a réellement été demandé
Vérité
Traiter le jeu de travail du bloc comme faisant autorité. C'est un journal ; la source est l'état du moteur
Ce qui est vrai en ce moment
Entrées
Tout ce qui peut différer d'une machine à l'autre : horloge, entropie, virgule flottante, ordre de hachage
Si un autre nœud obtient les mêmes octets
Causalité
Un changement d'état sans propriétaire. Les effets qui n'appartiennent à aucune transaction passent par un canal système, pas par une dérogation
Pourquoi ce changement précis a eu lieu
Fermé
Refusé
Le registre peut donc répondre
Quatre clôtures, un seul geste : énumérer l'espace à l'avance et refuser ce qui tombe en dehors.
Ce ne sont pas quatre vertus indépendantes. Chacune porte la suivante : fermer les opérations rend le *sens* d'une instruction récupérable ; un état unique et faisant autorité donne un sens au mot « résultat » ; fermer les entrées rend ce résultat reproductible ailleurs que sur cette machine ; et fermer la causalité permet de remonter d'un résultat à la demande qui l'a produit. Retirez-en une et la chaîne de responsabilité casse à ce maillon. Ce que les quatre achètent ensemble mérite un nom, car les places traditionnelles achètent la même chose bien plus cher. La piste d'audit d'une bourse est assemblée **à côté** du système de négociation puis déclarée en aval — c'est pourquoi elle peut diverger du système, pourquoi le rapprochement est un métier permanent, et pourquoi la synchronisation des horloges entre places relève de la réglementation et non du détail d'implémentation. Ici il n'y a pas de second registre à rapprocher. La piste d'audit est l'exécution. Le reste de cette page détaille ces quatre clôtures.

Le jeu d’instructions

Tout ce qu’un participant ou un validateur peut faire relève d’un ensemble fixe d’opérations typées : | Groupe | Opérations | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Ordres** | Placer, annuler, remplacer et modifier — sous les formes limitée, au marché et conditionnelle, avec durée de validité, reduce-only et structures take-profit / stop-loss liées | | **Configuration du compte** | Création de sous-compte, choix du levier, mode de marge, mode de position | | **Transferts** | Entre sous-comptes, entre comptes, et entrées et sorties via le [bridge](/fr/protocol/architecture/bridge) | | **Autorisation d’agent** | Autoriser et révoquer un agent qui trade au nom d’un compte | | **Opérations de vault** | Création, dépôts, retraits, configuration | | **Configuration système** | Cotation de marché, configuration des frais, paliers de levier, paramètres de risque — autorisés par la gouvernance | | **Émises par les validateurs** | Mises à jour de prix certifiés et reconfiguration | Une transaction dont la charge utile n’appartient pas à cet ensemble est rejetée à la validation. L’ensemble ne change que par mise à niveau du protocole, jamais par le déploiement de quelque chose de nouveau.

Exécuter un bloc

L’exécution est une séquence fixe d’étapes. Cet enchaînement n’est pas un détail d’implémentation — c’est lui qui détermine si une liquidation voit le prix qui l’a déclenchée, et si une annulation devance un ordre agressif entrant.
Prixfixer les marquages du bloc
Chargementingérer les comptes et ordres du bloc
Financementrégler les flux
Risquelevier vaults → liquidation → ADL
Appariementpré → appariement → post
Finalisationcollecter sorties, purger état mort
Chaque étape en aval raisonne sur un prix par instrument, non sur un prix mouvant
Réglé sur les positions telles que chargées, pas en fin de bloc
Le flux forcé est résolu avant l’admission de tout flux discrétionnaire
S’exécuter après Risque est ce qui empêche de devancer une liquidation dans le même bloc
Positions à zéro et comptes vidés ne persistent pas
Un bloc, six étapes
Ce que la place détermine
Les ordres conditionnels sont balayés dans cette séquence : un déclenchement provoqué par les marquages de ce bloc prend effet dans ce bloc, pas dans le suivant.
**Prix** s’exécute en premier et fixe les prix de marquage que le reste du bloc utilisera, de sorte que chaque étape en aval raisonne sur un prix par instrument plutôt que sur un prix mouvant. **Chargement** ingère les comptes et les ordres du bloc. **Financement** règle le financement contre les positions telles que chargées. **Risque** exécute trois phases successivement — réduction du levier des vaults, puis liquidation, puis réduction automatique du levier (ADL) — pour que le flux forcé soit résolu avant l’admission de tout nouveau flux discrétionnaire. **Appariement** exécute ensuite ses propres trois phases et produit des exécutions. **Finalisation** collecte ce qui a changé et purge l’état qui n’a plus lieu d’être, comme les positions ramenées à zéro et les comptes vidés. Les ordres conditionnels sont balayés et font avancer leur cycle de vie à l’intérieur de cette séquence, de sorte qu’un déclenchement provoqué par les prix de marquage de ce bloc prend effet dans ce bloc plutôt que dans le suivant. C’est parce que la liquidation s’exécute avant l’appariement qu’une liquidation ne peut pas être devancée par un ordre du même bloc. Le flux de liquidation est déjà résolu au moment où les ordres discrétionnaires sont appariés.

Deux sortes d’état

Le noyau maintient une séparation stricte entre ce qui persiste et ce qui est éphémère.
pendant l’exécution d’un bloc
État du moteurmarchés · comptes · carnets · positions · chambre de compensationvit entre les blocs
Ensemble de travailmarquages · comptes touchés · exécutions · sortievit le temps d’un bloc
État de la chaîne entérinéversionné · authentifiél’autorité
On confond facilement suivi des modifications et autorité. Ce qui change pendant un bloc construit la sortie déterministe — ce n’est pas là que vit l’état.
l’autorité qui reconstruit le moteur
lecture
application
matérialisation
**L’état du moteur** vit d’un bloc à l’autre : métadonnées de marché, comptes, carnets d’ordres, état des instruments, état de la chambre de compensation. C’est la réponse à « qu’est-ce qui est vrai en ce moment ». **L’ensemble de travail du bloc** n’existe que pendant l’exécution d’un bloc : les entrées du bloc, les prix de marquage fixés au départ, les comptes et les ordres touchés, et les sorties en cours d’assemblage. C’est un journal, pas une source de vérité. La distinction compte parce qu’il est facile de prendre le suivi des modifications pour l’autorité. Ce qui a changé pendant un bloc sert à construire une sortie déterministe — ce n’est pas là que vit l’état. Prendre cela à l’envers produit un système où la réponse dépend de la façon dont on a posé la question.

Pourquoi le résultat est reproductible

Le déterminisme est ici imposé, non espéré. Tout nœud honnête qui exécute le même bloc contre le même état antérieur produit le même résultat, octet pour octet, parce que rien sur le chemin d’exécution ne peut lire quoi que ce soit qui diffère d’un nœud à l’autre : * **Arithmétique en virgule fixe partout.** Les calculs de règlement se font en virgule fixe entière avec une sémantique d’arrondi explicite — arrondi vers le haut sur les exposants négatifs pour la marge, plancher et plafond pour les frais. Il n’y a pas de virgule flottante sur le chemin de règlement, parce qu’une différence d’arrondi entre deux machines est un fork. * **Aucune horloge murale.** Le séquencement à l’intérieur d’un bloc utilise la position canonique entérinée par le consensus et l’horodatage du bloc, jamais l’heure locale. * **Aucun aléa à l’exécution.** Tout ce qui exige de l’aléa le dérive de façon déterministe de l’état de la chaîne. * **Itération déterministe.** Toute collection dont l’ordre de parcours est observable dans la sortie est triée, et non randomisée par hachage. Une conséquence mérite d’être nommée : comme le « temps » à l’intérieur d’un bloc est la position intra-bloc entérinée, aucun avantage de colocation sous la milliseconde n’existe *à l’intérieur* d’un bloc. Combiné à l’ordonnancement des priorités — qui exécute les annulations avant les placements agressifs —, c’est une défense structurelle contre le fait de se faire prendre une cotation en carnet par un ordre arrivé dans le même bloc.

Les formules de risque sont pures

Les formules qui décident des exigences de marge, des prix de liquidation, de la sélection pour la réduction du levier, des frais et des limites d’encours sont implémentées comme des **fonctions pures et sans état**. Elles prennent des valeurs et renvoient des valeurs ; elles ne lisent ni ne modifient l’état du registre. Les changements d’état sont pilotés exclusivement par la [chambre de compensation](/fr/protocol/architecture/clearinghouse), qui appelle ces fonctions et applique les résultats. Les modules qui détiennent de l’état — comptes, positions, carnets d’ordres — stockent les données et exposent des mutateurs, mais ne pilotent pas eux-mêmes la logique métier. C’est une frontière délibérée. Elle fait qu’un calcul de marge peut être vérifié isolément contre une table d’entrées et de sorties, et qu’il existe exactement un chemin de code par lequel le solde de qui que ce soit peut changer.

La sortie

L’exécution produit des écritures d’état et des événements, chacun lié à la transaction qui l’a causé, plus un canal pour les effets de niveau système qui n’appartiennent à aucune transaction utilisateur en particulier — financement, mouvements du fonds d’assurance, compteurs de bloc. Ceux-ci deviennent les sorties de transaction que la [couche d’état](/fr/protocol/architecture/state/model) entérine et que l’[indexeur](/fr/protocol/architecture/indexer) sert. Rien de ce qui se passe à l’intérieur du noyau n’est invisible en aval. Si cela a changé l’état, cela se trouve dans la sortie de quelqu’un ou dans le canal système.

Pour aller plus loin

Le carnet d’ordres, la priorité prix-temps, et la résolution de la durée de validité et de la prévention de l’auto-exécution. L’unique chemin par lequel changent les soldes, les positions et la marge. Ce que devient la sortie du noyau une fois entérinée. D’où viennent le séquencement et les prix.