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.
Option 2. While option 1 is easier short term, it fails to account for the migration pain of asset unwinding if there is demand.
Either approach (1 or 2), will likely be the last one if there is demand. The question should be “Is Namada happy with Hub lock-in indefinitely, or should we own the distribution channel to one of the largest markets in the ecosystem?”
Proper research into what users want, if anything, should be conducted first instead of engineering here (even option 1). I’m not sure what the privacy market looks like in the Ethereum ecosystem, they might not be interested in Namada anyways.
3 larger teams I have talked with are actively avoiding IBCv2 integration through the hub for a variety of factors. CosmosHub has continued to be one of the most confusing networks in the market. The level of risk to put dependency on them in a time of uncertainty & change is unwise for the protocol.
Namada should own its distribution sovereignty. If I’m moving my ETH → Namada, I don’t also want to leak my Cosmos information or have to pay ATOM as a year (unless they are doing some PacketForward with IBCv2 packets).
Maybe Namada should wait given the technical rust requirements. If it’s not worth the engineering time there, is it worth it at all
Thanks @Reecepbcups and @dismad for the thoughts here - I definitely agree that we want to own our distribution channels. Still, it’s not clear what the demand for IBC Eureka would be, and I think it’s best for us to get some sense of that before committing (too much) development time. Luckily, options (1) and (2) aren’t mutually exclusive – we can enable (1) with basically zero engineering work, collect some data, and plan to do (2) in the future if the demand is there.
