Aditya

Definitely the events relayers should expect need to be part of the spec. Otherwise relayers will have to implement different parsing logic for each implementation. We should standardize on the...

This spec is quite complicated. The main issues I see are the following: 1. A connection is identified differently on both sides (this is an unavoidable property of IBC) 2....

cc: @cwgoes @colin-axner @brapse

I kind of wonder why we even need this feature. Can the CNS just say this client is the canonical client between say `Hub->Osmosis` and just store that on-chain? Most...

This proposal looks great. Would love to see it prototyped to ensure that we don't run into unexpected build issues. Perhaps after we get consensus on the approach from rest...

> Just a clarification: we copy over only [the consensus state at the latest height of the substitute client](https://github.com/cosmos/ibc-go/blob/6c8c50c5fdc0d7fd0f74ca9d463a0f04c0f0cddc/modules/light-clients/07-tendermint/proposal_handle.go#L56), right? Correct, yes thanks for the clarification. At the end, we...

Happy to see the changes are clean and minimal!

Thanks @ValarDragon for the detailed writeup!! It seems to me that this proposal would change some IBC guarantees. This proposal feels very clean in the happy case. I'm a bit...

> Then a single relayer would responsible for the entire happy path and payment could encompass that entire flow. Timeout, however, should be permissionless. A single relayer still could. However,...

Note TODO, I need one more handshake message here, and I need to ensure both sides have the counterparty channel store Identifier and has verified this field on the other...