公開のステータスページは2026年9月20日のパブリックテストネットと同時に公開します。それまでは、以下の確認方法がネットワークの状況を知る正式な手段です。公開後も正式な手段であり続けます。報告ではなくチェーンそのものを読むからです。
チェーンを直接確認する
最も信頼できる情報は、誰かが保守しているページではありません。チェーンそのものであり、リクエスト1回で答えが返ります。 ノードのRPCルートは、ネットワークの現在の状態を返します。block_heightが進んでいれば、ネットワークはブロックを生成しています。マッチング、クリアリング、強制決済はすべてブロック実行の内部で走るため、ブロックを生成しているネットワークとは、マッチングし、クリアリングし、強制決済している取引所そのものです。チェーンが動いている一方で停止しうるような、別立ての取引所プロセスは存在しません。
これは運用上の主張ではなく、構造上の性質です。マッチングエンジンがチェーンの横のサービスとして動く取引所では、「チェーンは正常だ」と「取引ができる」は本当に別の問いです。ここでは同じ問いです。
エンドポイントは現在のネットワークに掲載しています。
実際に劣化しうるもの
独立して障害を起こしうるものはあります。それぞれ観測できる形で壊れるので、名前で把握しておく価値があります。
この共通点には名前をつける価値があります。取引の経路は、これらのいずれにも依存していません。それぞれは、チェーンがすでに受理した入力として実行の上流にあるか、チェーンがコミットした内容の読み手として下流にあります。どちらの位置からも、ブロックを止めることはできません。
統合する側にとっての帰結は、「インデクサーが遅れている」と「注文が執行されなかった」が無関係な診断だということです。これらを1つの兆候として扱えば、見当違いの場所を探すことになります。
自分の側の状態を確認する
そのRPCレスポンスの2つのフィールドが、ふだんサポートに寄せられる質問に答えます。chain_idは、どのネットワークに接続しているかを示します。残高がまったく見えないクライアントは、障害に遭っているよりも、誤ったネットワークを向いていることのほうがはるかに多いです。
oldest_ledger_versionは、そのノードがどこまで遡って履歴を保持しているかを示します。強く剪定されたノードは、現在の状態は正しく返しながら、履歴クエリにはまったく答えられません。データの消失のように見えますが、そうではありません。ステート同期を参照してください。
ステータスページで扱う内容
パブリックテストネットと同時に公開したあとは、次の内容を掲載します。- 構成要素ごとのステータス。上記の各構成要素を、1つの指標にまとめず個別に報告する
- 計画メンテナンス。実施時間帯と想定される影響を添えて事前に告知する
- 障害の履歴。解消時に消さず、残す
- 障害発生中の逐次更新
問題を報告する
何かがおかしく見えて、なおチェーンがブロックを生成している場合、原因は特定の構成要素か、自分の統合にある可能性が高くなります。何をしていたか、エンドポイント、あればトランザクションハッシュまたは注文ID、ブロック高またはタイムスタンプを記載してください。 送り先はcontact@intention.xyzです。脆弱性の疑いがある場合は、代わりにバグバウンティの手続きを使ってください。件名にSecurityと記載すると、通常のメールより優先して振り分けられます。
次に読む
現在のネットワーク
チェーンの識別情報、稼働中のエンドポイント、想定しておくべきことです。
プロトコル変更履歴
リリースと障害の、日付付きの記録です。
サポートへの問い合わせ
チームへの連絡方法です。
開発者
APIと、緩やかに機能低下する統合の作り方です。