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

> Das Orderbuch, wie die Preis-Zeit-Priorität abgebildet ist und wie sich Gültigkeitsdauer und Selbstausführungsschutz dagegen auflösen.

Das Matching ist eine Stufe innerhalb der [Kernel-Ausführung](/de/protocol/architecture/kernel), kein Dienst, mit dem die Chain spricht. Es nimmt die Orders des Blocks in ihrer festgeschriebenen Reihenfolge, arbeitet sie gegen das Buch ab und erzeugt Ausführungen. Es bewegt niemandes Guthaben – das ist Aufgabe der [Clearingstelle](/de/protocol/architecture/clearinghouse) und geschieht, nachdem das Matching abgeschlossen ist.

Erst diese Trennung macht die Engine testbar. Das Matching beantwortet, *was gegen was gehandelt wurde*. Die Clearingstelle beantwortet, *was das kostet und wer wem jetzt was schuldet*.

<h2 id="the-book">
  Das Buch
</h2>

Jedes Instrument hat sein eigenes Buch, im Arbeitsspeicher gehalten als drei zusammenwirkende Strukturen:

<div className="dg" data-dg="matching-book">
  <div className="dg-c" style={{aspectRatio:"720 / 302"}}>
    <svg className="dg-w" viewBox="0 0 720 302" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 348.60 82.00 L 352.60 82.00" />

      <path className="dg-wire dg-soft" d="M 438.20 82.00 L 442.20 82.00" />

      <path className="dg-wire dg-soft" d="M 527.80 82.00 L 531.80 82.00" />

      <path className="dg-wire dg-soft" d="M 617.40 82.00 L 621.40 82.00" />

      <path className="dg-wire dg--blue" d="M 205.00 68.00 L 238.60 68.00" />

      <path className="dg-head dg--blue" d="M 245.00 68.00 L 238.60 72.40 L 238.60 63.60 Z" />

      <path className="dg-wire dg--sky" d="M 205.00 162.00 L 238.60 162.00" />

      <path className="dg-head dg--sky" d="M 245.00 162.00 L 238.60 166.40 L 238.60 157.60 Z" />
    </svg>

    <div className="dg-band" style={{left:"34.7222%",top:"9.9338%",width:"65.2778%",height:"56.2914%"}}><span className="dg-cap">Slab Arena – vorab reservierter Bereich mit Order-Slots</span></div>
    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"9.9338%",width:"27.7778%",height:"25.1656%"}}><span className="dg-t">Preisebenen</span><span className="dg-s">geordnet, Preis → Ebene</span><span className="dg-n">die Spitze findet man am Ende, nicht durch Suchen</span></div>
    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"41.0596%",width:"27.7778%",height:"25.1656%"}}><span className="dg-t">Order-Index</span><span className="dg-s">Order-ID → Slot</span><span className="dg-n">Stornieren, Ändern: konstante Zeit</span></div>
    <div className="dg-b dg--yellow" style={{left:"36.9444%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">Order</span></div>
    <div className="dg-b dg--yellow" style={{left:"49.3889%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">Order</span></div>
    <div className="dg-b dg--yellow" style={{left:"61.8333%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">Order</span></div>
    <div className="dg-b dg--yellow" style={{left:"74.2778%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">Order</span></div>
    <div className="dg-b dg--yellow" style={{left:"86.7222%",top:"19.5364%",width:"11.0556%",height:"15.2318%"}}><span className="dg-t">Order</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"36.9444%",top:"41.3907%",width:"60.8333%",height:"15.2318%"}}><span className="dg-s">Doppelt verkettet in Eintreffreihenfolge – die Priorität in einer Ebene ergibt sich aus der Position, nicht aus einer Rechnung.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"74.8344%",width:"100.0000%",height:"20.5298%"}}><span className="dg-t">Warum feste Wiederverwendung</span><span className="dg-s">Freigegebene Slots werden in fester Reihenfolge wiederverwendet, der Index hat festen Seed. Keine Performance-Frage: Zwei Validatoren mit anderer Reihenfolge forken.</span></div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"17.8808%",width:"15.2778%",whiteSpace:"normal"}}>Kopf jeder Ebene</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"62.9139%",width:"15.2778%",whiteSpace:"normal"}}>direkter Zugriff</div>
  </div>
</div>

| Struktur        | Rolle                                                                                                                                                                                      |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Preisebenen** | Eine geordnete Abbildung von Preis auf Ebene, sodass sich bestes Bid und bestes Ask am Ende ablesen lassen, statt sie zu suchen                                                            |
| **Orderkette**  | Eine doppelt verkettete Liste, die Orders in der Reihenfolge ihres Eintreffens auffädelt, sodass sich die Priorität innerhalb einer Ebene aus der Position ergibt und nicht berechnet wird |
| **Order-Index** | Eine direkte Abbildung von der Order-ID auf ihren Slot, sodass Stornieren und Ändern konstante Zeit kosten und keine Suche erfordern                                                       |

Orders liegen in einer **Slab Arena** – einem vorab reservierten Bereich mit Allokation und Freigabe in konstanter Zeit. Orderbuchoperationen allokieren deshalb nicht auf dem heißen Pfad, und freigegebene Slots werden in einer festen Reihenfolge wiederverwendet und nicht dort, wo der Allokator sie zufällig ablegt. Dieses letzte Detail ist keine Performance-Entscheidung: Würden zwei Validatoren Slots in unterschiedlicher Reihenfolge wiederverwenden, liefe alles auseinander, was das Slot-Layout beobachtet.

Dieselbe Disziplin gilt für den Order-Index, dessen Seed fest und nicht zufällig ist. Eine Hash-Map mit prozessindividuellem Seed ist ein üblicher Schutz gegen Kollisionsangriffe; auf einem Konsens-Ausführungspfad ist sie ein Fork.

Preise sind durchgehend ganze Zahlen – Subtick-Einheiten, keine Dezimalzahlen. Wie sich das auf das abbildet, was Sie absenden, steht unter [Präzision](/de/trading/precision).

<h2 id="priority">
  Priorität
</h2>

Priorität ist zuerst der Preis, dann die Position in der Kette zu diesem Preis. „Zeit“ ist die kanonische Position der Order in der festgeschriebenen Blockreihenfolge, nicht der Moment, in dem sie bei einer Node ankam.

Das beseitigt das Latenzrennen innerhalb eines Blocks. Zwei Orders im selben Block haben einen definierten Vorrang, den jeder Validator identisch berechnet, und keine noch so große Nähe zu einer bestimmten Node ändert daran etwas. Zwischen Blöcken zählt das Eintreffen weiterhin – aber die Einheit des Wettbewerbs ist der Block, nicht die Mikrosekunde.

Die Stufenreihenfolge des Kernels verstärkt das: Stornierungen werden innerhalb eines Blocks vor aggressiven Platzierungen ausgeführt, sodass eine liegende Quotierung nicht von einer Order genommen werden kann, die im selben Block eintraf wie ihre Stornierung.

<h2 id="matching-an-order">
  Eine Order matchen
</h2>

<div className="dg" data-dg="matching-walk">
  <div className="dg-c" style={{aspectRatio:"720 / 334"}}>
    <svg className="dg-w" viewBox="0 0 720 334" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 134.00 144.00 L 155.60 144.00" />

      <path className="dg-head dg--blue" d="M 162.00 144.00 L 155.60 148.40 L 155.60 139.60 Z" />

      <path className="dg-wire dg--sky" d="M 320.00 144.00 L 345.60 144.00" />

      <path className="dg-head dg--sky" d="M 352.00 144.00 L 345.60 148.40 L 345.60 139.60 Z" />

      <path className="dg-wire dg--green" d="M 510.00 144.00 L 535.60 144.00" />

      <path className="dg-head dg--green" d="M 542.00 144.00 L 535.60 148.40 L 535.60 139.60 Z" />

      <path className="dg-wire dg--sky" d="M 633.00 114.00 L 633.00 80.00 L 241.00 80.00 L 241.00 103.60" />

      <path className="dg-head dg--sky" d="M 241.00 110.00 L 236.60 103.60 L 245.40 103.60 Z" />

      <path className="dg-wire dg--green" d="M 633.00 174.00 L 633.00 213.60" />

      <path className="dg-head dg--green" d="M 633.00 220.00 L 628.60 213.60 L 637.40 213.60 Z" />

      <path className="dg-wire dg--sky" d="M 241.00 178.00 L 241.00 213.60" />

      <path className="dg-head dg--sky" d="M 241.00 220.00 L 236.60 213.60 L 245.40 213.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"35.3293%",width:"18.0556%",height:"15.5689%"}}><span className="dg-t">Eingehende Order</span></div>
    <div className="dg-b dg--yellow dg-round" style={{left:"23.0556%",top:"34.1317%",width:"20.8333%",height:"17.9641%"}}><span className="dg-t">Kreuzt das Buch?</span></div>
    <div className="dg-b dg--sky" style={{left:"49.4444%",top:"35.3293%",width:"20.8333%",height:"15.5689%"}}><span className="dg-t">Beste Gegenebene abarbeiten</span></div>
    <div className="dg-b dg--green" style={{left:"75.8333%",top:"35.3293%",width:"24.1667%",height:"15.5689%"}}><span className="dg-t">Ausführung erzeugen</span></div>
    <div className="dg-b dg--green" style={{left:"75.8333%",top:"67.0659%",width:"24.1667%",height:"25.7485%"}}><span className="dg-t">Fertig</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"10.5556%",top:"67.0659%",width:"45.8333%",height:"25.7485%"}}><span className="dg-t">Liegen bleiben oder ablehnen, je Gültigkeitsdauer</span><span className="dg-s">GTC bleibt liegen · IOC storniert · FOK führt nur vollständig aus · Post-only wird abgelehnt statt zu kreuzen</span></div>
    <div className="dg-lbl" style={{left:"60.6944%",top:"23.9521%",width:"27.7778%",whiteSpace:"normal"}}>Restmenge – nächste Ebene</div>
    <div className="dg-lbl" style={{left:"87.9167%",top:"58.9820%"}}>nichts übrig</div>
  </div>
</div>

Der Matcher arbeitet wiederholt den Kopf der Gegenseite ab und erzeugt für jeden genommenen Maker eine Ausführung, bis die eingehende Order erschöpft ist oder das Buch nicht mehr kreuzt. Was mit einer Restmenge geschieht, entscheidet die Gültigkeitsdauer:

* **GTC** – die Restmenge bleibt im Buch liegen.
* **IOC** – die Restmenge wird storniert.
* **FOK** – kann die Order nicht vollständig ausgeführt werden, wird überhaupt nichts ausgeführt.
* **ALO** – Post-only: Würde die Order Liquidität nehmen, wird sie abgelehnt, statt zu kreuzen.

Jede Ausführung bringt ihre Zurechnung schon bei der Entstehung mit. Jede Ausführung hält fest, wo sie in der Folge der Ausführungen ihres Instruments sitzt, und diese Positionen je Instrument werden beim Zusammenstellen der Ausgabe in eine einzige Reihenfolge über den ganzen Block aufgelöst. Genau das erlaubt es, ein Event später auf exakt die Transaktion und exakt die Stelle im Block zurückzuführen, die es verursacht hat.

<h2 id="self-trade-prevention">
  Selbstausführungsschutz
</h2>

Trifft eine eingehende Order auf liegende Liquidität desselben Inhabers, wird das Match unterdrückt statt ausgeführt. Welche Seite weicht, ist konfigurierbar:

| Modus            | Verhalten                                                          |
| ---------------- | ------------------------------------------------------------------ |
| **Expire taker** | Die eingehende Order wird storniert                                |
| **Expire maker** | Die liegende Order wird storniert, und die eingehende läuft weiter |
| **Expire both**  | Beide werden storniert                                             |

Auf diese Weise stornierte Maker-Orders werden während des Matchings gesammelt und im selben Block entfernt, sodass das Buch keine Order führt, die bereits unterdrückt wurde.

Für diese Prüfung gilt die Kontoebene, die das Buch mitführt. Die Sicht aus der Handelsperspektive steht unter [Selbstausführungsschutz](/de/trading/self-trade-prevention).

<h2 id="what-matching-does-not-do">
  Was das Matching nicht tut
</h2>

Es berechnet keine Gebühren, realisiert keine Gewinne und Verluste, passt keine Positionen an und prüft keine Margin. Das geschieht nach dem Matching in der [Clearingstelle](/de/protocol/architecture/clearinghouse), angetrieben von den Ausführungen, die das Matching erzeugt hat.

Es entscheidet auch nicht, ob eine Order überhaupt existieren durfte. Margin-Deckung, Limits für offene Orders, Reduce-only-Bedingungen und die Umwandlung von Market in Limit sind geklärt, bevor eine Order das Buch erreicht. Wenn der Matcher eine Order sieht, ist die einzige Frage, wohin sie im Buch gehört.

<h2 id="where-to-go-next">
  Wie es weitergeht
</h2>

<CardGroup cols={2}>
  <Card title="Clearingstelle" href="/de/protocol/architecture/clearinghouse">
    Was mit Guthaben und Positionen geschieht, sobald Ausführungen vorliegen.
  </Card>

  <Card title="Ordertypen" href="/de/trading/order-types">
    Die Sicht aus der Handelsperspektive: was Sie absenden können und wie sich das jeweils verhält.
  </Card>

  <Card title="Orderbuch" href="/de/trading/order-book">
    Markttiefe, Ebenen und das Buch als Trader lesen.
  </Card>

  <Card title="IntentionKernel" href="/de/protocol/architecture/kernel">
    Wo das Matching in der Blockausführung sitzt.
  </Card>
</CardGroup>