> ## 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.
# Regeländerungen
> Wie sich Handelsregeln, Risikoparameter und Protokollverhalten ändern: Ankündigungsfristen, Blockhöhen des Inkrafttretens und warum die Regeln eines vergangenen Blocks nie umgeschrieben werden können.
Drei Arten von Änderungen erreichen ein laufendes Netzwerk: **Parameteränderungen** (ein Risikolimit, eine Gebührenstaffel, eine Funding-Obergrenze), **Verhaltensänderungen** (wie die Ausführung selbst funktioniert) und **Marktänderungen** ([Listings und Delistings](/de/programs/listings)).
Sie unterscheiden sich darin, wie sie angekündigt werden. Sie teilen eine Eigenschaft, und auf die kommt es an: Eine Änderung wird an einem **bestimmten Punkt in der Historie der Chain** wirksam, und die Historie vor diesem Punkt bleibt unberührt.
Parameteränderungen
Risikoparameter, Hebelstufen, Funding-Obergrenzen, Positionslimits und Gebührenstaffeln sind On-Chain-Konfiguration. Eine Änderung daran ist eine Protokolltransaktion, die in einem Block ausgeführt wird, an der Spitze der [Blockpriorität](/de/trading/tx-sequencing).
Weil der Wert Chain-Zustand ist, ist die Änderung beobachtbar und nicht bloß gemeldet. Man muss Ihnen nicht mitteilen, dass sich die Maintenance Margin eines Marktes bewegt hat – Sie können lesen, wie sie ist, und Sie können lesen, wie sie in jedem vergangenen Block war.
Konfigurationsschlüssel sind außerdem **versioniert**. Ändert sich nicht die Zahl eines Werts, sondern seine Form, wird die neue Form unter einem neuen Schlüssel geschrieben, und der alte bleibt lesbar. Ein Client, der die Konfiguration live auflöst, arbeitet über die Änderung hinweg weiter; ein Client mit fest verdrahtetem Schlüsselpfad merkt es sofort, statt still etwas Veraltetes zu lesen. Siehe [Zustandsmodell](/de/protocol/architecture/state/model).
Verhaltensänderungen
Eine Änderung am *Verhalten* der Ausführung ist schwieriger als eine Änderung an einer Zahl, denn jeder Validator muss sie im exakt selben Moment vollziehen. Eine Änderung, die auf verschiedenen Nodes zu verschiedenen Zeiten landet, ist kein Rollout – sie ist ein Fork.
Intention löst das mit **On-Chain-Gates**. Jedes Gate ist ein Zustandsschlüssel, der eine Blockhöhe enthält: die Höhe, ab der das neue Verhalten beginnt.
Neues Verhalten inaktivim Binary, nicht aktiv
Ein Gate wird geschriebenein Zustandsschlüssel mit künftiger Blockhöhe
Jeder Validator liest dieselbe Höhe
Verhalten ändert sich genau in diesem Block
Die Höhe muss in der Zukunft liegenEin Gate kann nicht auf eine bereits vergangene Höhe gesetzt werden. Erst diese eine Regel macht die Änderung gleichzeitig.
Fehlendes Gate heißt inaktivEine Node im Replay liest auf diesen Höhen keinen Schlüssel und nimmt den alten Pfad – korrekt ohne Kompatibilitätsmatrix.
Auf der ausgeführten Version gelesenNie aus einem Cache. Ein aktueller Wert beim Replay eines alten Blocks würde heutige Regeln auf gestrige Historie anwenden.
Daraus folgen drei Eigenschaften, und jede davon ist tragend:
**Die Höhe muss beim Schreiben in der Zukunft liegen.** Ein Gate kann nicht auf eine bereits vergangene Höhe gesetzt werden. Erst diese Regel sorgt dafür, dass die Änderung überall gleichzeitig greift – jeder Validator erreicht diesen Block mit demselben, bereits sichtbaren Schlüssel.
**Ein fehlendes Gate bedeutet inaktiv.** Eine Node, die Historie erneut ausführt, liest auf diesen Höhen keinen Schlüssel und nimmt exakt den alten Codepfad. Das Replay der Historie bleibt damit von selbst korrekt, ohne dass jemand eine Kompatibilitätsmatrix pflegen müsste.
**Das Gate wird auf der gerade ausgeführten Version gelesen, nie aus einem Cache.** Würde beim erneuten Ausführen eines alten Blocks der aktuelle Wert gelesen, gälten die heutigen Regeln für die Historie von gestern – und der State-Root fiele anders aus. Der Wert wird deshalb immer aus der Ausführungssicht des gerade ausgeführten Blocks gelesen.
Derselbe Mechanismus ermöglicht die schrittweise Aktivierung: Ein Flag kann inaktiv eingeführt, gegen realen Traffic geprüft und auf einer geplanten Höhe eingeschaltet werden – statt als Alles-auf-einmal-Upgrade eines Binaries ausgeliefert zu werden.
Ankündigungsfristen
Die Vorlaufzeit richtet sich danach, was eine Änderung an einer Position bewirken kann, die Sie bereits halten.
| Änderung | Ankündigung |
| ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **Betrifft offene Positionen** – Margin-Anforderungen, Hebelstufen, Funding-Obergrenzen, Delistings | Wird vor dem Wirksamkeitsdatum angekündigt, mit Nennung des Datums |
| **Betrifft Integrationen** – API-Oberfläche, Nachrichtenformate, Schlüssellayouts | Wird vorab angekündigt, mit einem Migrationspfad |
| **Betrifft nur die Kosten** – Gebührenstaffeln, Rebate-Stufen | Wird vor dem Wirksamkeitsdatum angekündigt |
| **Korrigiert ein akutes Risiko** – ein Parameter, der als Reaktion auf eine Marktlage verschärft wird | Kann sofort wirksam werden |
Die letzte Zeile ist eine echte Ausnahme, kein Schlupfloch. Ein Positionslimit, das eine Woche warten muss, um verschärft zu werden, ist ein Positionslimit, das genau in der Woche nichts tut, in der es gebraucht wurde. Wird davon Gebrauch gemacht, werden die Änderung und ihr Grund mitveröffentlicht.
Eine Änderung der Margin-Anforderungen oder der Hebelstufen verändert Ihren Liquidationspreis bei Positionen, die Sie bereits halten. Sie stellt nichts glatt, und sie warnt Sie nicht persönlich. Wenn Sie Positionen über eine angekündigte Änderung der Risikoparameter hinweg halten, rechnen Sie Ihren Abstand zur Liquidation gegen die neuen Werte nach, nicht gegen die, die bei der Eröffnung galten. Siehe [Hebel](/de/trading/leverage).
Was sich nicht ändern kann
Die Regeln, die für einen bereits festgeschriebenen Block galten.
Jede Regeländerung wird auf einer Höhe wirksam, die beim Aufzeichnen in der Zukunft lag; das erneute Ausführen eines alten Blocks wendet deshalb immer die damals aktiven Regeln an. Ob eine bestimmte Regel auf einer vergangenen Version in Kraft war, ist eine Frage mit genau einer Antwort – und die ist heute dieselbe wie in einem Jahr.
Das ist eine stärkere Garantie als eine veröffentlichte Richtlinie. Es geht nicht darum, dass das Protokoll die Historie *nicht umschreiben will* – der Mechanismus hat schlicht keine Darstellung für eine Regel, die in der Vergangenheit begonnen hat. Siehe [Zustandsmodell](/de/protocol/architecture/state/model).
Ankündigungen
Die Ankündigungszusagen auf dieser Seite gelten ab dem **öffentlichen Testnet am 20.09.2026**. Das [private Testnet](/de/protocol/architecture/network-status) ändert Parameter und Verhalten ohne Vorankündigung – es existiert, um sie einzustellen.
Sobald die Ankündigungsfristen greifen, wird jede Änderung im [Protokoll-Changelog](/de/protocol/roadmap/changelog) mit dem Datum ihres Inkrafttretens festgehalten und vor diesem Datum angekündigt, wenn die Tabelle oben es verlangt.
Maßgeblich für die Datierung eines Eintrags ist, **wann die Änderung im Netzwerk wirksam wurde**, nicht wann sie angekündigt wurde.
Wie es weitergeht
Die datierte Aufzeichnung dessen, was ausgeliefert wurde.
Marktänderungen und ihre Ankündigungsfristen.
Warum Konfigurationsschlüssel versioniert und live aufgelöst werden.
Was eine Änderung der Risikoparameter mit einer offenen Position macht.