Check TSN Network Status Before Signing

Use the TSN SDK to select reachable services and prevent an application from creating a transaction while settlement dependencies are unavailable.

Payment applications should check TSN service availability before asking a wallet to sign. The SDK checks local endpoints first and then uses configured live endpoints when a local service is unavailable.

import { getTsnNetworkStatus } from "@trustlink/tsn-sdk";

const status = await getTsnNetworkStatus({
  local: {
    node: "http://127.0.0.1:8000",
    receiver: "http://127.0.0.1:3000",
    rpc: "http://127.0.0.1:8787",
  },
  live: {
    node: process.env.TSN_NODE_URL ?? null,
    receiver: "https://tsn-receiver-kappa.vercel.app",
    rpc: "https://tsn-rpc-gateway.vercel.app",
  },
});

if (!status.readyForNativeTransactions) {
  throw new Error("Native TSN services are not ready");
}

console.log(status.selected);

The selected RPC URL is the RPC endpoint the application should pass to the SDK transaction and route helpers. In the prototype UI, the live gateway is https://tsn-rpc-gateway.vercel.app; it is used only after the local RPC probe fails, so status checks and transaction preparation use the same source.

The result reports the selected source for each service, route count, and the number of online Crankers reported by the Node. A Cranker is a worker rather than a public HTTP service, so the SDK reads its liveness from the Node’s heartbeat-backed status response. Cranker liveness is operational information, not a client-side authorization gate: a signed intent can be accepted before a Cranker claims it, and a Cranker becomes observable when it accepts or processes authorized work. If the Node has no recent worker observation, the SDK returns onlineCrankers: null. Applications should display this as “discovery on demand,” not as “offline” or “not reported.” Crankers are not located by IP address. Their public network address is not part of the application status model.

readyForNativeTransactions requires the Node, Receiver, and RPC. It is used for private TIN issuance, native TIN payments, and wallet transfers. readyForCrossChainTransactions additionally requires a registered destination route. A missing cross-chain route must not block a native TSN action.

Applications should refresh this status before preparing a payment and again before requesting a wallet signature. Status checks do not create a payment, move funds, or authorize a settlement operation.