> ## 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.
# Estado del sistema
> Cómo comprobar si la red, el exchange y el puente funcionan con normalidad — incluido lo que puedes comprobar tú mismo sin esperar a que nadie lo publique.
La página pública de estado se lanza con la [testnet pública el 20 de septiembre de 2026](/es/protocol/roadmap/milestones). Hasta entonces, las comprobaciones de abajo son la referencia para ver qué está haciendo la red, y lo siguen siendo después, porque leen la cadena y no un informe sobre ella.
Comprueba la cadena directamente
La señal más fiable no es una página que alguien mantiene. Es la propia cadena, y responde en una sola solicitud.
La raíz RPC del nodo devuelve el estado actual de la red:
```json theme={null}
{
"chain_id": 2,
"node_role": "validator",
"block_height": "1540443",
"ledger_version": "5046975",
"epoch": "125",
"oldest_ledger_version": "0"
}
```
Llámala dos veces, con unos segundos de diferencia. **Si `block_height` avanza, la red está produciendo bloques**; y como [la casación, la compensación y la liquidación ocurren todas dentro de la ejecución del bloque](/es/protocol/architecture/kernel), una red que produce bloques es una plataforma que está casando, compensando y liquidando. No hay un proceso de exchange aparte que pueda estar caído mientras la cadena funciona.
Es una propiedad estructural, no una afirmación operativa. En una plataforma donde el motor de casación es un servicio junto a la cadena, “la cadena está bien” y “se puede operar” son preguntas genuinamente distintas. Aquí son la misma pregunta.
Los endpoints están listados en [La red hoy](/es/protocol/architecture/network-status).
Qué puede degradarse de verdad
Algunas cosas *sí* pueden fallar de forma independiente, y merece la pena conocerlas por su nombre, porque cada una falla de una manera que puedes observar.
| Componente | Síntoma | Qué sigue funcionando |
| --------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------- |
| **[Indexador](/es/protocol/architecture/indexer)** | Las consultas históricas y los flujos se retrasan o se paran | El trading. El envío y la ejecución de órdenes no dependen de él |
| **[Oráculo](/es/protocol/architecture/oracle)** | Los precios índice dejan de actualizarse en un mercado | El libro. El precio de marca y la financiación se degradan en ese mercado |
| **[Puente](/es/protocol/architecture/bridge)** | Los depósitos o los retiros se paran | Operar con el saldo que ya tienes |
| **[Servicios de programa](/es/protocol/architecture/programs)** | Los niveles de comisiones dejan de actualizarse | El trading, con la comisión que tengas aplicada |
| **Front-end web** | El sitio no es accesible | Todo, a través de la API |
Merece la pena nombrar el patrón: **la ruta de trading no depende de ninguno de ellos.** Cada uno se sitúa o bien aguas arriba de la ejecución, como una entrada que la cadena ya aceptó, o bien aguas abajo, como lector de lo que la cadena confirmó. Ninguna de las dos posiciones puede detener un bloque.
La consecuencia para una integración es que “el indexador va atrasado” y “mi orden no se ejecutó” son diagnósticos sin relación, y tratarlos como una sola señal te llevará al sitio equivocado.
Comprobar tu propia vista
Dos campos de esa respuesta RPC responden preguntas que la gente suele llevar a soporte.
**`chain_id` confirma en qué red estás.** Un cliente que parece no ver saldos está apuntando a la red equivocada mucho más a menudo de lo que está sufriendo un incidente.
**`oldest_ledger_version` te dice hasta dónde atrás conserva historia este nodo.** Un nodo podado de forma agresiva sirve correctamente el estado actual y a la vez es incapaz de responder consultas históricas: parece pérdida de datos y no lo es. Consulta [Sincronización de estado](/es/protocol/architecture/state/sync).
Qué cubrirá la página de estado
Cuando se lance, junto con la testnet pública:
* **El estado de cada componente** de las superficies de arriba, publicado por separado en vez de refundido en un solo indicador
* **El mantenimiento programado**, anunciado con antelación, con la ventana y el impacto esperado
* **El historial de incidentes**, conservado en vez de borrarse al resolverse
* **Actualizaciones en vivo del incidente** mientras dure
Los incidentes que afectan a la ejecución, a los fondos o a las posiciones abiertas se registran además en el [registro de cambios del protocolo](/es/protocol/roadmap/changelog), para que el registro permanente no viva solo en una página de estado.
Cómo informar de un problema
Si algo parece mal y la cadena está produciendo bloques, lo más probable es que sea específico de una superficie o de tu integración. Incluye qué estabas haciendo, el endpoint, un hash de transacción o un ID de orden si lo tienes, y la altura de bloque o la marca de tiempo.
Envíalo a `contact@intention.xyz`. Las vulnerabilidades que sospeches deben ir por el proceso de [bug bounty](/es/protocol/security/bug-bounty): pon **Security** en el asunto para que se encamine por delante del correo ordinario.
Qué leer a continuación
Identidad de la cadena, endpoints en vivo y qué esperar.
El registro fechado de versiones e incidentes.
Cómo contactar con el equipo.
Las APIs, y cómo construir una integración que degrade con elegancia.