was looking into the Cosmos IBC contracts deployed on Ethereum and found something interesting about how their ZK light clients are managed. the SP1 proofs verify Cosmos consensus, but the light client implementation itself can still be migrated through governance. they actually used this during the June upgrade to move the Tendermint clients to SP1 v6.1. the current setup uses an OpenZeppelin AccessManager, a 4-of-7 governance Safe and a 72 hour timelock. so even though the consensus verification is cryptographic, the system still has an administrative trust layer. and I think that's worth understanding. if someone can change which light client implementation the router trusts, then the security of the whole system also depends on who controls that permission. not saying there's a vulnerability here. the migration mechanism is intentional and useful for upgrades and recovery. but I want to understand what happens if the governance keys are compromised, whether every sensitive change really goes through the timelock, and how users can verify an upgrade before it happens. source: https://t.co/dnN5drqJMi