> ## 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.
# System status
> How to check whether the network, the exchange, and the bridge are operating normally — including what you can verify yourself without waiting for anyone to publish it.
A public status page launches with the [public testnet on 20 September 2026](/protocol/roadmap/milestones). Until then, the checks below are the authoritative way to see what the network is doing — and they remain authoritative afterwards, because they read the chain rather than a report about it.
## Check the chain directly
The most reliable signal is not a page someone maintains. It is the chain itself, and it answers in one request.
The node RPC root returns the network's current state:
```json theme={null}
{
"chain_id": 2,
"node_role": "validator",
"block_height": "1540443",
"ledger_version": "5046975",
"epoch": "125",
"oldest_ledger_version": "0"
}
```
Call it twice, a few seconds apart. **If `block_height` is advancing, the network is producing blocks** — and because [matching, clearing, and liquidation all run inside block execution](/protocol/architecture/kernel), a network producing blocks is a venue that is matching, clearing, and liquidating. There is no separate exchange process that can be down while the chain is up.
That is a structural property, not an operational claim. On a venue where the matching engine is a service beside the chain, "the chain is fine" and "trading works" are genuinely different questions. Here they are the same question.
Endpoints are listed on [The network today](/protocol/architecture/network-status).
## What can actually be degraded
Some things *can* fail independently, and they are worth knowing by name, because each one fails in a way you can observe.
| Component | Symptom | What still works |
| ------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------------- |
| **[Indexer](/protocol/architecture/indexer)** | Historical queries and streams lag or stall | Trading. Order submission and execution do not depend on it |
| **[Oracle](/protocol/architecture/oracle)** | Index prices stop updating for a market | The book. Mark price and funding degrade for that market |
| **[Bridge](/protocol/architecture/bridge)** | Deposits or withdrawals stall | Trading with the balance you already hold |
| **[Program services](/protocol/architecture/programs)** | Fee tiers stop updating | Trading, at your currently applied rate |
| **Web front end** | The site is unreachable | Everything, through the API |
The pattern is worth naming: **the trading path has no dependency on any of them.** Each sits either upstream of execution as an input the chain has already accepted, or downstream as a reader of what the chain committed. Neither position can stop a block.
The consequence for an integration is that "the indexer is behind" and "my order did not execute" are unrelated diagnoses, and treating them as one signal will send you to the wrong place.
## Checking your own view
Two fields in that RPC response answer questions people usually ask support about.
**`chain_id` confirms which network you are on.** A client that seems to see no balances is far more often pointed at the wrong network than experiencing an incident.
**`oldest_ledger_version` tells you how far back this node retains history.** A node pruned aggressively serves current state correctly while being unable to answer historical queries at all — which looks like data loss and is not. See [State sync](/protocol/architecture/state/sync).
## What the status page will cover
When it launches, alongside the public testnet:
* **Component status** for the surfaces above, each reported independently rather than rolled into one indicator
* **Scheduled maintenance**, announced ahead with the window and expected impact
* **Incident history**, retained rather than cleared on resolution
* **Live incident updates** during an event
Incidents affecting execution, funds, or open positions are also recorded in the [protocol changelog](/protocol/roadmap/changelog), so the permanent record does not live only on a status page.
## Reporting a problem
If something looks wrong and the chain is producing blocks, it is likely specific to a surface or to your integration. Include what you were doing, the endpoint, a transaction hash or order ID if you have one, and the block height or timestamp.
Send it to `contact@intention.xyz`. Suspected vulnerabilities should go through the [bug bounty](/protocol/security/bug-bounty) process instead — put **Security** in the subject line so it is routed ahead of ordinary mail.
## Where to go next
Chain identity, live endpoints, and what to expect.
The dated record of releases and incidents.
Reaching the team.
APIs, and building an integration that degrades gracefully.