Why
`waitForInclusion` polls `GET /v1/ledger/txs/{hash}` every 500ms. It works, but it's a chatty round-trip per tx, and the chain already has a WebSocket subscription endpoint. WS would give first-byte latency closer to the chain's actual indexing cadence (typically ~100ms once a slot finalises).
What
`waitForInclusionWS(client, txHash, options)` that opens a WebSocket subscription on the chain's `/ws` endpoint and resolves on the first `tx_processed` event for the given hash.
Keep `waitForInclusion` (HTTP polling) as the default — it's the more robust path for browsers behind weird proxies, edge runtimes that don't speak WS, or polling-only environments.
Blockers
- `ligate-chain#245`: the Rust SDK's `subscribe_to_tx_status_updates` has a URL-parser bug ("invalid port value") that blocked us from using WS in cli/faucet. The TS path uses native browser `WebSocket`, which doesn't have the same bug, but until the chain confirms the WS handler itself is solid in the JS path I'd rather not ship a feature that hits a buggy code path.
Out of scope
- Pub/sub for arbitrary events: bigger surface, defer.
- Reconnection / backoff: do it once we have a real consumer.
Why
`waitForInclusion` polls `GET /v1/ledger/txs/{hash}` every 500ms. It works, but it's a chatty round-trip per tx, and the chain already has a WebSocket subscription endpoint. WS would give first-byte latency closer to the chain's actual indexing cadence (typically ~100ms once a slot finalises).
What
`waitForInclusionWS(client, txHash, options)` that opens a WebSocket subscription on the chain's `/ws` endpoint and resolves on the first `tx_processed` event for the given hash.
Keep `waitForInclusion` (HTTP polling) as the default — it's the more robust path for browsers behind weird proxies, edge runtimes that don't speak WS, or polling-only environments.
Blockers
Out of scope