How does IBC actually work?

Today I was explaining the Cosmos project to a friend, but I had some trouble explaining the interoperability between zones. For example, the docs state that Cosmos tokens can be transferred from one zone to another securely and quickly without the need for exchange liquidity between zones. But how does that really work for lets say I have 10 Ether and I want to send it to a Bitcoin address. I understand the IBC principle: The principle behind IBC is fairly simple. Let’s take an example where an account on chain A wants to send 10 tokens X on chain B. First, these tokens are locked on chain A. Then, a proof that these 10 tokens X are locked is relayed from chain A to chain B. Chain B tracks the validator set of chain A. If the proof is signed by more than 2/3rd of chain A’s validators, then it is valid, and 10 tokens X are created on chain B. So in the example of sending Ether to a Bitcoin, the Ether is getting locked in the Ether zone of Cosmos. Then after validating that the Ether is being locked in the Ether zone, new “virtual” Bitcoins is being created in the Bitcoin zone. But how does it work when the receiver of the virtual bitcoins wants to extract those virtual…

Excerpt (1197 of 1430 characters). Read the whole post on the forum ↗

Here is the basic principle of how Cosmos is intended to work.

User A -> send 1 BTC to the Cosmos BTC Peg -> gets 1 CosmosBTC on the Hub -> Move 1 CosmosBTC to DEX zone -> trade with user B for 10 CosmosETh

User B -> send 10 ETh to Cosmos ETH Peg -> get 10 CosmosEth on the Hub -> Send 10 CosmosETH to DEX Zone -> Trade with User A for 1 CosmosBTC -> Send 1 Cosmos BTC to Cosmos BTC peg -> get 1 BTC on main chain minus fees to the Peg Zone.

Thx for your reply Zaki, but does the DEX zone not contradict with the following lines from the whitepaper? Tokens can be transferred from one zone to another securely and quickly without the need for exchange liquidity between zones. Instead, all inter-zone token transfers go through the Cosmos Hub, which keeps track of the total amount of tokens held by each zone. That gave me the idea that there won’t be a DEX zone necessary (solving the liquidity problem), as the Cosmos Hub would keep track of the tokens being held in each zone So would it perhaps go as follows: User A sends 1 BTC to the Cosmos BTC Peg → 1 BTC is getting locked, and 1 CosmosBTC is being created → user A sends 1 CosmosBTC to CosmosETH address → the Hub locks/burns the 1 CosmosBTC → Hub creates 10 CosmosETH in CosmosETH’s address (ETH Peg) → User A needs to trade 10 CosmosETH on a DEX for real ETH. That would solve the liquidity problem in between peg zones. Liquidity only would come into play when you’d want to exchange CosmosETH for real ETH But that would leave me with the question (as well as in your scenario, as well as in mine): What happens with the locked in BTC user A sent to the BTC Peg.…

Excerpt (1198 of 1521 characters). Read the whole post on the forum ↗

We don’t need interzone liquidity for transfers but a DEX zone will need to support some sort of order matching and execution which we don’t plan to support in Hub b/c there are many many ways to do this especially with automated liquidity.

Aha, so I’m mixing up transfers and trades I guess. To wrap it up: CosmosBTC can be transferred to the Ether Peg and exist there, there is no liquidity needed for that. However if you want the CosmosBTC on the Ether peg to become CosmosEther you need the DEX zone to trade your CosmosBTC for CosmosEther.

If you’re familiar with the SDK, the IBC specification explains things quite well: https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/ibc

Thanks for the link, I will look into it.