> ## 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. # Programmdienste > Dienste, die den Kontozustand off-chain aus der festgeschriebenen Handelshistorie ableiten und das Ergebnis über Protokolltransaktionen zurück auf die Chain schreiben. Manches, was ein Handelsplatz über ein Konto wissen muss, lässt sich nicht während der Blockausführung berechnen. Eine Volumenstufe hängt an dreißig Tagen Handel. Eine Prämie hängt an einem Zeitfenster, das noch nicht geschlossen ist. Eine Empfehlungszuordnung hängt an einer Beziehung, die vor Monaten entstanden ist. Diese Arbeit in die Blockausführung zu verlagern, wäre gleich doppelt falsch: Jeder Block müsste für eine Berechnung zahlen, die fast kein Block braucht, und der Kernel müsste Historie mitführen, für die er sonst keinen Grund hat. Programmdienste lösen das, indem sie die Richtung umkehren. Die Berechnung läuft **außerhalb** des Blocks, über den festgeschriebenen Datensatz. Ihr *Ergebnis* wird anschließend **zurück** auf die Chain geschrieben, als Protokollzustand, den die Ausführung wie jede andere Konfiguration in konstanter Zeit lesen kann.
Festgeschriebene Handelshistorie
ProgrammdienstFensterberechnung, außerhalb des Blocksliest die Gebührentabelle live von der Chain
Seit letzter Anwendung geändert?
Nichts geschrieben
Protokolltransaktion
Chain-Zustand
Bei der Ausführung gelesenin konstanter Zeit
Verglichen wird an Sätzen, nicht an StufenpositionenEine verschobene Schwelle oder eine neu bepreiste Stufe ändert, was ein Konto zahlt, ohne seinen Stufenindex zu ändern.
Den endgültigen Satz löst die Chain aufEine Periode gilt erst als angewendet, wenn jeder Stapel festgeschrieben ist; ein Absturz wiederholt die ganze Periode – gefahrlos, weil die Berechnung idempotent ist.
Maßgeblich bleibt die Chain. Ein Dienst hält keinen Zustand, von dem das Netzwerk abhängt – er schlägt einen Wert vor, und real ist nur, was die Chain angenommen hat.

Was heute läuft

**Volumenbasierte Gebührenstufen.** Der Dienst konsumiert die Handelshistorie, die eine Node streamt, summiert das Volumen je Konto und legt nach Zeitplan Snapshots an. Schließt eine Periode, berechnet er für jedes Konto das Volumen im gleitenden Fenster, bildet es über die **live von der Chain gelesene** Gebührenkonfiguration ab und schreibt geänderte Konten in Stapeln zurück. Mehrere Details in diesem Satz sind tragend: * **Die Stufentabelle wird von der Chain gelesen, nie fest einprogrammiert.** Ein Dienst mit eigener Kopie würde weiter die gestrige Staffel anwenden, nachdem das Netzwerk sie geändert hat. * **Verglichen wird mit den Sätzen, nicht mit den Stufenpositionen.** Ein Vergleich der Stufen*indizes* übersieht zwei reale Fälle: Eine Schwelle verschiebt sich, sodass ein unverändertes Konto in einer anderen Stufe landet, oder eine Stufe erhält einen neuen Satz, während ihr Index gleich bleibt. Beides ändert, was ein Konto zahlt; keines ändert seinen Index. * **Den endgültigen Satz löst die Chain auf.** Die Transaktion enthält einen Stufenindex; die Ausführung löst ihn gegen die aktuelle Gebührenkonfiguration auf. Ein Stufenindex außerhalb des gültigen Bereichs lässt den gesamten Stapel scheitern, statt teilweise angewendet zu werden. * **Eine Periode gilt erst als angewendet, wenn jeder Stapel festgeschrieben ist.** Ein Absturz mitten in der Periode führt zum Replay der ganzen Periode, was gefahrlos ist, weil die Berechnung idempotent ist – dasselbe Fenster liefert dasselbe Ergebnis.

Das Fehlermodell

Diese Dienste sitzen zwischen zwei Systemen, die beide zeitweise nicht verfügbar sein werden. Das Design setzt das voraus, statt es als Ausnahme zu behandeln. Ausfälle von Abhängigkeiten – die Datenbank, der Stream der Node, die API der Node – werden mit Backoff wiederholt. Sie beenden den Prozess nicht, denn ein Neustart repariert keine unerreichbare Abhängigkeit; er fügt dem Ausfall nur einen Kaltstart hinzu. Fatal bleibt, was ein Neustart *beheben* kann oder was ein Betreiber sehen muss: ungültige Konfiguration beim Start, ein nicht bindbarer Health-Endpunkt und Panics. Während eines Ausfalls läuft der Prozess weiter, meldet sich als nicht bereit und zählt Fehler. Das operative Signal lautet deshalb **„ist das seit N Minuten nicht bereit“** statt **„lebt der Prozess“** – und das ist die nützliche Frage, denn ein lebender Prozess, der seit einer Stunde nichts mehr aufnimmt, ist der eigentliche Vorfall. Auf die Signale eines Orchestrators fährt der Dienst geordnet herunter: Die Arbeit stoppt, Checkpoints werden geschrieben, und der Prozess endet sauber. Ohne das würde jedes Routine-Deployment ein nicht geschriebenes Fenster und ein Replay kosten. Eine berechnete, aber noch nicht angewendete Periode ist keine verlorene Periode. Weil die Berechnung idempotent ist und die angewendete Periode erst nach erfolgreichem Schreiben vermerkt wird, nimmt ein unterbrochener Lauf die Arbeit wieder auf, indem er das Fenster erneut rechnet, statt es zu überspringen.

Warum sich das Muster verallgemeinern lässt

Der Rückschreibpfad ist generisch. Es gibt Protokolltransaktionen zum Setzen kontobezogener und zum Setzen globaler Konfiguration, und ein Programmdienst ist jeder Prozess, der aus festgeschriebener Historie einen Wert für eine davon berechnet. Die Gebührenstufen sind der einzige laufende Dienst. Anreizprogramme, Empfehlungszuordnung und Kampagnenberechtigung hätten dieselbe Form: eine Fensterberechnung über die Handelshistorie, ein Abgleich gegen das aktuell Angewendete und ein gestapeltes Zurückschreiben. Sie gehörten hierher und nicht in den Kernel, aus demselben Grund wie die Gebührenstufen – die Berechnung ist periodisch und historisch, während die Ausführung die Antwort als Lookup in konstanter Zeit braucht. Keines davon ist gebaut; verallgemeinerbar ist das Muster, nicht die Zusage, dass sie es nutzen werden. Die kommerziellen Konditionen dieser Programme stehen unter [Gebühren & Programme](/de/programs/fees). Diese Seite handelt davon, wie das Ergebnis auf die Chain gelangt.

Wie es weitergeht

Der Stream, den diese Dienste konsumieren. Die kommerzielle Seite: welche Stufen es gibt und was sie kosten. Wie zurückgeschriebene Konfiguration bei der Ausführung gelesen wird. Warum Konfigurationsschlüssel versioniert sind und warum Clients sie live auflösen sollten.