> ## 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 > Il livello di esecuzione: un insieme chiuso di istruzioni finanziarie, eseguite come sequenza fissa di fasi su un blocco confermato dal consenso. IntentionKernel è il punto in cui un blocco confermato diventa stato di trading. Non è una macchina virtuale generalista che esegue programmi arbitrari: il suo insieme di istruzioni è l'insieme enumerato delle operazioni finanziarie di cui ha bisogno una piattaforma di derivati, e ognuna ha un effetto definito che il protocollo comprende. È questa distinzione a permettere alla rete di affermare qualcosa sul trading. Una catena generalista può dirti che una transazione è stata firmata e non si è interrotta. Non può dirti che quella transazione era l'annullamento di un ordine specifico in una posizione specifica del book, perché il significato della chiamata le è opaco. Qui il significato è l'istruzione.

Esecuzione a mondo chiuso

Chiudere l'insieme di istruzioni è solo un'istanza di una mossa che il kernel compie quattro volte. Ogni volta lo spazio di ciò che può accadere è enumerato in anticipo, e ciò che ne resta fuori viene rifiutato anziché gestito.
Operazioni
Un payload che non appartiene all'insieme enumerato: rifiutato in validazione, non a runtime
Che cosa è stato davvero chiesto
Verità
Trattare come autorevole il working set del blocco. Quello è un giornale; la fonte è lo stato del motore
Che cosa è vero adesso
Input
Tutto ciò che può differire fra due macchine: orologio, entropia, virgola mobile, ordine di hash
Se un altro nodo ottiene gli stessi byte
Causalità
Un cambiamento di stato senza titolare. Gli effetti che non appartengono a nessuna transazione passano da un canale di sistema, non da un'esenzione
Perché è avvenuto proprio questo cambiamento
Chiuso
Rifiutato
Così il ledger può rispondere
Quattro chiusure, una sola mossa: enumerare lo spazio in anticipo e rifiutare ciò che ne resta fuori.
Non sono quattro virtù indipendenti. Ciascuna regge la successiva: chiudere le operazioni è ciò che rende recuperabile il *significato* di un'istruzione; un unico stato autorevole è ciò che dà senso alla parola «risultato»; chiudere gli input è ciò che rende quel risultato riproducibile fuori da questa macchina; e chiudere la causalità è ciò che permette di risalire da un risultato alla richiesta che lo ha prodotto. Toglietene una e la catena di responsabilità si spezza proprio lì. Ciò che le quattro comprano insieme merita un nome, perché le sedi tradizionali comprano la stessa cosa a un costo assai maggiore. La pista di controllo di una borsa è assemblata **accanto** al sistema di negoziazione e poi segnalata a valle: per questo può divergere dal sistema, per questo la riconciliazione è un mestiere permanente, e per questo la sincronizzazione degli orologi fra sedi è un requisito regolamentare e non un dettaglio implementativo. Qui non esiste un secondo registro con cui riconciliare. La pista di controllo è l'esecuzione. Il resto di questa pagina sono quelle quattro chiusure in dettaglio.

L'insieme di istruzioni

Tutto ciò che un partecipante o un validatore può fare rientra in un insieme fisso di operazioni tipizzate: | Gruppo | Operazioni | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Ordini** | Immissione, annullamento, sostituzione e modifica — nelle forme limite, a mercato e condizionata, con validità dell'ordine, reduce-only e strutture take-profit / stop-loss collegate | | **Configurazione del conto** | Creazione di sottoconti, scelta della leva, modalità di margine, modalità di posizione | | **Trasferimenti** | Tra sottoconti, tra conti e in entrata e in uscita attraverso il [bridge](/it/protocol/architecture/bridge) | | **Autorizzazione degli agenti** | Autorizzare e revocare un agente che opera per conto di un conto | | **Operazioni sui vault** | Creazione, depositi, prelievi, configurazione | | **Configurazione di sistema** | Quotazione dei mercati, configurazione delle commissioni, livelli di leva, parametri di rischio — autorizzati dalla governance | | **Emesse dai validatori** | Aggiornamenti di prezzo certificati e riconfigurazione | Una transazione il cui payload non appartiene a questo insieme viene rifiutata in fase di validazione. L'insieme cambia solo con un aggiornamento di protocollo, mai mettendo in produzione qualcosa di nuovo.

Eseguire un blocco

L'esecuzione è una sequenza fissa di fasi. L'ordine non è un dettaglio implementativo: è ciò che determina se una liquidazione vede il prezzo che l'ha innescata e se un annullamento batte un ordine aggressivo in arrivo.
Prezzofissa i mark del blocco
Caricoacquisisce conti e ordini del blocco
Fundingregola il funding
Rischiodeleveraging vault → liquidazione → ADL
Matchingpre-match → matching → post-match
Finalizzazioneraccoglie output, pulisce stato morto
Ogni fase a valle ragiona su un prezzo per strumento, non su uno in movimento
Regolato sulle posizioni come caricate, non come finiscono
Il flusso forzato è risolto prima che entri quello discrezionale
Girando dopo Rischio, una liquidazione non è anticipabile da un ordine dello stesso blocco
Posizioni azzerate e conti svuotati non persistono
Un blocco, sei fasi
Che cosa determina la posizione
Gli ordini condizionati sono scanditi e fatti avanzare in questa sequenza: un'attivazione scattata dai mark di questo blocco ha effetto qui, non nel blocco successivo.
**Prezzo** viene eseguito per primo e fissa i mark che il resto del blocco userà, così ogni fase a valle ragiona su un prezzo per strumento invece che su uno in movimento. **Carico** acquisisce i conti e gli ordini del blocco. **Funding** regola il funding sulle posizioni così come sono state caricate. **Rischio** esegue tre fasi in ordine — deleveraging dei vault, poi liquidazione, poi auto-deleveraging — in modo che il flusso forzato sia risolto prima che venga ammesso nuovo flusso discrezionale. **Matching** esegue poi le sue tre fasi, producendo esecuzioni. **Finalizzazione** raccoglie ciò che è cambiato e ripulisce lo stato che non ha più ragione di esistere, come le posizioni azzerate e i conti svuotati. Gli ordini condizionati vengono scanditi e fatti avanzare nel loro ciclo di vita all'interno di questa sequenza, così un'attivazione scattata dai mark di questo blocco ha effetto in questo blocco e non nel successivo. Il fatto che la liquidazione giri prima del matching è la ragione per cui una liquidazione non può essere anticipata da un ordine nello stesso blocco. Il flusso di liquidazione è già risolto nel momento in cui gli ordini discrezionali vengono incrociati.

Due tipi di stato

Il kernel mantiene una separazione rigida tra ciò che persiste e ciò che è temporaneo.
esecuzione del blocco
Stato del motoremercati · conti · book · posizioni · stanza di compensazionevive tra i blocchi
Working set del bloccomark · conti toccati · esecuzioni · output in corsovive per un blocco
Stato della catenaversionato · autenticatol'autorità
Tracciare le modifiche è facile da scambiare per autorità. Ciò che cambia in un blocco costruisce output deterministico — non è dove risiede lo stato.
l'autorità da cui il motore è ricostruito
lettura
applica
materializza
**Lo stato del motore** sopravvive da un blocco all'altro: metadati dei mercati, conti, book degli ordini, stato degli strumenti, stato della stanza di compensazione. È la risposta alla domanda «che cosa è vero adesso». **Il working set per blocco** esiste solo mentre un blocco è in esecuzione: gli input del blocco, i mark fissati all'inizio, i conti e gli ordini toccati e gli output in via di assemblaggio. È un registro di lavoro, non una fonte di verità. La distinzione conta perché è facile scambiare il tracciamento delle modifiche per autorità. Ciò che è cambiato durante un blocco serve a costruire output deterministico: non è il luogo in cui lo stato risiede. Invertire le due cose produce un sistema in cui la risposta dipende da come hai fatto la domanda.

Perché il risultato è riproducibile

Qui il determinismo è imposto, non sperato. Ogni nodo onesto che esegue lo stesso blocco sullo stesso stato precedente produce lo stesso risultato byte per byte, perché nulla sul percorso di esecuzione può leggere qualcosa che differisca da nodo a nodo: * **Aritmetica a virgola fissa ovunque.** I calcoli di regolamento girano su interi a virgola fissa con semantica di arrotondamento esplicita: per eccesso sugli esponenti negativi nel margine, per difetto e per eccesso sulle commissioni. Sul percorso di regolamento non c'è virgola mobile, perché una differenza di arrotondamento tra due macchine è un fork. * **Nessun orologio di sistema.** L'ordinamento dentro un blocco usa la posizione canonica confermata dal consenso e il timestamp del blocco, mai l'ora locale. * **Nessuna casualità a runtime.** Tutto ciò che richiede casualità la deriva in modo deterministico dallo stato della catena. * **Iterazione deterministica.** Ogni collezione il cui ordine di iterazione è osservabile nell'output è ordinata, non randomizzata sull'hash. Vale la pena nominare una conseguenza: poiché il «tempo» dentro un blocco è la posizione intra-blocco confermata, *dentro* un blocco non esiste alcun vantaggio di colocation sotto il millisecondo. Unito all'ordine di priorità — che esegue gli annullamenti prima delle immissioni aggressive — questa è una difesa strutturale contro il rischio che un prezzo esposto in book venga colpito da un ordine arrivato nello stesso blocco.

Le formule di rischio sono pure

Le formule che decidono requisiti di margine, prezzi di liquidazione, selezione per il deleveraging, commissioni e limiti di open interest sono implementate come **funzioni pure e senza stato**. Prendono valori e restituiscono valori; non leggono né modificano lo stato del ledger. I cambiamenti di stato sono guidati esclusivamente dalla [stanza di compensazione](/it/protocol/architecture/clearinghouse), che chiama quelle funzioni e ne applica i risultati. I moduli che detengono stato — conti, posizioni, book degli ordini — memorizzano dati ed espongono mutatori, ma non guidano da soli il flusso applicativo. È un confine deliberato. Significa che un calcolo di margine si può verificare in isolamento su una tabella di input e output, e significa che esiste esattamente un percorso di codice attraverso cui il saldo di chiunque può cambiare. ## Output L'esecuzione produce scritture di stato ed eventi, ciascuno legato alla transazione che lo ha causato, più un canale per gli effetti a livello di sistema che non appartengono a nessuna singola transazione utente: funding, movimenti del fondo assicurativo, contatori di blocco. Diventano gli output di transazione che il [livello di stato](/it/protocol/architecture/state/model) conferma e l'[indexer](/it/protocol/architecture/indexer) serve. Niente di ciò che accade dentro il kernel è invisibile a valle. Se ha cambiato lo stato, è nell'output di qualcuno o nel canale di sistema.

Dove proseguire

Il book degli ordini, la priorità prezzo-tempo e come si risolvono validità dell'ordine e prevenzione dell'auto-negoziazione. L'unica strada attraverso cui cambiano saldi, posizioni e margine. Che cosa diventa l'output del kernel una volta confermato. Da dove arrivano l'ordinamento e i prezzi.