Marius Poke

> @mpoke did we decide to postpone this? We are releasing Gaia on multiple platforms. As a result, we should test for those platforms.

> @zmanian > > This code doesn't appear to contain any migration code from the original x/staking implantation unless I missed it. > > Should the migration code live here...

@sampocs > Was there no migration necessary for ICS? No as ICS didn't affect any of the existing state. ICS affects only new unbonding operations. > Where should the migration...

nit: could somebody run `make format`?

Also, are we sure we cannot get more tests passing? @alexanderbez Are any of the CI checks failing a problem?

> Ideally the client created on the provider should be done with a consensus state with same timestamp as the corresponding block on the consumer chain (genesis_time for height 1)....

I'm not that familiar with bootstrapping chains. Is there a way to set a chain's genesis time in advance, regardless of when the chain actually starts?

The current implementation guarantees the following invariant: ``` spawn_time

> i don't think initial_height in the proposal should include revision_number as this should be derived from chain_id (see same [diffs](https://gist.github.com/ancazamfir/511dd3879cfcfb8a75c17a5720169f7e#file-consumer_consensus_state-diffs)). I agree. That would simplify the UX.

> But where is consumer_client_creation_time defined, I don't see it. It's the block time on the provider when the proposal is handled, see https://github.com/cosmos/interchain-security/blob/b3533f63cf7be2df1bd3b5279d7914a72f1e4de9/x/ccv/provider/keeper/proposal.go#L89