VersionCoherence
Pre-flight check that the client's bundled ledger version is coherent with the node it's talking to.
Why this exists. The client links a fixed midnight-ledger (its op encoding + cost model). When the node runs a different ledger, ops can mis-decode and the node rejects the tx with an opaque Custom error: N (e.g. 138) — a class of failure that's near-impossible to debug from the tx-build code. A version comparison up front turns that silent failure into a named, actionable warning.
Why it WARNS instead of hard-failing. The published support matrix is known to LAG the live node: a node may validate fine with 8.0.2 while the matrix (and our bundled string) say 8.0.3. Strict equality would false-positive and block a perfectly working node. So the policy is an allowlist of known-compatible node spec versions + a loud warning on anything outside it — never a hard block. The single decision point lives in evaluate; flip HARD_FAIL_ON_SKEW to change it.
Types
Properties
The client's bundled midnight-ledger version, from the native FFI (kuira_ledger_version). Falls back to a compile-time constant if the native call is unavailable (so the check still produces a sensible message rather than throwing during a pre-flight).
THE decision point. With the support matrix known to lag the live node, a version skew is a WARNING by default — loud (logged + surfaced to the caller) but non-blocking. A human can flip this to make a skew fatal once the matrix is trustworthy. Documented as a single, obvious switch so the policy is easy to find and change.
Node runtime specVersions we've validated the bundled ledger against. The node's Substrate runtime version doesn't carry the ledger semver directly, so we gate on specVersion — the monotonic counter the runtime bumps on a ledger-affecting upgrade. Outside this set we WARN (the matrix lags reality), we do not block.
Functions
Compare the node runtime to the clientLedgerVersion and classify coherence.