Aditya

> Trying to summarize again... > > * All fee escrow/payment logic is done in the source chain - this is implementation specific but does not need to be in...

> If so, I see two potential ways to do this: > > 1. every ICS application spec will need to pass this field in their app-specific acknowledgement messages. This...

> There were a few elements that I didn't understand, but this largely matches the approach I was considering. I'll post a few things separately to then try to clarify...

> I would expect that, in a send/ack pair, the destination chain would tip the send and the source chain would tip the ack. In the simplest case, they have...

> > chain B recv_packet handler stores the pay_to along with the ack bytes (when write ack happens) > > This is the key change and what affects the payloads...

> I guess we don't look into the validator set anymore; but I have to think about this again in the context of fork detection. However, the Nextvalidators will will...

Note: We already need need the current `ValidatorSet` for `Header` verification

We don't use the validator set of height `h`, we just check that `h+1` validator set hashes to `h` NextValidatorsHash https://github.com/tendermint/tendermint/blob/v0.33.4/lite2/verifier.go#L122

IBC core does not enforce anything about the chainID because the `chainID` is not a concept used at all within IBC core. All of the requirements on chainID are only...

I'm in support of this. Why is the 180 bytes limit necessary or beneficial?