> ## 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 > A camada de execução: um conjunto fechado de instruções de operações financeiras, executado como uma sequência fixa de fases sobre um bloco confirmado pelo consenso. O IntentionKernel é onde um bloco confirmado se torna estado de negociação. Não é uma máquina virtual de uso geral que executa programas arbitrários — o seu conjunto de instruções é o conjunto enumerado de operações financeiras de que uma plataforma de derivados precisa, e cada uma delas tem um efeito definido que o protocolo compreende. É essa distinção que permite à rede afirmar seja o que for sobre negociação. Uma cadeia de uso geral consegue dizer que uma transação foi assinada e não abortou. Não consegue dizer que a transação era o cancelamento de uma ordem específica numa posição específica do livro, porque o significado da chamada lhe é opaco. Aqui, o significado é a instrução.

Execução em mundo fechado

Fechar o conjunto de instruções é apenas uma instância de um gesto que o kernel faz quatro vezes. De cada vez, o espaço do que pode acontecer é enumerado à cabeça, e o que fica de fora é recusado em vez de tratado.
Operações
Uma carga que não pertence ao conjunto enumerado — recusada na validação, não em tempo de execução
O que foi realmente pedido
Verdade
Tratar o conjunto de trabalho do bloco como autoritativo. É um diário; a fonte é o estado do motor
O que é verdade neste momento
Entradas
Tudo o que pode diferir entre duas máquinas: relógio, entropia, vírgula flutuante, ordem de hash
Se outro nó obtém os mesmos bytes
Causalidade
Uma alteração de estado sem dono. Os efeitos que não pertencem a nenhuma transação passam por um canal de sistema, não por uma exceção
Porque aconteceu esta alteração em concreto
Fechado
Recusado
Assim o ledger consegue responder
Quatro fechos, um só gesto: enumerar o espaço à cabeça e recusar o que fica de fora.
Não são quatro virtudes independentes. Cada uma sustenta a seguinte: fechar as operações é o que torna recuperável o *significado* de uma instrução; um único estado autoritativo é o que dá sentido à palavra «resultado»; fechar as entradas é o que torna esse resultado reproduzível fora desta máquina; e fechar a causalidade é o que permite recuar de um resultado até ao pedido que o produziu. Retire uma e a cadeia de responsabilização parte-se nesse elo. O que as quatro compram em conjunto merece um nome, porque os locais tradicionais compram a mesma coisa muito mais caro. A trilha de auditoria de uma bolsa é montada **ao lado** do sistema de negociação e depois reportada a jusante — é por isso que pode divergir do sistema, é por isso que a reconciliação é um trabalho permanente, e é por isso que a sincronização de relógios entre locais é uma exigência regulatória e não um detalhe de implementação. Aqui não há um segundo registo com que reconciliar. A trilha de auditoria é a execução. O resto desta página são esses quatro fechos em detalhe.

O conjunto de instruções

Tudo o que um participante ou um validador pode fazer é uma de um conjunto fixo de operações tipadas: | Grupo | Operações | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Ordens** | Colocar, cancelar, substituir e alterar — nas formas limitada, de mercado e condicional, com validade da ordem, reduce-only (apenas redução) e estruturas take-profit / stop-loss ligadas | | **Configuração de conta** | Criação de subcontas, seleção de alavancagem, modo de margem, modo de posição | | **Transferências** | Entre subcontas, entre contas e para dentro e para fora através da [ponte](/pt/protocol/architecture/bridge) | | **Autorização de agente** | Autorizar e revogar um agente que negoceia em nome de uma conta | | **Operações de vault** | Criação, depósitos, levantamentos, configuração | | **Configuração do sistema** | Listagem de mercados, configuração de comissões, escalões de alavancagem, parâmetros de risco — autorizados pela governação | | **Emitidas por validadores** | Atualizações de preços certificados e reconfiguração | Uma transação cujo payload não pertença a este conjunto é rejeitada na validação. O conjunto só muda por atualização do protocolo, nunca por se instalar algo novo.

Executar um bloco

A execução é uma sequência fixa de fases. A ordem não é um detalhe de implementação — é o que determina se uma liquidação forçada vê o preço que a ativou e se um cancelamento chega antes de uma ordem agressora que entra.
Preçofixar as marcações do bloco
Cargaingerir as contas e ordens do bloco
Fundingacertar o funding
Riscodesalavancagem de vaults → liquidação → ADL
Matchingpré → matching → pós
Finalizarrecolher saídas, eliminar estado morto
As fases seguintes raciocinam sobre um preço por instrumento, não um em movimento
Acertado sobre as posições como carregadas, não como acabam
O fluxo forçado resolve-se antes de se admitir novo fluxo discricionário
Correr depois do Risco impede o front-running de uma liquidação por uma ordem do mesmo bloco
Posições zeradas e contas esvaziadas não persistem
Um bloco, seis fases
O que a posição determina
As ordens condicionais são varridas dentro desta sequência: uma ativação pelas marcações deste bloco produz efeito neste bloco e não no seguinte.
**Preço** corre primeiro e fixa as marcações que o resto do bloco vai usar, para que todas as fases seguintes raciocinem sobre um preço por instrumento e não sobre um preço em movimento. **Carga** ingere as contas e as ordens do bloco. **Funding** acerta o funding sobre as posições tal como foram carregadas. **Risco** corre três fases por ordem — desalavancagem de vaults, depois liquidação forçada, depois desalavancagem automática — para que o fluxo forçado fique resolvido antes de se admitir novo fluxo discricionário. **Matching** corre depois as suas próprias três fases, produzindo execuções. **Finalizar** recolhe o que mudou e elimina o estado que já não precisa de existir, como posições zeradas e contas esvaziadas. As ordens condicionais são varridas e avançam no seu ciclo de vida dentro desta sequência, pelo que uma ativação despoletada pelas marcações deste bloco produz efeito neste bloco e não no seguinte. O facto de a liquidação correr antes do matching é a razão pela qual não é possível fazer front-running a uma liquidação com uma ordem do mesmo bloco. O fluxo de liquidação já está resolvido quando as ordens discricionárias são cruzadas.

Dois tipos de estado

O kernel mantém uma separação estrita entre o que persiste e o que é rascunho.
enquanto o bloco executa
Estado do motormercados · contas · livros · posições · câmara de compensaçãopersiste entre blocos
Conjunto de trabalhomarcações · contas tocadas · execuções · resultadosdura apenas um bloco
Estado confirmado da cadeiaversionado · autenticadoa autoridade
É fácil confundir o registo de alterações com autoridade. O que mudou num bloco constrói saída determinista — não é onde o estado vive.
autoridade de onde o motor é reconstruído
ler
aplicar
materializar
O **estado do motor** vive de bloco para bloco: metadados de mercado, contas, livros de ordens, estado dos instrumentos, estado da câmara de compensação. É a resposta a «o que é verdade neste momento». O **conjunto de trabalho por bloco** existe apenas enquanto um bloco executa: as entradas do bloco, as marcações fixadas no início, as contas e ordens tocadas e as saídas em construção. É um diário, não uma fonte de verdade. A distinção importa porque é fácil confundir o registo de alterações com autoridade. O que mudou durante um bloco serve para construir saída determinista — não é onde o estado vive. Inverter isto produz um sistema em que a resposta depende da forma como a pergunta foi feita.

Porque o resultado é reproduzível

Aqui o determinismo é imposto, não esperado. Todos os nós honestos que executem o mesmo bloco sobre o mesmo estado anterior produzem o mesmo resultado byte a byte, porque nada no caminho de execução pode ler o que quer que seja que difira entre nós: * **Aritmética de vírgula fixa em todo o lado.** O cálculo da liquidação financeira corre em vírgula fixa inteira com semântica de arredondamento explícita — por excesso em expoentes negativos na margem, por defeito e por excesso nas comissões. Não há vírgula flutuante no caminho da liquidação financeira, porque uma diferença de arredondamento entre duas máquinas é um fork. * **Sem relógio de parede.** A ordenação dentro de um bloco usa a posição canónica confirmada pelo consenso e a data/hora do bloco, nunca a hora local. * **Sem aleatoriedade em tempo de execução.** Tudo o que precise de aleatoriedade deriva-a de forma determinista do estado da cadeia. * **Iteração determinista.** Qualquer coleção cuja ordem de iteração seja observável na saída é ordenada, não aleatorizada por hash. Vale a pena nomear uma consequência: como o «tempo» dentro de um bloco é a posição intrabloco confirmada, não existe qualquer vantagem de colocalização ao nível do submilissegundo *dentro* de um bloco. Combinado com a ordem de prioridades — que corre os cancelamentos antes das colocações agressivas — isto é uma defesa estrutural contra o risco de uma cotação colocada no livro ser apanhada por uma ordem que chegou no mesmo bloco.

As fórmulas de risco são puras

As fórmulas que decidem requisitos de margem, preços de liquidação, seleção para desalavancagem, comissões e limites de open interest (posições em aberto) são implementadas como **funções puras e sem estado**. Recebem valores e devolvem valores; não leem nem alteram o estado do ledger. As alterações de estado são conduzidas exclusivamente pela [câmara de compensação](/pt/protocol/architecture/clearinghouse), que chama essas funções e aplica os resultados. Os módulos que detêm estado — contas, posições, livros de ordens — armazenam dados e expõem mutadores, mas não conduzem eles próprios o fluxo de negócio. Esta fronteira é deliberada. Significa que um cálculo de margem pode ser verificado isoladamente contra uma tabela de entradas e saídas, e significa que existe exatamente um caminho de código pelo qual o saldo de alguém pode mudar.

Saída

A execução produz escritas de estado e eventos, cada um ligado à transação que o causou, mais um canal para efeitos ao nível do sistema que não pertencem a nenhuma transação de utilizador — funding, movimentos do fundo de seguro, contadores de bloco. Estes tornam-se as saídas de transação que a [camada de estado](/pt/protocol/architecture/state/model) confirma e o [indexador](/pt/protocol/architecture/indexer) serve. Nada do que acontece dentro do kernel é invisível a jusante. Se alterou estado, está na saída de alguém ou no canal do sistema.

Para onde ir a seguir

O livro de ordens, a prioridade preço-tempo e como se resolvem a validade da ordem e a prevenção de autonegociação. O único caminho pelo qual saldos, posições e margem mudam. Em que se torna a saída do kernel depois de confirmada. De onde vieram a ordenação e os preços.