Ready for review as a draft. Specific functions for calculating valid datagrams will need to be defined in individual ICSs as mentioned. Possibly this ICS could include more detail about relayer incentivization later, but I think that design discussion would be too early now (it doesn't seem particularly difficult, and is unlikely to require low-level protocol changes).

I suggest reviewing the rendered Markdown.

My understanding is that these will be part of separate ICSs.

Yes, that's right. I think that makes more sense because chains are likely to implement subsets of the IBC protocol - that way relayers can compose pendingDatagrams based on which ICSs the chain implements.

Question: Do we need to creation some notion of an ID for each datagram.

The relayer algorithm would then be expected to insert any detected datagram if the id wasn't already in the mempool.

Question: Do we need to creation some notion of an ID for each datagram.

The relayer algorithm would then be expected to insert any detected datagram if the id wasn't already in the mempool.

This is expected to be included in pendingDatagrams (which can read the state of the ledger).

I think usually we will (certainly for packets), but occasionally other state will be sufficient (connection state, for example, in the connection handshake).

Questions I have so far:

• do relayers programmed to use a Hub?
• if yes, how do they choose what Hub to use?
• do they first send IBC transaction to a Hub? What if a Hub detects a double spend? How it can signal the relayer that IBC transaction is malicious?

@melekes I don't think any of the current IBC specifications talk about "Hubs" yet - that's a distinction at the level of expected network dynamics (for now), not a distinction at the protocol layer.

There's some discussion in progress at #59.

Merging to the "draft" stage, further comments always welcome.