IBC v2, often referred to by a product name “IBC Eureka”, is a simplified version of the original IBC protocol that preserves basic ordered-packet-sending functionality and reduces the complexity of the connection and channel abstractions. This simplification makes it more feasible to run IBC on the EVM/Ethereum, and the interchain folks have implemented IBC in Solidity for this purpose. IBC Eureka has been deployed on the Cosmos Hub, and transfers of assets to and from Ethereum are supported.
Broadly speaking, there are two ways in which Namada could integrate IBC v2/Eureka:
The simplest way (requiring no protocol changes) is to allow assets transferred from Ethereum to the Cosmos Hub (with IBC Eureka) to be thereafter deposited into Namada (and the MASP) via the standard IBC connection between the Cosmos Hub and Namada. This means that users would need to deposit and withdraw Ethereum assets through the Cosmos Hub, an additional step as compared to a direct connection, but it is easy to add and would also make it more difficult to censor Namada specifically (as compared to a direct connection).
Namada also has the option of implementing IBC Eureka as a protocol upgrade, which would allow Namada to connect directly to Ethereum and wherever else IBC Eureka is supported. This would require substantial engineering work – ICL has implemented IBC Eureka only in Go, as far as I am aware, so we would need to implement it in ibc-rs or similar – but, once complete, would allow for direct connections. Direct connections would reduce fees and latency, but potentially increase the risk of censorship.
Personally, my view is that we should go ahead with (1) ASAP – the only question that needs to be decided there is which Ethereum assets to support – and consider (2) in the longer-term, but probably not start engineering work until we can experiment with IBC Eureka from the product side and see what the demand looks like.
it’s great that we can get immediate access to ethereum now. potential drawback is dependency on Cosmos Hub’s uptime and policies, which i feel like could fine in the short - mid term, while we observe Eureka adoption, product demand, and how users handle and use Namada interop
Do we have any data about the Cosmos Hub demand already? Even if little demand yet, if ETH is incentivized in the MASP or stETH or other liquid staked ETH versions then there might be an important demand
Re: 1 would it be possible to create a wrapped NAM ERC-20? If so it would also allow the DAO to initiate Pool 2 rewards for WNAM-ETH LPs for example. Better yet, protocol owned liquidity where the DAO owns WNAM-ETH LP shares. Could potentially also allow WNAM to be used with the Anoma protocol adaptor for shielded swaps in Ethereum land.
Yes, creating a wrapped NAM ERC20 token should be possible (although we haven’t tested it end-to-end yet). I do not know if IBC Eureka on the Cosmos Hub supports arbitrary message-passing, though (which we’d need for Namada-controlled LP share management on Ethereum).
Option number 1 - looks good. The sooner users can use Namada service, the better)
besides, i believe сosmoshub will be one of the biggest gateways in Eureka transfers.If these assets will be supported by Osmosis, then this is another argument in favor.