> ## 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.
# Matching
> O livro de ordens, como é representada a prioridade preço-tempo e como a validade da ordem e a prevenção de autonegociação se resolvem sobre ele.
O matching é uma fase dentro da [execução do kernel](/pt/protocol/architecture/kernel), não um serviço com que a cadeia fala. Recebe as ordens do bloco na sua sequência confirmada, percorre-as contra o livro e produz execuções. Não mexe no saldo de ninguém — isso é trabalho da [câmara de compensação](/pt/protocol/architecture/clearinghouse) e acontece depois de o matching terminar.
Manter os dois separados é o que torna o motor testável. O matching responde a *o que negociou contra o quê*. A câmara de compensação responde a *quanto isso custa e quem passa a dever a quem*.
O livro
Cada instrumento tem o seu próprio livro, mantido em memória como três estruturas que cooperam entre si:
Slab arena — uma região pré-alocada de slots de ordens
Níveis de preçomapa ordenado, preço → nívelo topo do livro alcança-se indo ao extremo, sem varrer
Índice de ordensid da ordem → slotcancelar e alterar: tempo constante
ordem
ordem
ordem
ordem
ordem
Cadeia duplamente ligada pela sequência de chegada: a prioridade dentro de um nível é posicional, não calculada.
A ordem de reutilização é fixaOs slots libertados são reutilizados por ordem fixa e o índice tem semente fixa. Não é escolha de desempenho: dois validadores a reutilizar slots por ordens diferentes divergiriam.
topo de cada nível
consulta direta
| Estrutura | Papel |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Níveis de preço** | Um mapa ordenado de preço para nível, para que o melhor preço de compra e o melhor preço de venda sejam encontrados indo ao extremo em vez de varrer tudo |
| **Cadeia de ordens** | Uma lista duplamente ligada que encadeia as ordens pela sequência de chegada, para que a prioridade dentro de um nível seja posicional em vez de calculada |
| **Índice de ordens** | Um mapa direto do ID da ordem para o seu slot, para que cancelar e alterar sejam operações de tempo constante em vez de uma pesquisa |
As ordens vivem numa **slab arena** — uma região pré-alocada com alocação e libertação em tempo constante. As operações sobre o livro de ordens não alocam, portanto, no caminho crítico, e os slots libertados são reutilizados segundo uma ordem fixa e não onde calhar ao alocador. Este último detalhe não é uma escolha de desempenho: se dois validadores reutilizassem slots segundo ordens diferentes, tudo o que observasse a disposição dos slots divergiria.
A mesma disciplina aplica-se ao índice de ordens, cuja semente é fixa e não aleatória. Um hash map com semente por processo é uma defesa habitual contra ataques de colisão; num caminho de execução por consenso é um fork.
Os preços são inteiros em todo o lado — unidades subtick, não decimais. Ver [Precisão](/pt/trading/precision) para saber como isso se relaciona com o que submete.
Prioridade
A prioridade é primeiro o preço, depois a posição na cadeia a esse preço. O «tempo» é a posição canónica da ordem na sequência confirmada do bloco, não o momento em que chegou a um nó.
É isto que elimina a corrida à latência dentro de um bloco. Duas ordens no mesmo bloco têm uma precedência definida que todos os validadores calculam de forma idêntica, e nenhuma proximidade a um nó em particular a altera. Entre blocos, a chegada continua a contar — mas a unidade de competição é o bloco, não o microssegundo.
A ordem das fases do kernel reforça isto: os cancelamentos executam antes das colocações agressivas dentro de um bloco, pelo que uma cotação colocada no livro não pode ser levada por uma ordem que chegou no mesmo bloco que o seu cancelamento.
Cruzar uma ordem
Ordem que entra
Cruza o livro?
Consumir o melhor nível oposto
Emitir execução
Fim
A sobra fica no livro ou é rejeitada pela validadeGTC fica no livro · IOC cancela · FOK não executa nada se não executar tudo · post-only é rejeitada em vez de cruzar
sobra — consumir o nível seguinte
sem sobra
O motor de matching consome repetidamente o topo do lado oposto, emitindo uma execução por cada maker que consome, até a ordem que entra se esgotar ou o livro deixar de cruzar. O que acontece a qualquer sobra é decidido pela validade da ordem:
* **GTC** — a sobra fica no livro.
* **IOC** — a sobra é cancelada.
* **FOK** — se a ordem não puder ser executada na totalidade, nada executa.
* **ALO** — post-only (apenas maker): se a ordem fosse retirar liquidez, é rejeitada em vez de cruzar.
As execuções trazem atribuição à medida que são produzidas. Cada execução regista onde se situa na sequência de execuções do seu instrumento, e essas posições por instrumento são resolvidas numa única ordenação ao longo do bloco quando a saída é montada. É isto que permite, mais tarde, rastrear um evento até à transação exata e ao ponto exato do bloco que o causou.
Prevenção de autonegociação
Quando uma ordem que entra cruzaria com liquidez do mesmo titular que está no livro, o cruzamento é suprimido em vez de executado. Qual dos lados cede é configurável:
| Modo | Comportamento |
| ---------------- | ------------------------------------------------------------------ |
| **Expire taker** | A ordem que entra é cancelada |
| **Expire maker** | A ordem que está no livro é cancelada e a ordem que entra continua |
| **Expire both** | Ambas são canceladas |
Os makers cancelados desta forma são recolhidos durante o matching e removidos como parte do mesmo bloco, para que o livro não transporte uma ordem que já foi suprimida.
A titularidade para esta verificação é resolvida ao nível de conta que o livro acompanha. Ver [Prevenção de autonegociação](/pt/trading/self-trade-prevention) para a perspetiva do lado da negociação.
O que o matching não faz
Não calcula comissões, não realiza lucros e perdas, não ajusta posições nem verifica margem. Isso acontece depois do matching, na [câmara de compensação](/pt/protocol/architecture/clearinghouse), conduzido pelas execuções que o matching produziu.
Também não decide se uma ordem podia sequer existir. A adequação da margem, os limites de ordens abertas, as restrições reduce-only (apenas redução) e a conversão de mercado para limitada são resolvidos antes de a ordem chegar ao livro. Quando o motor de matching vê uma ordem, a única questão é onde ela pertence no livro.
Para onde ir a seguir
O que acontece aos saldos e às posições depois de existirem execuções.
A perspetiva do lado da negociação: o que pode submeter e como cada tipo se comporta.
Profundidade, níveis e como ler o livro enquanto trader.
Onde o matching se situa na execução do bloco.