Signaling Proposal: ODIN IBC Channel Transition


  • A YES vote means you support ODIN IBC Channel Transition, allowing ODIN to change the default channel to Channel-74 (ODIN) / Channel-20925 (Osmosis).
  • A NO vote means you don’t want ODIN to change the default Channel.
  • A NO WITH VETO vote suggests you think this proposal could harm Osmosis, and the proposers should face penalties, including the loss of their deposit.

Proposer: ODIN Development Team


This proposal seeks community approval to transition the IBC channel used for transactions between ODIN and Osmosis from the current problematic pair Channel-3 (ODIN) / Channel-258 (Osmosis) to the new, fully functional pair Channel-74 (ODIN) / Channel-20925 (Osmosis). This transition addresses persistent transactional issues post-hard fork, ensuring seamless asset transfers and safeguarding user funds.

Background and Justification

Following the ODIN network’s hard fork, transactions from ODIN to Osmosis via Channel-3/Channel-258 have faced consistent failures, causing user funds to be stranded. Despite extensive troubleshooting with validators and Cosmos ecosystem experts, resolving the issues with Channel-3/Channel-258 has remained elusive.

Existing Channel Configuration (Problematic):

  • ODIN Chain ID: odin-mainnet-freya
  • Osmosis Chain ID: osmosis-1
  • ODIN Client ID: 07-tendermint-10
  • Osmosis Client ID: 07-tendermint-2007
  • ODIN Connection ID: connection-9
  • Osmosis Connection ID: connection-1551
  • ODIN Channel ID: channel-3
  • Osmosis Counterpart Channel ID: channel-258
  • Issue: Transactions from ODIN to Osmosis are unsuccessful, while transactions from Osmosis to ODIN proceed without issues.

Proposed Channel Configuration (New):

  • ODIN Chain ID: odin-mainnet-freya
  • Osmosis Chain ID: osmosis-1
  • ODIN Client ID: 07-tendermint-10
  • Osmosis Client ID: 07-tendermint-2007
  • ODIN Connection ID: connection-9
  • Osmosis Connection ID: connection-1551
  • ODIN Channel ID: channel-74
  • Osmosis Counterpart Channel ID: channel-20925
  • Validation: This new channel configuration has been rigorously tested and confirmed to support bidirectional transactions effectively.

Brief background about the tech steps taken

The issue under discussion arises from a sequence of events triggered by a hard fork on the Odin network, which led to a transition from IBC version 3 to version 7. This upgrade has precipitated a complex situation where transactions from Odin to Osmosis are not being finalized as anticipated, creating a state of limbo for these transactions. The essence of the problem, as gleaned from the technical dialogue, revolves around packet commitments and acknowledgments within the IBC protocol framework.

Here’s a technical breakdown:

  1. Pre-Fork State:
  • Prior to the hard fork, Odin’s IBC transactions were managed through IBC version 3. One of the relayers was still operational, with certain transactions remaining unprocessed and accumulating as pending within the system.
  1. Post-Fork Complications:
  • Post-hard fork, with the transition to IBC version 7, a critical issue emerged. While Osmosis to Odin transactions continued unaffected, the reverse flow (Odin to Osmosis) encountered failures. The crux of the problem appears to be the system’s inability to reconcile or clear transactions that were pending under the previous IBC version.
  1. Technical Dissection:
  • Detailed investigation revealed that Osmosis had indeed acknowledged receipt and processing of a series of “stuck” packets from Odin. In a standard operational framework, such acknowledgments should trigger the deletion of corresponding packet commitments on Odin, adhering to IBC protocol logic.
  1. Anomaly in Commitments:
  • Post-upgrade, an anomaly was observed where commitments for packets already acknowledged by Osmosis resurfaced on Odin. This abnormality led to a scenario where the relayer, misled by these re-emerged commitments, attempted to reprocess these packets erroneously, assuming they were unacknowledged.
  1. Resolution Dilemma:
  • The main challenge in resolving this issue lies in the unexplained reappearance of these commitments for previously acknowledged packets. The root cause of this anomaly remains elusive, complicating efforts to devise a clear resolution strategy.
  1. Exploration of Solutions:
  • The dialogue among technical experts has explored various avenues, including a potential temporary rollback to IBC version 3 to manage the stuck packets effectively. However, the feasibility of such a rollback is constrained by the dependencies and technical specifications of the SDK in use, which might not support a seamless transition back to an earlier IBC version.

Proposal Specifics

  1. Channel Transition: Terminate all transactions on Channel-3/Channel-258 and officially migrate to Channel-74/Channel-20925 for all ODIN-Osmosis transactions.
  2. Refund for Affected Users: Compile a detailed list of transactions impacted by the Channel-3/Channel-258 issue and initiate a company-funded refund process.
  3. Ceasing Operations on Channel-3/Channel-258: Formally conclude all troubleshooting efforts for Channel-3/Channel-258 to prevent complications from post-resolution transactions.
  4. Liquidity Pool Migration: Shift liquidity from the current pool associated with Channel-3/Channel-258 to a new pool for Channel-74/Channel-20925 to ensure uninterrupted trading operations.
  5. Update on ODIN Registry: Amend the ODIN asset registry on Osmosis to recognize transfers via Channel-74/Channel-20925, ensuring compatibility across the ecosystem.
  6. Launch of ODIN IBC Dashboard: Introduce a user-friendly dashboard for IBC transaction management, allowing seamless asset transfers between channels.
  7. Integration of Skip API: Implement the Skip API to enhance transaction routing efficiency, ensuring the best liquidity paths are utilized, with a focus on Channel-74/Channel-20925 during the transition.

Execution Plan

  • Phase 1: Engagement & Feedback
  • Phase 2: Technical Setup
    • Complete all necessary technical preparations for Channel-74/Channel-20925.
    • Since channel-258 (osmosis >> Odin) is working, users can seamlessly use keplr/leap or odin dashboard to move ODIN back to odin chain.
  • Phase 3: Implementation
    • Initiate the refund process for impacted transactions.
    • Facilitate the liquidity shift to the new pool and update the ODIN registry.
    • Deploy the IBC management dashboard for community access.
  • Phase 4: Ongoing Support
    • Monitor the transition closely to address any issues.
    • Provide continuous support to users adapting to the new channel setup.


The transition from Channel-3/Channel-258 to Channel-74/Channel-20925 between ODIN and Osmosis is pivotal for ensuring the smooth and secure transfer of assets. This detailed proposal lays out a comprehensive plan to tackle existing challenges, reduce user impact, and establish a robust foundation for future transactions. The ODIN team values community feedback and support in actualizing this essential transition.


YES, I support ODIN IBC Channel Transition, allowing ODIN to change the default channel to Channel-74 (ODIN) / Channel-20925 (Osmosis).

Would this refund also include users who have the ODIN Channel 3 version of ODIN on Osmosis and haven’t attempted to withdraw?

As I understand it, changing the channel used also changes the IBC denom and so results in a different asset on the destination chain.

I.e. users using ODIN currently on Osmosis via channel 258 have ibc/C360EF34A86D334F625E4CBB7DA3223AEA97174B61F35BB3758081A8160F7D9B, users using ODIN via channel 20925 would have ibc/23B7FFE8E621153ACFA43F1D3443847AB9203BCC0E28B8D5B0D9860929BFE971 and these are not fungible without returning to Osmosis.

This also wouldn’t require any parameter change on the Osmosis chain side, just approval from the ODIN side and ideally frontend notifications on Osmosis frontends/wallets showing ODIN.

1 Like

@JohnnyWyles No, a refund is not necessary for users holding the Channel 3 version of ODIN (ibc/C360EF34A86D334F625E4CBB7DA3223AEA97174B61F35BB3758081A8160F7D9B), as they can easily transfer their assets back to the home chain. Osmosis can also provide a deposit & withdrawal link that directs users to the ODIN dashboard, where they can manage their assets efficiently.

To prevent further complications, we urge the immediate implementation of the proposed IBC change on both the Osmosis asset and the Cosmos chain GitHub. This update is crucial to discourage users from transferring funds via Channel 3. Since channel-3 is preferred IBC connection within the Cosmos registry Leap & Keplr allow users to still move using channel-3 and getting the funds stuck.

1 Like

I think the idea was to set up a CL pool with 100% of liquidity added as ‘Odin 2’ with both limits set at whatever is the smallest spacing from 1:1 so everyone can just swap. After that I guess just burn the entire thing? Not sure what to do after that.


But if they all have to move back to switch then they could in theory get stuck and need this refund?
1:1 pool would be good as max says when the channel 3 relayers inevitably decommission.

I think @JohnnyWyles is right on this one.

If we change the IBC-channel, the denom changes.
And what also can be learned from the past is that when the channel changes, the relayes change along. So there is a chance that no relayer will support channel-3 anymore, which means that users will be stuck on Osmosis with their ODIN-channel-3 denom… which would be bad from an UX perspective.

Having a pool for it would be good, but the liquidity needs to be big enough to be able to handle all trades (and not create an offset where users will lose as well). Since every trade will automatically change the balance of channel-3 vs the new channel-ID there will be a scenario where the 1:1 ratio will fail to exist.

Also worth noting (@Odin_Protocol ) there are users actively managing things like the Cosmos-registries and more which will most likely also be changed following the proposal on chain. So my best guess would be that Leap and Keplr will move to the new channel-ID pretty fast after the proposal is passed.


  1. The ODIN team will run a relayer on old channels & keep it running for two years. Ensuring that the Odin side of the relayer has no ODIN balance means only transfers from Osmosis >> ODIN will work & ODIN >> OSMO will fail. We will also remind our relayers if anyone is still running on old channels

  2. A concentrated Liquidity pool will be created as Maxmentioned, where the ODIN 2 side will have buy side set super close to 1:1 ratio, this means that the price will never go lower ofcourse we will add equivalent / more Odin_New than the ODIN ch-3 balance on Osmosis.

  3. Regarding channel change on the osmosis/cosmos registry, we tried submitting the request but were informed that it we needed to go through voting, hence the discussion and later onchain text proposal.


Appreciate the clarification

I tried making this today but it isn’t a quote asset so it can’t be done. An AMM pool would be a nightmare trying to keep the price close to 1:1. I suggested setting up something like the OTC swap contract I have on Juno, just ask holders to set up their own swaps 1:1 and the foundation can replace them or something lol… Pretty crusty, but it works. They just need to reimplement the cw module.

Could also use a Transmuter pool and only provide the New ODIN to it, removing any old as it is traded in.


I like this idea!

Since it tackles a lot of the above mentioned issues imo.

Hey All

Quick update: We’ve successfully sorted out ODIN -->>OSMO IBC channel-3 issues, and everything’s smooth now—no more stuck transactions!

All TXs in limbo were cleared & auto-refunded.

Big shoutout to our devs for pulling off a last-minute fix, and a massive thank you to everyone in the Osmosis & ODIN Vals for helping us out.

:rotating_light: No further action needed - we will keep using the old channel

We will write a detailed breakdown of the events. It might just save the day for someone else in the future.

Thank you!
-ODIN Team