公开状态页将随2026 年 9 月 20 日的公开测试网一同上线。在那之前，下面这些检查是了解网络状况的权威方式——而且在那之后它们依然权威，因为它们读的是链本身，而不是关于链的一份报告。
直接检查链
最可靠的信号不是某个人维护的页面，而是链本身，而且它一次请求就能回答。 节点 RPC 根路径返回网络的当前状态：block_height 在增长，网络就在出块——而撮合、清算和强制平仓都跑在区块执行内部，所以网络在出块，就说明这个交易场所正在撮合、清算和强平。这里没有一个独立的交易所进程，能在链好好的时候单独宕掉。
这是结构决定的，不是运维层面的说法。撮合引擎跑在链旁边的场所，“链没问题”和“能交易”确实是两个不同的问题。在这里，它们是同一个问题。
端点列在网络现状。
真正可能降级的部分
有些东西确实可能独立出故障，值得逐个点名，因为每一个失效的方式你都能观察到。
有一条规律值得点明：交易路径不依赖其中任何一个。 它们要么在执行的上游，是链已经接受的输入；要么在下游，只是读取链已经提交的东西。这两个位置都拦不住一个区块。
这对集成的意义是：“索引器落后了”和“我的订单没执行”是两种互不相干的诊断，当成同一个信号看，只会让你查错方向。
检查你自己这一侧
那份 RPC 响应里有两个字段，能回答人们通常来问客服的问题。chain_id 确认你连的是哪个网络。 客户端看起来一个余额都查不到，多半是网络指错了，而不是真出了故障。
oldest_ledger_version 告诉你这个节点保留了多久的历史。 剪枝很激进的节点，当前状态照样给得对，历史查询却根本答不了——看着像数据丢失，其实不是。见状态同步。
状态页将包含什么
上线时，与公开测试网同步：- 上述各个面的组件状态，各自独立报告，而不是揉成一个总指示灯
- 计划内维护，提前公告，写明窗口和预期影响
- 事故历史，保留而不在解决后清除
- 事件期间的实时事故更新
报告问题
如果有什么看起来不对，而链仍在出块，那问题多半局限在某个具体的面或你的集成上。请说明你当时在做什么、用的哪个端点、如果有的话附上交易哈希或订单 ID，以及区块高度或时间戳。 发送至contact@intention.xyz。疑似漏洞请改走漏洞赏金流程——在主题行写上 Security，以便优先于普通邮件被处理。
后续阅读
网络现状
链标识、可用端点，以及可以预期什么。
协议变更日志
发布与事故的带日期记录。
联系我们
与团队取得联系。
开发者
API，以及如何构建一个能优雅降级的集成。