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

# Dúvidas sobre liquidações

> Como funcionam as liquidações na Intention, como ler o evento que fechou a posição e quando contestar uma liquidação é mesmo um caso para o apoio.

Esta página é para os traders que querem perceber porque foi liquidada uma posição. A resposta curta e honesta é que a liquidação forçada é quase sempre o resultado mecânico das regras de margem de manutenção aplicadas ao preço de marcação, e a narrativa da «liquidação injusta» costuma dissolver-se assim que o trader examina os valores exatos que entraram na conta. Leia as secções abaixo antes de abrir um ticket.

<h2 id="what-triggers-a-liquidation">
  O que ativa uma liquidação
</h2>

Uma posição é liquidada quando o valor líquido da conta cai abaixo da margem de manutenção exigida para o tamanho atual, avaliada contra o preço de marcação atual. A página [Liquidações](/pt/trading/liquidations) descreve a condição exata. Vale a pena sublinhar duas coisas:

* A ativação usa o **preço de marcação**, não o preço da última transação. Ver [Preço de marcação](/pt/trading/mark-price). Isto importa porque um único pavio no livro de ordens pode parecer dramático no gráfico sem que a marcação se tenha movido o suficiente para violar a margem de alguém.
* A margem de manutenção depende do **escalão de tamanho** da posição. As posições maiores exigem mais margem, e a escada de escalões está documentada na página [Alavancagem](/pt/trading/leverage). Uma posição com colateral confortável a um dado tamanho pode ficar subcolateralizada depois de a reforçar, mesmo sem qualquer movimento de preço.

<h2 id="how-liquidation-runs">
  Como corre a liquidação
</h2>

A liquidação não é um bot a reagir depois do facto. É uma máquina de estados do protocolo que corre atomicamente com o matching, dentro do mesmo ciclo de produção de blocos. A página [Câmara de compensação](/pt/protocol/architecture/clearinghouse) descreve o mecanismo. A consequência para quem negoceia: não há uma «corrida» para o liquidar, e nenhum keeper externo recebe um prémio que o próprio protocolo poderia ter captado. Tudo acontece dentro do IntentionKernel, de forma determinista.

Quando é detetada uma violação de margem, o motor tenta fechar a posição contra o livro. Se o livro estiver demasiado fino para absorver o fecho a um preço aceitável, entra o fundo de seguro. Se a situação for suficientemente grave para esgotar o fundo de seguro, entra a desalavancagem automática — ver [ADL](/pt/trading/adl) — e as posições da contraparte são atribuídas a um preço definido.

<h2 id="reading-the-liquidation-event">
  Ler o evento de liquidação
</h2>

Cada liquidação emite um evento estruturado que contém, no mínimo:

* A **conta e a posição** que violaram a margem.
* O **preço de marcação** no momento da violação.
* O **escalão de margem** aplicado, que determina o requisito de manutenção.
* O **tamanho fechado** e o **preço de execução** do fecho, incluindo se passou pelo livro, pelo fundo de seguro ou pelo ADL.
* A **variação do fundo de seguro**, se existir.

Se acredita que uma liquidação foi incorreta, comece por estes cinco campos. Na grande maioria dos casos, o preço de marcação na altura indicada coincide com o que o oráculo agregado estava a reportar, e o requisito de margem para o tamanho da sua posição era exatamente o que a escada de escalões indica. Nesse ponto a liquidação não é um bug nem um caso para o apoio — é uma consequência dos parâmetros de risco que aceitou ao abrir a posição.

<h2 id="when-it-actually-is-a-support-issue">
  Quando é mesmo um caso para o apoio
</h2>

Há algumas situações que justificam um ticket:

* A interface mostra um preço de marcação diferente do que consta no evento. Pode indicar um atraso da interface e não um bug do motor, mas vale a pena confirmar.
* A liquidação disparou a um preço de marcação que o oráculo agregado não atingiu nesse bloco.
* O escalão de margem reportado não corresponde à escada de escalões publicada na documentação.
* A variação do fundo de seguro é inconsistente com o preço de execução do fecho.

Em qualquer destes casos, envie um email para `contact@intention.xyz` com o endereço da posição, a altura do bloco do evento, os campos do próprio evento e uma captura de ecrã que mostre a discrepância.

<h2 id="when-it-is-not-a-support-issue">
  Quando não é um caso para o apoio
</h2>

Se a sua posição foi liquidada porque a marcação se moveu e a sua margem de manutenção foi violada, a resposta não é «o apoio pode reverter isso». Nenhuma equipa de apoio, em lado nenhum, consegue reverter uma transição de estado on-chain já definitiva. O que a equipa pode fazer é explicar-lhe as contas e confirmar que o protocolo fez o que devia — que é, muitas vezes, a resposta incómoda.