Thread by @CBarraford

I want to clear up @THORChain's relationship with #IBC and why it's made the decisions its made.
IBC is a good bridging design but doesn't meet the design specifications and requirements of the @THORChain project. 🧵

https://twitter.com/Wickex2/status/1446876345120735245

THORChain will be implementing IBC, but NOT for interfacing with its liquidity pools. Instead, you can beam out $RUNE and THORChain synthetic assets to other cosmos chains via IBC, but not beam in external assets via IBC. This will contribute a massive amount to the IBC ecosystem

THORChain uses its own bridging design called "Bifrost" for its pools. This was designed & developed before IBC even existed. So IBC wasn't really an option from the start. But even if it was it would have not been a good choice for the goals and design requirements of THORChain

IBC was designed to bridge two cosmos chains. It does NOT work with the greater crypto sphere out of the box. It is possible using a shim layer of some kind, but that creates more complexity and security concerns as each chain is implemented. This is why IBC is NOT chain agnostic

THORChain needed to be chain agnostic from the start, and connect to any chain no differently than any other chain. I see targeting a subset of chains is a "half solution" to the cross chain problem. Almost all cross chain DEXes out there are making this very mistake today.

Another important design choice for THORChain, is not using wrapped or pegged assets. There are a host of reason why wrapped or pegged assets are a non-starter. 1) a wrapped asset is not the asset (ie a wrapped bitcoin is not a real bitcoin).

2) you cannot economically secure wrapped assets without a trusted central entity. This is because there is a strong decoupling between the value of the assets that are securing the network, and the value of the assets its securing.

3) Holding a wrapped asset continuously retains additional risk. You require the bridge to stay up to maintain its value. Swapping from L1 <> L1 on THORChain, it doesn't matter if THORChain dies the next day. You still have your L1 asset, therefore it has less risk by design

IBC transfers asset via wrapping them. Like Ren or WBTC, IBC locks up the source asset in the source chain, and mints a 1:1 representative asset on the target chain. THORChain does not operate this way & believes this isn't the right approach to getting #DeFi to be more inclusive

Bifrost's design insures a "carrot & stick" to directly incentivize actors to be participate & facilitate cross chain comms. IBC wasn't designed with any economics in mind. It requires "altruistic" actors to facilitate comms, but this could change in a future spec of the protocol

THORChain is permissionless and interfaces with other chains permissionlessly. #Bitcoin didn't need to make any code changes to allow THORChain, nor is there anything #Bitcoin can do to stop @THORChain. This is not the case with IBC's design.

Putting aside these design requirements, implementing two types of cross chain bridges goes against basic & fundamental standards of code architecture. It would add a lot of code to write, secure & maintain/debug while not offering any value that isn't already achieved by Bifrost

As I said before, IBC has a good bridging design. And for most cosmos projects, it is probably a good choice to adopt/use. I certainly may use in a future project, but it is not a good fit for this one.