Current status
PR #652 implemented most of this issue for the v8 and v10 Classic profiles. The focused Caribic scenario creates a short-lived subject client and an active substitute, establishes a connection and ICS-20 channel, relays a packet, lets the subject expire naturally, advances the substitute, and submits MsgRecoverClient through the real ibc-go governance path.
The scenario then proves that the original subject client ID, connection, channel, packet state, Cosmos escrow, and voucher denomination remain unchanged. It submits the first ordinary probabilistic update after recovery and exercises both membership and non-membership through post-recovery packet and timeout flows. The accompanying Go tests cover copied and reconstructed custom state, recovery-invariant mismatches, insufficient substitute height, missing consensus metadata, and operational-certificate regression. The Injective-oriented operator runbook now documents compatibility checks, governance submission, downtime, post-recovery verification, and failure handling.
PR #655 fixed the Hermes schema and local stake-normalization problems discovered while exercising this flow.
Two narrower coverage gaps remain. The ibc-go keeper and authority enforce the active-subject, inactive-substitute, different-concrete-type, and unauthorized-signer checks, but those cases do not yet have dedicated app-level recovery fixtures. The live scenario also checks Cosmos channel escrow directly, but it does not independently locate and compare the relevant Cardano transfer-escrow shard UTxO or UTxOs across recovery.
Remaining acceptance criteria
- Add dedicated app-level negative tests for an active subject, an inactive substitute, a substitute with a different concrete client type, and an unauthorized signer.
- Run those negative cases through the corresponding v8 and v10 app APIs where they differ, and prove that rejection leaves both clients and the existing route unchanged.
- In the live recovery scenario, locate the Cardano transfer-escrow shard UTxO or UTxOs associated with the tested route and denomination.
- Record their identities, locked assets, and balances before recovery; require the same state immediately after recovery; and verify that subsequent packet and timeout operations change them only by the expected amounts.
- Retain the existing natural-expiry happy path, first normal post-recovery update, membership and non-membership checks, packet-state checks, Cosmos escrow checks, voucher-denomination checks, and operator runbook.
This issue can close once those app-level negative fixtures and explicit Cardano escrow assertions are present. Exact deployment-artifact release gating remains tracked separately by #648.
Current status
PR #652 implemented most of this issue for the v8 and v10 Classic profiles. The focused Caribic scenario creates a short-lived subject client and an active substitute, establishes a connection and ICS-20 channel, relays a packet, lets the subject expire naturally, advances the substitute, and submits MsgRecoverClient through the real ibc-go governance path.
The scenario then proves that the original subject client ID, connection, channel, packet state, Cosmos escrow, and voucher denomination remain unchanged. It submits the first ordinary probabilistic update after recovery and exercises both membership and non-membership through post-recovery packet and timeout flows. The accompanying Go tests cover copied and reconstructed custom state, recovery-invariant mismatches, insufficient substitute height, missing consensus metadata, and operational-certificate regression. The Injective-oriented operator runbook now documents compatibility checks, governance submission, downtime, post-recovery verification, and failure handling.
PR #655 fixed the Hermes schema and local stake-normalization problems discovered while exercising this flow.
Two narrower coverage gaps remain. The ibc-go keeper and authority enforce the active-subject, inactive-substitute, different-concrete-type, and unauthorized-signer checks, but those cases do not yet have dedicated app-level recovery fixtures. The live scenario also checks Cosmos channel escrow directly, but it does not independently locate and compare the relevant Cardano transfer-escrow shard UTxO or UTxOs across recovery.
Remaining acceptance criteria
This issue can close once those app-level negative fixtures and explicit Cardano escrow assertions are present. Exact deployment-artifact release gating remains tracked separately by #648.