> ## 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.
# Systemstatus
> Wie Sie prüfen, ob Netzwerk, Börse und Bridge normal laufen – einschließlich dessen, was Sie selbst überprüfen können, ohne auf eine Veröffentlichung zu warten.
Eine öffentliche Statusseite startet mit dem [öffentlichen Testnet am 20.09.2026](/de/protocol/roadmap/milestones). Bis dahin sind die Prüfungen unten der maßgebliche Weg, um zu sehen, was das Netzwerk tut – und sie bleiben es auch danach, weil sie die Chain lesen und nicht einen Bericht darüber.
Die Chain direkt prüfen
Das verlässlichste Signal ist keine Seite, die jemand pflegt. Es ist die Chain selbst, und sie antwortet in einer einzigen Anfrage.
Der RPC-Root einer Node gibt den aktuellen Zustand des Netzwerks zurück:
```json theme={null}
{
"chain_id": 2,
"node_role": "validator",
"block_height": "1540443",
"ledger_version": "5046975",
"epoch": "125",
"oldest_ledger_version": "0"
}
```
Rufen Sie ihn zweimal auf, im Abstand von ein paar Sekunden. **Wenn `block_height` steigt, produziert das Netzwerk Blöcke** – und weil [Matching, Clearing und Liquidation alle innerhalb der Blockausführung laufen](/de/protocol/architecture/kernel), ist ein Netzwerk, das Blöcke produziert, ein Handelsplatz, der matcht, cleart und liquidiert. Es gibt keinen separaten Börsenprozess, der ausfallen könnte, während die Chain läuft.
Das ist eine strukturelle Eigenschaft, keine Betriebszusage. An einem Handelsplatz, an dem die Matching-Engine ein Dienst neben der Chain ist, sind „die Chain läuft“ und „der Handel funktioniert“ tatsächlich zwei verschiedene Fragen. Hier sind sie dieselbe Frage.
Die Endpunkte stehen unter [Das Netzwerk heute](/de/protocol/architecture/network-status).
Was tatsächlich beeinträchtigt sein kann
Manches *kann* unabhängig ausfallen, und es lohnt sich, diese Teile namentlich zu kennen, denn jeder fällt auf eine beobachtbare Weise aus.
| Komponente | Symptom | Was weiterhin funktioniert |
| --------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------- |
| **[Indexer](/de/protocol/architecture/indexer)** | Historische Abfragen und Streams hängen zurück oder stehen | Der Handel. Orderübermittlung und Ausführung hängen nicht davon ab |
| **[Oracle](/de/protocol/architecture/oracle)** | Indexpreise werden für einen Markt nicht mehr aktualisiert | Das Buch. Mark-Preis und Funding verschlechtern sich für diesen Markt |
| **[Bridge](/de/protocol/architecture/bridge)** | Ein- oder Auszahlungen bleiben stehen | Der Handel mit dem Guthaben, das Sie bereits halten |
| **[Programmdienste](/de/protocol/architecture/programs)** | Gebührenstufen werden nicht mehr aktualisiert | Der Handel, zu Ihrem aktuell angewandten Satz |
| **Web-Frontend** | Die Website ist nicht erreichbar | Alles, über die API |
Das Muster verdient einen Namen: **Der Handelspfad hängt von keinem davon ab.** Jeder Teil sitzt entweder vor der Ausführung als Eingabe, die die Chain bereits angenommen hat, oder dahinter als Leser dessen, was die Chain festgeschrieben hat. Keine der beiden Positionen kann einen Block aufhalten.
Für eine Integration folgt daraus: „Der Indexer hängt hinterher“ und „meine Order wurde nicht ausgeführt“ sind zwei unabhängige Diagnosen, und wer sie als ein Signal behandelt, sucht an der falschen Stelle.
Die eigene Sicht prüfen
Zwei Felder in dieser RPC-Antwort beantworten Fragen, die man sonst an den Support stellt.
**`chain_id` bestätigt, auf welchem Netzwerk Sie sind.** Ein Client, der scheinbar keine Guthaben sieht, zeigt weit häufiger auf das falsche Netzwerk, als dass er eine Störung erlebt.
**`oldest_ledger_version` sagt Ihnen, wie weit zurück diese Node Historie vorhält.** Eine aggressiv geprunte Node liefert den aktuellen Zustand korrekt aus, kann historische Abfragen aber gar nicht beantworten – das sieht nach Datenverlust aus und ist keiner. Siehe [Zustandssynchronisation](/de/protocol/architecture/state/sync).
Was die Statusseite abdecken wird
Sobald sie startet, zusammen mit dem öffentlichen Testnet:
* **Komponentenstatus** für die oben genannten Bereiche, jeder einzeln gemeldet statt in einer Anzeige zusammengefasst
* **Geplante Wartung**, vorab angekündigt mit Zeitfenster und erwarteter Auswirkung
* **Störungshistorie**, die erhalten bleibt, statt nach der Behebung gelöscht zu werden
* **Live-Updates während einer Störung**
Störungen, die Ausführung, Mittel oder offene Positionen betreffen, werden zusätzlich im [Protokoll-Changelog](/de/protocol/roadmap/changelog) festgehalten, damit die dauerhafte Aufzeichnung nicht nur auf einer Statusseite liegt.
Ein Problem melden
Wenn etwas falsch aussieht und die Chain Blöcke produziert, liegt es wahrscheinlich an einem einzelnen Bereich oder an Ihrer Integration. Nennen Sie, was Sie getan haben, den Endpunkt, einen Transaktions-Hash oder eine Order-ID, sofern vorhanden, und die Blockhöhe oder den Zeitstempel.
Schicken Sie das an `contact@intention.xyz`. Vermutete Schwachstellen gehen stattdessen über den [Bug bounty](/de/protocol/security/bug-bounty)-Prozess – setzen Sie **Security** in die Betreffzeile, damit die Meldung vor gewöhnlichen Anfragen bearbeitet wird.
Wie es weitergeht
Chain-Identität, aktive Endpunkte und was Sie erwartet.
Die datierte Aufzeichnung von Releases und Störungen.
Wie Sie das Team erreichen.
APIs und wie Sie eine Integration bauen, die Ausfälle sauber verkraftet.