Check a HILSA read or settlement route

Use this task before integrating a particular foreign-state read or external settlement route. You will record which prerequisites are established and which still block the route. Discovering a method or chain name is the beginning of that check.

Starting point: an intended Singularity endpoint, the foreign chain you need, and your application's required verification/finality policy. You need curl and permission to make read-only requests. You do not need a wallet or funds. For the concepts behind the policy, read HILSA verified reads; keep the interface reference available for exact fields.

Establish the endpoint and deployment

Set the intended endpoint. The URL here is the SDK's public default, not a promise of availability.

RPC=https://rpc.entropytoorder.xyz
probe() {
  curl --silent --show-error --max-time 15 "$RPC" \
    -H 'content-type: application/json' --data "$1"
}
probe '{"jsonrpc":"2.0","id":1,"method":"getHealth","params":[]}'
probe '{"jsonrpc":"2.0","id":2,"method":"getVersion","params":[]}'
probe '{"jsonrpc":"2.0","id":3,"method":"getGenesisHash","params":[]}'

Read each JSON body. Record the endpoint, UTC time, reported build/version and genesis identity. Check that identity against the intended network's published configuration. HTTP success alone does not establish a healthy node; getHealth must return "result":"ok" before relying on this endpoint for a live workflow.

At 2026-09-08 01:44 UTC, all seven probes used in this task returned JSON-RPC error -32000 with message Upstream error (HTTP 521). Endpoint identity, current evidence and settlement readiness therefore remained unverified. This is a completed diagnostic outcome: record the upstream availability blocker and stop dependent integration work. It is not a positive HILSA-route test.

The availability record preserves earlier observations separately. An older connected service or safety-pause response must not be substituted for a current successful probe.

Discover the foreign chain's HILSA identity

When the intended endpoint responds normally, request its catalog:

probe '{"jsonrpc":"2.0","id":4,"method":"hilsa_chainCatalog","params":{}}'

Find the entry matching the chain's name and CAIP-2 identity. Record its HILSA id, family, phase and class_ceiling. HILSA IDs are not EIP-155 chain IDs. The earlier catalog identified Ethereum as HILSA ID 2; verify the actual entry before using this example:

probe '{"jsonrpc":"2.0","id":5,"method":"hilsa_chainHead","params":{"chain":2}}'

The catalog describes intended capability. The head reads the committed chain-state account and reports the actual verification class used for that head. head:null means there is no accepted head to use; connected:true with a null head would only establish that persisted chain state exists. An invalid owner or malformed persisted account produces an error. Catalog contract, head lookup.

Record the height, hash/commitment and actual class if present. Determine the matching artifact producer, anchor/registry and finality policy before trusting that class. The head response alone does not establish your application's complete freshness/finality policy.

Separate feed diagnostics from accepted evidence

probe '{"jsonrpc":"2.0","id":6,"method":"hilsa_feedStatus","params":{"recent":4}}'

Use feed status to investigate observer/transport activity. It is process-local diagnostic information; an assembled quorum or recent transport event is not proof that consensus committed its artifact. Empty status is also not a substitute for inspecting the committed head. Feed-status handler.

For a contract read, establish the exact VM ABI and query type, an installed handler, committed input and the requested minimum verification/finality classes. Reads in block H use the H - 1 committed snapshot. Establish acceptable age for the application separately; one local snapshot does not imply synchronized foreign-chain clocks. See committed read interfaces.

For a caller-supplied account/storage proof, check the supported hilsa_proveRead chain/root profile, obtain the proof and required header material, and test positive and negative proof cases through that endpoint. The node does not fetch the foreign proof for you, and a valid trie branch does not upgrade the admitted head's trust class. This task does not manufacture a positive proof from a catalog entry.

Check the additional settlement boundary

For a route requiring a quorum certificate, this read-only probe requests the newest retained BLS quorum attestation:

probe '{"jsonrpc":"2.0","id":7,"method":"hilsa_getAttestation","params":{"quorum":true}}'

A response still needs its actual scheme, stake/bitmap, trusted validator-set epoch and destination verifier checked. For a particular message, its proof and certificate must bind the same root and block; “latest” alone is not enough. See certificate contracts.

Earlier checks at 00:19 UTC returned deployment-specific -32012, describing a protocol-v8 durable-interop safety pause. Do not disable verification or choose a weaker class to get around such a gate. The later HTTP 521 result establishes a different, earlier availability failure.

A settlement route also needs enabled local admission/outbox machinery, the actual destination contract and configured authority, a working delivery path, replay protection, and a verifiable destination effect. An emitted event at the general gateway is not arbitrary destination application execution. The writes and settlement explanation distinguishes the general gateway from an asset vault unlock.

Record a route verdict

Complete the task by recording the route, policy, dated responses and each unresolved prerequisite. A usable-route claim needs the relevant positive and rejection tests; the diagnostic probes here do not establish it on their own. The current execution evidence covers read-only failure responses, with no HILSA transaction, bridge transfer or production mutation.