> ## 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.

# Glossaire

> Définitions des termes de protocole, de consensus, de trading et de risque employés dans toute la documentation Intention.

Ce glossaire définit les termes qui reviennent le plus souvent dans la documentation Intention. Cliquez sur un terme pour déplier sa définition ; pour des explications plus longues et le raisonnement de conception, suivez les renvois vers les sections architecture et trading.

<AccordionGroup>
  <Accordion title="ADL — réduction automatique du levier">
    Le mécanisme natif au protocole par lequel des positions ouvertes sont clôturées de force pour absorber des pertes qui dépassent la capacité du fonds d’assurance. La sélection est calculée de façon déterministe à partir d’une combinaison du P\&L latent et du levier effectif. Voir [ADL](/fr/trading/adl).
  </Accordion>

  <Accordion title="Compensation et règlement atomiques">
    La propriété selon laquelle l'appariement, la compensation et le règlement s'achèvent comme une unité d'un bloc, ou pas du tout : il n'existe aucun intervalle où une exécution existe sans que sa marge, son enregistrement ou son règlement n'existent. L'atomicité couvre le registre propre au protocole ; faire entrer ou sortir du collatéral par le [bridge](/fr/protocol/architecture/bridge) dépend de la finalité d'une chaîne externe et se situe en dehors. Voir [l'infrastructure de marché que cela remplace](/fr/protocol/architecture/overview).
  </Accordion>

  <Accordion title="BFT — tolérance aux fautes byzantines">
    Un protocole de consensus qui reste sûr et vivant en présence de participants arbitrairement malveillants, sous réserve d’une borne sur la fraction du stake défaillant. IntentionBFT est BFT sous un seuil $2f+1$ pondéré par le stake.
  </Accordion>

  <Accordion title="Déterminisme au niveau de l’octet">
    La propriété selon laquelle deux nœuds honnêtes qui rejouent le même bloc finalisé contre le même état initial produisent un état final, des événements et des sorties par transaction identiques octet pour octet. Sa forme visible par l’utilisateur est le [rejeu déterministe](/fr/protocol/architecture/kernel). Garanti par une discipline de conteneurs triés, une arithmétique en virgule fixe et le Differential Test Harness.
  </Accordion>

  <Accordion title="Engagement de séquencement canonique">
    L’engagement cryptographique, pris par le proposeur du bloc et certifié par $2f+1$ validateurs, sur l’ordonnancement précis des transactions à l’intérieur d’un bloc. C’est le point d’ancrage, au niveau du consensus, du [rejeu déterministe](/fr/protocol/architecture/kernel) et de l’[attribution par transaction](/fr/protocol/architecture/state/model). Voir [IntentionBFT](/fr/protocol/architecture/intention-bft).
  </Accordion>

  <Accordion title="Marge croisée (Cross)">
    Un mode de marge dans lequel toutes les positions d’un compte partagent un même pool de collatéral. Les profits d’une position peuvent compenser les pertes d’une autre, mais une perte suffisamment grande sur n’importe quelle position peut liquider le compte entier. Voir [Modes de marge](/fr/trading/margin-modes).
  </Accordion>

  <Accordion title="Rejeu déterministe">
    La garantie native au protocole que deux nœuds honnêtes quelconques rejouant le même bloc finalisé produisent un état final, un flux d’événements et une sortie par transaction identiques octet pour octet. Voir [Rejeu déterministe](/fr/protocol/architecture/kernel).
  </Accordion>

  <Accordion title="Flux d’exécution">
    L’observable de niveau protocole exposé aux utilisateurs par Intention : un flux complet, déterministe à l’octet près et cryptographiquement vérifiable de l’exécution des blocs, exposé via une interface RPC en streaming. C’est la forme visible par l’utilisateur de l’[attribution par transaction](/fr/protocol/architecture/state/model).
  </Accordion>

  <Accordion title="Taux de financement">
    Le paiement périodique échangé entre les positions longues et courtes d’un marché perpétuel, destiné à maintenir le prix du contrat arrimé au prix au comptant du sous-jacent. Le financement est réglé par le protocole selon un calendrier fixe. Voir [Financement](/fr/trading/funding).
  </Accordion>

  <Accordion title="Prix intra-consensus">
    La garantie native au protocole que les prix utilisés dans les opérations sensibles au règlement sont signés par le même ensemble de $2f+1$ validateurs, dans le même tour BFT, que les transactions qui les consomment. Voir [Prix intra-consensus](/fr/protocol/architecture/oracle).
  </Accordion>

  <Accordion title="Prix de l’indice">
    L’observation canonique, faite par le bloc, du marché au comptant externe du sous-jacent d’un instrument, livrée par le quorum de prix intra-consensus. L’indice est l’entrée de la construction du prix de marquage ; ce n’est pas le prix auquel les transactions s’exécutent. Voir [Prix de l’indice](/fr/trading/index-price).
  </Accordion>

  <Accordion title="Intention Exchange">
    Le DEX phare de contrats perpétuels bâti sur la L1 Intention. Il exploite un carnet d’ordres central complet, de la marge isolée et croisée, des liquidations natives au protocole et des vaults de liquidité on-chain. Intention Exchange n’implémente ni son propre moteur d’appariement ni sa propre chaîne de traitement du risque — il hérite des deux du protocole en dessous, via [IntentionKernel](/fr/protocol/architecture/kernel) et [IntentionBFT](/fr/protocol/architecture/intention-bft). C’est la première application à utiliser les garanties du protocole en production ; d’autres usages financiers suivront sur le même substrat.
  </Accordion>

  <Accordion title="IntentionBFT">
    Le protocole de consensus d’Intention. Un protocole tolérant aux fautes byzantines, partiellement synchrone et pondéré par le stake, issu de la famille HotStuff, étendu par des engagements de séquencement canoniques, des quorums de prix intra-consensus, un découplage de la disponibilité des lots et une réputation des leaders pondérée par le stake. Voir [IntentionBFT](/fr/protocol/architecture/intention-bft).
  </Accordion>

  <Accordion title="IntentionKernel">
    Le noyau déterministe de transition d’état d’Intention — pas une machine virtuelle généraliste. Une couche d’exécution en monde clos dont le jeu d’instructions est l’ensemble énuméré de primitives financières typées (ordre, annulation, appariement, marquage, liquidation, financement, règlement, transfert). Voir [IntentionKernel](/fr/protocol/architecture/kernel).
  </Accordion>

  <Accordion title="Marge isolée (Isolated)">
    Un mode de marge dans lequel chaque position dispose de sa propre allocation de collatéral. Une perte sur la position ne peut pas dépasser le collatéral qui lui est alloué, ni vider les autres positions du même compte. Voir [Modes de marge](/fr/trading/margin-modes).
  </Accordion>

  <Accordion title="Liquidation">
    La clôture forcée d’une position dont la valeur nette du compte est tombée sous l’exigence de marge de maintenance. Intention liquide par étages — carnet d’ordres, vault de liquidation, fonds d’assurance, et enfin [ADL](/fr/trading/adl). Voir [Liquidations](/fr/trading/liquidations).
  </Accordion>

  <Accordion title="Prix de marquage">
    La référence de règlement lissée et résistante à la manipulation du protocole. Calculée à chaque bloc comme la médiane d’au plus cinq prix candidats dérivés de l’indice, du carnet on-chain et de composantes de moyenne mobile exponentielle. Pilote le P\&L latent et les liquidations. Voir [Prix de marquage](/fr/trading/mark-price).
  </Accordion>

  <Accordion title="Encours de positions ouvertes (OI)">
    Le notionnel total de toutes les positions ouvertes sur un marché, compté d’un seul côté. Chaque marché a un plafond d’encours ; voir [Limites de position](/fr/trading/oi-limits).
  </Accordion>

  <Accordion title="Attribution par transaction">
    La garantie native au protocole que chaque changement d’état et chaque événement produits pendant l’exécution d’un bloc sont cryptographiquement liés à la transaction utilisateur précise qui les a déclenchés, y compris sous appariement par lots. Voir [Attribution par transaction](/fr/protocol/architecture/state/model).
  </Accordion>

  <Accordion title="Risque natif au protocole">
    La garantie native au protocole que la liquidation, la comptabilité du fonds d’assurance, la réduction automatique du levier et le règlement du financement sont des machines à états du protocole exécutées atomiquement avec l’appariement, dans le même bloc et sous les mêmes prix. Voir [Risque natif au protocole](/fr/protocol/architecture/clearinghouse).
  </Accordion>

  <Accordion title="Reduce-only">
    Un modificateur d’ordre qui permet de réduire une position existante, jamais d’en ouvrir une nouvelle ni de l’augmenter. Sert à gérer une sortie sans risquer un retournement de position accidentel. Voir [Reduce-only](/fr/trading/reduce-only).
  </Accordion>

  <Accordion title="Prévention de l’auto-exécution">
    Une règle de niveau protocole qui empêche un ordre d’être apparié à un autre ordre du même compte, ce qui élimine les transactions fictives (*wash trading*) dès la couche d’appariement. Voir [Prévention de l’auto-exécution](/fr/trading/self-trade-prevention).
  </Accordion>

  <Accordion title="Pas de cotation">
    Le plus petit incrément de prix autorisé pour les ordres d’un marché donné. Chaque marché a aussi un pas de quantité, qui définit le plus petit incrément de quantité autorisé. Voir [Marchés](/fr/trading/markets) et [Précision](/fr/trading/precision).
  </Accordion>

  <Accordion title="TWAP">
    Time-Weighted Average Price — prix moyen pondéré par le temps. En tant que type d’ordre, une stratégie qui découpe un gros ordre en de nombreux ordres enfants répartis dans le temps, afin de réduire l’impact de marché. Voir [TWAP](/fr/trading/twap).
  </Accordion>

  <Accordion title="Vault">
    Un pool de capital géré par le protocole, qui apporte de la liquidité au carnet d’ordres et absorbe les liquidations. Voir [Vaults](/fr/trading/vaults).
  </Accordion>
</AccordionGroup>