Feature: Forward bridge traffic to IBC Channel

[jackzampolin]

[zmanian]

there is cool.

Questions I have are

1. Are we minting and escrowing the coins on the Cosmos side of the bridge or something else?

2. I can imagine extending the solidity contract with the send to IBC event that takes a channel directly from the eth transaction and pushes the coins over it. This allows us to preserve putting the routing tables in the client layer rather than having an unchain governance controlled routing table.

[zmanian]

Just documenting that this is timeout event handling to return funds back to the user on ethereum.

"I think we could build in some error handling where if the IBC packet times out we would send the funds back to ETH" - @jackzampolin

[jackzampolin]

1. Are we minting and escrowing the coins on the Cosmos side of the bridge or something else?

Yes this would be the plan. Zone running gravity would mint the tokens the exact same way but instead of depositing the to desired user account it would create an IBC packet with those coins.

2. I can imagine extending the solidity contract with the send to IBC event that takes a channel directly from the eth transaction and pushes the coins over it. This allows us to preserve putting the routing tables in the client layer rather than having an unchain governance controlled routing table.

Yup! I've actually added that in this PR too

[zmanian]

I feel like SendToIBCChannel should have a CosmosAddress on the gravity chain where tokens on timedout IBC packets can be sent too.

Otherwise we have a more expensive process of making a batch to send the tokens back to the eth address.

[jackzampolin]

@zmanian ETH contract emits final destination. Orchestrator parses final destination into same address w/ different prefix on both gravity and final destination chain. When event gets submitted to cosmos chain it contains both representations. IBC packets will look like this:

{
  "sending_address": "cosmos1vzxkv3lxccnttr9rs0002s93sgw72h7ghukuhs",
  "reciveing_address": "osmo1vzxkv3lxccnttr9rs0002s93sgw72h7gl89vpz"
}

[zmanian]

makes sense

[jackzampolin]

still need to pass transfer keeper into gravity keeper

[zmanian]

In the existing SendToCosmos method, the address is encoded without the bech32 prefix and the orchestrator is configured with the correct prefixes and adds them when sending them as cosmos transactions.

Am I correct that this won't work unless we include the bech32 encoding for all the addresses?

[zmanian]

Switching to bech32 bytes seems doable.

[jackzampolin]

So RE: bech32. What I'm thinking here is that the eth transaction has the bech32 encoding for the final destination. This way the orchestrator can send that w/o having to know the prefix apriori. It can then parse that representation into bytes and also render it as the proper prefix for the gravity chain in order to set the refund address in the case that the packet fails

[EricBolten]

Looking through old PRs and this one has been sitting for almost a year. Should we plan on picking this back up or close?

[cbrit]

Closing due to staleness