> ## 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
> Die Ausführungsschicht: ein geschlossener Befehlssatz von Finanzoperationen, ausgeführt als feste Folge von Stufen über einem konsensbestätigten Block.
Im IntentionKernel wird ein festgeschriebener Block zu Handelszustand. Er ist keine virtuelle Allzweckmaschine, die beliebige Programme ausführt – sein Befehlssatz ist die abschließend aufgezählte Menge der Finanzoperationen, die ein Derivate-Handelsplatz braucht, und jede von ihnen hat eine definierte Wirkung, die das Protokoll versteht.
Dieser Unterschied ist der Grund, warum das Netzwerk überhaupt Aussagen über den Handel treffen kann. Eine Allzweck-Chain kann Ihnen sagen, dass eine Transaktion signiert wurde und nicht abgebrochen ist. Sie kann Ihnen nicht sagen, dass die Transaktion die Stornierung einer bestimmten Order an einer bestimmten Stelle im Buch war, denn die Bedeutung des Aufrufs ist ihr undurchsichtig. Hier ist die Bedeutung der Befehl.
Closed-World-Ausführung
Das Schließen des Instruktionssatzes ist nur ein Fall eines Zuges, den der Kernel viermal macht. Jedes Mal wird der Raum des Möglichen vorab aufgezählt, und was außerhalb liegt, wird abgelehnt statt behandelt.
Operationen
Eine Payload, die nicht Element der aufgezählten Menge ist – abgelehnt bei der Validierung, nicht zur Laufzeit
Was tatsächlich verlangt wurde
Wahrheit
Den Arbeitssatz eines Blocks als maßgeblich zu behandeln. Er ist ein Journal; die Quelle ist der Engine-Zustand
Was gerade wahr ist
Eingaben
Alles, was sich zwischen zwei Maschinen unterscheiden kann: Uhr, Entropie, Gleitkomma, Hash-Reihenfolge
Ob eine andere Node dieselben Bytes erhält
Kausalität
Eine Zustandsänderung ohne Urheber. Effekte, die zu keiner Nutzertransaktion gehören, laufen über einen Systemkanal, nicht über eine Ausnahme
Warum genau diese Änderung geschah
Geschlossen
Abgelehnt
Damit beantwortet das Ledger
Vier Schließungen, ein Zug: den Raum vorab aufzählen und alles ablehnen, was außerhalb liegt.
Das sind keine vier unabhängigen Tugenden. Jede trägt die nächste: Erst das Schließen der Operationen macht die *Bedeutung* einer Instruktion rekonstruierbar; erst ein einziger maßgeblicher Zustand gibt dem Wort „Ergebnis" einen Sinn; erst geschlossene Eingaben machen dieses Ergebnis auf einer anderen Maschine reproduzierbar; und erst geschlossene Kausalität erlaubt es, von einem Ergebnis zur Anforderung zurückzugehen, die es erzeugt hat. Nimmt man eine weg, reißt die Kette der Zurechenbarkeit genau dort.
Was die vier zusammen einkaufen, verdient einen Namen, denn traditionelle Handelsplätze kaufen dasselbe weit teurer. Der Prüfpfad einer Börse wird **neben** dem Handelssystem zusammengesetzt und weitergemeldet — deshalb kann er vom System abweichen, deshalb ist Abstimmung eine Daueraufgabe, und deshalb ist die Uhrensynchronisation zwischen Handelsplätzen eine regulatorische Anforderung und kein Implementierungsdetail. Hier gibt es keinen zweiten Datensatz, gegen den abgestimmt werden müsste. Der Prüfpfad ist die Ausführung.
Der Rest dieser Seite sind diese vier Schließungen im Detail.
Der Befehlssatz
Alles, was ein Teilnehmer oder ein Validator tun kann, stammt aus einer festen Menge typisierter Operationen:
| Gruppe | Operationen |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Orders** | Platzieren, stornieren, ersetzen und ändern – über Limit-, Market- und bedingte Formen hinweg, mit Gültigkeitsdauer, Reduce-only und verknüpften Take-Profit-/Stop-Loss-Strukturen |
| **Kontokonfiguration** | Anlegen von Unterkonten, Hebelwahl, Margin-Modus, Positionsmodus |
| **Transfers** | Zwischen Unterkonten, zwischen Konten sowie hinein und hinaus über die [Bridge](/de/protocol/architecture/bridge) |
| **Agenten-Autorisierung** | Autorisieren und Widerrufen eines Agenten, der im Auftrag eines Kontos handelt |
| **Vault-Operationen** | Anlegen, Einzahlungen, Auszahlungen, Konfiguration |
| **Systemkonfiguration** | Listing von Märkten, Gebührenkonfiguration, Hebelstufen, Risikoparameter – von der Governance autorisiert |
| **Von Validatoren erzeugt** | Zertifizierte Preisaktualisierungen und Rekonfiguration |
Eine Transaktion, deren Nutzlast nicht zu dieser Menge gehört, wird bei der Validierung abgelehnt. Die Menge ändert sich nur durch ein Protokoll-Upgrade, nie dadurch, dass jemand etwas Neues deployt.
Einen Block ausführen
Die Ausführung ist eine feste Folge von Stufen. Die Reihenfolge ist kein Implementierungsdetail – sie entscheidet, ob eine Liquidation den Preis sieht, der sie ausgelöst hat, und ob eine Stornierung einer eingehenden aggressiven Order zuvorkommt.
Jede weitere Stufe rechnet mit einem Preis je Instrument statt mit einem laufenden
Abgerechnet gegen die geladenen Positionen, nicht die späteren
Erzwungener Fluss ist aufgelöst, bevor neuer diskretionärer zugelassen wird
Weil es nach Risiko läuft, kann keine Order im selben Block einer Liquidation zuvorkommen
Genullte Positionen und leere Konten bleiben nicht
Ein Block, sechs Stufen
Was der Platz bestimmt
Bedingte Orders werden in dieser Folge geprüft und weitergeführt: Ein von den Marks dieses Blocks gefeuerter Auslöser wirkt hier, nicht erst im nächsten Block.
**Preis** läuft zuerst und fixiert die Marks, die der Rest des Blocks verwendet, sodass jede nachgelagerte Stufe mit einem Preis je Instrument rechnet statt mit einem laufenden. **Laden** liest die Konten und Orders des Blocks ein. **Funding** rechnet das Funding gegen die Positionen ab, wie sie geladen wurden. **Risiko** durchläuft drei Phasen in fester Reihenfolge – Vault-Deleveraging, dann Liquidation, dann Auto-Deleveraging –, damit erzwungener Fluss aufgelöst ist, bevor neuer diskretionärer Fluss zugelassen wird. **Matching** durchläuft danach seine eigenen drei Phasen und erzeugt Ausführungen. **Finalisieren** sammelt ein, was sich geändert hat, und löscht Zustand, der nicht mehr existieren muss, etwa auf null gestellte Positionen und geleerte Konten.
Bedingte Orders werden innerhalb dieser Folge geprüft und in ihrem Lebenszyklus weitergeführt, sodass ein Auslöser, den die Marks dieses Blocks feuern, in diesem Block wirkt und nicht erst im nächsten.
Dass die Liquidation vor dem Matching läuft, ist der Grund, warum einer Liquidation keine Order im selben Block zuvorkommen kann. Der liquidierende Fluss ist bereits aufgelöst, wenn diskretionäre Orders gematcht werden.
Zwei Arten von Zustand
Der Kernel trennt strikt zwischen dem, was fortbesteht, und dem, was nur Zwischenstand ist.
Änderungsverfolgung ist nicht Maßgeblichkeit. Was sich im Block geändert hat, baut deterministische Ausgaben – dort liegt der Zustand nicht.
maßgeblich – die Engine wird daraus gebaut
liest
anwenden
materialisieren
**Der Engine-Zustand** überdauert Blöcke: Marktmetadaten, Konten, Orderbücher, Instrumentenzustand, Zustand der Clearingstelle. Er ist die Antwort auf „was ist gerade wahr“.
**Das Working Set je Block** existiert nur, solange ein Block ausgeführt wird: die Eingaben des Blocks, die zu Beginn fixierten Marks, die berührten Konten und Orders und die entstehenden Ausgaben. Es ist ein Journal, keine Quelle der Wahrheit.
Der Unterschied zählt, weil sich Änderungsverfolgung leicht mit Maßgeblichkeit verwechseln lässt. Was sich während eines Blocks geändert hat, dient dazu, deterministische Ausgaben zu bauen – dort liegt der Zustand nicht. Wer das vertauscht, baut ein System, in dem die Antwort davon abhängt, wie gefragt wurde.
Warum das Ergebnis reproduzierbar ist
Determinismus wird hier erzwungen, nicht erhofft. Jede ehrliche Node, die denselben Block gegen denselben Vorzustand ausführt, erzeugt Byte für Byte dasselbe Ergebnis, weil nichts auf dem Ausführungspfad etwas lesen kann, das sich zwischen Nodes unterscheidet:
* **Durchgehend Festkommaarithmetik.** Die Abrechnungsmathematik läuft auf ganzzahligem Festkomma mit expliziter Rundungssemantik – Aufrunden bei negativen Exponenten in der Margin, Abrunden (floor) und Aufrunden (ceiling) bei Gebühren. Auf dem Abrechnungspfad gibt es kein Gleitkomma, denn ein Rundungsunterschied zwischen zwei Maschinen ist ein Fork.
* **Keine Systemzeit.** Die Reihenfolge innerhalb eines Blocks nutzt die vom Konsens festgeschriebene kanonische Position und den Block-Zeitstempel, nie die lokale Systemzeit.
* **Kein Zufall zur Laufzeit.** Was Zufall braucht, leitet ihn deterministisch aus dem Chain-Zustand ab.
* **Deterministische Iteration.** Jede Sammlung, deren Iterationsreihenfolge in der Ausgabe beobachtbar ist, ist sortiert und nicht hash-randomisiert.
Eine Folge verdient es, benannt zu werden: Weil „Zeit“ innerhalb eines Blocks die festgeschriebene Position im Block ist, gibt es *innerhalb* eines Blocks keinen Colocation-Vorteil im Submillisekundenbereich. Zusammen mit der Prioritätsreihenfolge – die Stornierungen vor aggressiven Platzierungen ausführt – ist das ein struktureller Schutz davor, dass eine liegende Quotierung von einer Order abgegriffen wird, die im selben Block eingetroffen ist.
Risikoformeln sind rein
Die Formeln, die über Margin-Anforderungen, Liquidationspreise, Deleveraging-Auswahl, Gebühren und Open-Interest-Limits entscheiden, sind als **reine, zustandslose Funktionen** umgesetzt. Sie nehmen Werte entgegen und geben Werte zurück; sie lesen und verändern keinen Ledger-Zustand.
Zustandsänderungen werden ausschließlich von der [Clearingstelle](/de/protocol/architecture/clearinghouse) angestoßen, die diese Funktionen aufruft und die Ergebnisse anwendet. Die Module, die Zustand halten – Konten, Positionen, Orderbücher –, speichern Daten und stellen Mutatoren bereit, treiben aber selbst keinen fachlichen Ablauf.
Das ist eine bewusste Grenze. Sie bedeutet, dass sich eine Margin-Berechnung isoliert gegen eine Tabelle aus Eingaben und Ausgaben prüfen lässt, und sie bedeutet, dass es genau einen Codepfad gibt, über den sich das Guthaben von irgendjemandem ändern kann.
Ausgabe
Die Ausführung erzeugt Zustandsschreibvorgänge und Events, jeweils gebunden an die Transaktion, die sie verursacht hat, dazu einen Kanal für Effekte auf Systemebene, die zu keiner einzelnen Nutzertransaktion gehören – Funding, Bewegungen des Versicherungsfonds, Blockzähler. Daraus werden die Transaktionsausgaben, die die [Zustandsschicht](/de/protocol/architecture/state/model) festschreibt und der [Indexer](/de/protocol/architecture/indexer) ausliefert.
Nichts, was im Kernel geschieht, bleibt nachgelagert unsichtbar. Wenn es Zustand geändert hat, steht es in der Ausgabe von jemandem oder im Systemkanal.
Wie es weitergeht
Das Orderbuch, die Preis-Zeit-Priorität und wie Gültigkeitsdauer und Selbstausführungsschutz aufgelöst werden.
Der einzige Pfad, über den sich Guthaben, Positionen und Margin ändern.
Was aus der Ausgabe des Kernels wird, sobald sie festgeschrieben ist.
Woher die Reihenfolge und die Preise stammen.