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

# Question sur une liquidation

> Comment fonctionnent les liquidations sur Intention, comment lire l’événement qui a clôturé votre position, et quand une contestation relève vraiment de l’assistance.

Cette page s’adresse aux traders qui veulent comprendre pourquoi une position a été liquidée. La réponse courte et honnête, c’est que la liquidation est presque toujours la conséquence mécanique des règles de marge de maintenance appliquées au prix de marquage, et que le récit de la « liquidation injuste » se dissipe en général dès que le trader inspecte les entrées exactes. Lisez les sections ci-dessous avant d’ouvrir un ticket.

<h2 id="what-triggers-a-liquidation">
  Ce qui déclenche une liquidation
</h2>

Une position est liquidée quand la valeur nette du compte passe sous la marge de maintenance exigée pour sa taille courante, évaluée au prix de marquage courant. La page [Liquidations](/fr/trading/liquidations) décrit la condition précise. Deux points méritent d’être soulignés :

* Le déclenchement se fait sur le **prix de marquage**, pas sur le prix de la dernière transaction. Voir [Prix de marquage](/fr/trading/mark-price) pour la raison. Cela compte, parce qu’une mèche isolée dans le carnet peut paraître spectaculaire sur le graphique sans pour autant déplacer le prix de marquage au point d’entamer la marge de quiconque.
* La marge de maintenance dépend du **palier de taille** de la position. Les positions plus grosses exigent plus de marge, et l’échelle des paliers est documentée sur la page [Levier](/fr/trading/leverage). Une position correctement collatéralisée à une certaine taille peut devenir sous-collatéralisée après un renforcement, même sans mouvement de prix.

<h2 id="how-liquidation-runs">
  Comment se déroule une liquidation
</h2>

La liquidation n’est pas un bot qui réagit après coup. C’est une machine à états du protocole qui s’exécute atomiquement avec l’appariement, à l’intérieur de la même boucle de production de blocs. La page [Chambre de compensation](/fr/protocol/architecture/clearinghouse) décrit le mécanisme. La conséquence pour les utilisateurs : il n’y a pas de « course » pour vous liquider, et aucun keeper externe ne touche une prime que le protocole aurait pu capter lui-même. Tout se passe à l’intérieur d’IntentionKernel, de façon déterministe.

Quand un dépassement de marge est détecté, le moteur tente de clôturer la position contre le carnet. Si le carnet est trop peu fourni pour absorber la clôture à un prix acceptable, le fonds d’assurance intervient. Si la situation est assez grave pour que le fonds d’assurance soit épuisé, la réduction automatique du levier prend le relais — voir [ADL](/fr/trading/adl) — et des positions de contrepartie sont assignées à un prix défini.

<h2 id="reading-the-liquidation-event">
  Lire l’événement de liquidation
</h2>

Chaque liquidation émet un événement structuré qui contient au minimum :

* Le **compte et la position** qui ont franchi la marge.
* Le **prix de marquage** au moment du franchissement.
* Le **palier de marge** appliqué, qui détermine l’exigence de maintenance.
* La **taille clôturée** et le **prix d’exécution** de la clôture, en précisant si elle est passée par le carnet, par le fonds d’assurance ou par l’ADL.
* Le **delta du fonds d’assurance**, s’il y en a un.

Si vous pensez qu’une liquidation était incorrecte, la première chose à regarder, ce sont ces cinq champs. Dans la grande majorité des cas, le prix de marquage à la hauteur de bloc indiquée correspond à ce que l’oracle agrégé rapportait, et l’exigence de marge à la taille de votre position était exactement celle qu’annonce l’échelle des paliers. À ce stade, la liquidation n’est pas un bug et ne relève pas de l’assistance — c’est la conséquence des paramètres de risque que vous avez acceptés en ouvrant la position.

<h2 id="when-it-actually-is-a-support-issue">
  Quand cela relève vraiment de l’assistance
</h2>

Quelques situations justifient un ticket :

* L’interface affiche un prix de marquage différent de celui de l’événement. Cela peut indiquer un retard d’affichage plutôt qu’un défaut du moteur, mais cela vaut la peine d’être confirmé.
* La liquidation s’est déclenchée à un prix de marquage que l’oracle agrégé n’a pas atteint à ce bloc.
* Le palier de marge rapporté ne correspond pas à l’échelle publiée dans la documentation.
* Le delta du fonds d’assurance est incohérent avec le prix d’exécution de la clôture.

Dans l’un de ces cas, écrivez à `contact@intention.xyz` avec l’adresse de la position, la hauteur de bloc de l’événement, les champs de l’événement lui-même et une capture d’écran montrant l’écart.

<h2 id="when-it-is-not-a-support-issue">
  Quand cela ne relève pas de l’assistance
</h2>

Si votre position a été liquidée parce que le prix de marquage a bougé et que votre marge de maintenance a été franchie, la réponse n’est pas « l’assistance peut annuler ça ». Aucune équipe d’assistance, nulle part, ne peut annuler une transition d’état on-chain déjà entérinée. Ce qu’elle peut faire, c’est vous détailler le calcul et confirmer que le protocole a fait ce qu’il devait faire — ce qui, souvent, est la réponse inconfortable.