Diagnose stale offline signing data after a Substrate runtime upgrade

A signing workstation can remain connected to the correct chain yet use stale runtime information. Version-related signed extensions make old signing payloads unusable after some upgrades.

Compare the signer’s snapshot with the live runtime

Use the connected polkadot-js API to capture a finalized version record. Compare the genesis hash, specVersion, transactionVersion and relevant signed extensions with the saved offline request. An RPC node’s software release number is a separate identifier.

const hash = await api.rpc.chain.getFinalizedHead()
const version = await api.rpc.state.getRuntimeVersion(hash)
console.log({
  genesis: api.genesisHash.toHex(),
  spec: version.specVersion.toString(),
  transaction: version.transactionVersion.toString(),
  at: hash.toHex()
})

Rebuild the entire signing request on a mismatch

Suppose a payload was built for specVersion 120 and the live runtime reports 121. On a runtime using CheckSpecVersion, changing that value changes the implicit data verified with the signature. Editing a display field after signing cannot repair the payload. Refresh metadata, rebuild the inner call and collect a fresh signature after checking the intended arguments.

A version match only resolves this part of validation. Keep expiry, nonce and actual signature errors distinguishable in the incident record.

Sources