ヘルスチェックアルゴリズムは、ADAMANTを最も信頼性の高い暗号資産ウォレットにすることを目指しています。このアルゴリズムは、ADMおよびコインノードに加え、info-serviceやIPFSなどのサービスにも適用されます。アルゴリズムはノードの高さ（height）、最小サポートバージョンを評価し、ADMの場合は/api/node/statusなど、最も有益なエンドポイントを利用します。ユーザーによって無効化されたノードはスキップされ、ノードリストは「ログイン状態を維持」の設定とは独立してローカルに保存されます。
ノードのステータスには、ユーザーによる無効化、非サポート（バージョンまたはPWA-HTTPS経由のHTTPノードによるもの）、および利用不可（Unavailable）があります。ノードが利用できない場合、アルゴリズムはまずドメインを確認し、ドメインが失敗した場合にalt_ipをチェックします。ドメインが利用可能になると、以降はalt_ipはチェックされず、余分なリクエストを回避します。両方が利用できない場合、次のリクエストで再試行されます。
利用可能（Available）および同期中（In-sync）の検出は、ノード高さのしきい値（HEIGHT_EPSILON）に依存します。応答した唯一のノードが「利用可能」とマークされます。しきい値内にある一連のノードは「アクティブ」、しきい値外のノードは「同期中（In-sync）」または「チーター」となります。しきい値はコインごとに異なります：ADMは10、BTCは2、ETHは5、DOGEは3、DASHは3、LSKは5です。たとえば、BTCノードが815,000および815,001の場合、両方ともアクティブですが、815,010のノードは同期中となります。
初期ヘルスチェック時または接続が切断された後の再接続時、最初のノード応答が「アクティブ」ではなく「同期中」とマークされる可能性があります。完全な10秒間のチェックを待つとアプリがフリーズしてしまうため、これを回避するため、ノードの30%以上が応答した場合にのみステータスを「アクティブ」または「同期中」に更新します。それ以外の場合は、以前のステータスを維持します。これは「初期チェック」としてマークされます。以降のチェックでは、保留中のノードが古いデータで誤って「同期中」と判定されるのを防ぐため、100%のノードが応答した場合にのみステータスを更新します。
ユーザーの混乱を避けるため、「未定義」または「利用不可」ステータスのノードに対して「初期チェック中」の間は「更新中…」という視覚的なステータスが表示されます。これは、グレーのドットと抑えたテキストで表示されます。
各ヘルスチェックリクエストではPingが測定され、最もPingが小さいノードが最速とされます。「最速のノードを優先」設定は、ADMではデフォルトで「いいえ」、コインノードでは「はい」です。コインノードとインデクサーに対しては別々に動作します。
ヘルスチェックはインターネット接続ステータスとは独立して実行されます。OSが報告する「インターネット接続なし」は信頼性が低いためです。接続がない場合、結果として利用可能なノードが存在しないことになります。hasEnabledNodesおよびhasAvailableNodesの状態は、少なくとも3つのノードが応答したとき、またはチェックが完了したときに更新されます。これにより、10秒間のフリーズを回避して起動時のUXが向上します。重複するチェックは防止されており、以前はsetInterval()を使用するバグにより、アプリをバックグラウンドから復帰させた際にリクエストの嵐が発生していましたが、これは修正済みです。
ヘルスチェックは、アプリ起動時、接続復帰時、ノード画面を開いたとき、またはノードリストが更新されたときにトリガーされます。定期的な間隔（normalUpdateInterval）はノードタイプに応じて3〜8分の間で変化します。すべてのアクティブノードが失敗した場合、追加のヘルスチェックが実行されます。
HTTPリクエストを送信する際、アルゴリズムは「インターネット接続なし」ステータスを無視し、完全なヘルスチェックの完了を待ちません。最速のノードまたはランダムなアクティブノードが選択されます。リクエストがタイムアウトにより失敗した場合、次のノードを試行し、失敗したノードは「利用不可」とマークされます。404などのHTTPエラーは失敗とはみなされません。保留中のリクエストは接続復帰後に常に完了させられるため、連絡先リストの保存などの操作が中断されることはありません。