# IBC Protocol Considering users want to transfer their assets and data between execution chains in a safe, simple, affordable, and timely way, let’s imagine another multi-chain topology where all execution chains are directly connected and are also connected with every legitimate settlement chain. Moreover, all connections between blockchains are trustless — based on light client verification or its ZKP equivalents. Surprisingly, this describes a landscape that Cosmos had envisioned for years with its [IBC protocol](https://cosmos.network/ibc/).
However, dark clouds still hover, albeit replaced by a different set. * *After token A has been transferred from S to E1, can it be transferred to E2?* The answer should be a firm “Yes.” Else, the connection between E1 and E2 is useless. * *But when token A arrives in E2, is it the same, aka fungible, as its kind, which was transferred directly from S to E2?* The answer from IBC is “No” because different paths carry different risks. In other words, the probability of the token losing its redemption rights for the original asset on the settlement chain varies. The answer from IBC is “No” because different paths carry different risks. In other words, the probability of the token losing its redemption rights for the original asset on the settlement chain varies.
Fungibility loss leads to liquidity fragmentation and user confusion. To address these issues, IBC is working on a so-called ['unwinding](https://github.com/cosmos/ibc/discussions/824)' feature, whereby token A doesn't directly transfer from E1 to E2 but goes back to S and then to E2 — the whole process is transparent to the user. However, even with the full implementation of unwinding, users still have to bear the high gas costs of the settlement chain and significant delays. * Taking a step back, what would happen if tokens remained fungible when reaching an execution chain via different paths? A disaster. A hacker could take down one execution chain, most likely the weakest one, flood other chains with fake tokens (since they are all connected directly, and accept tokens from the hacked chain). Liquidity on all execution chains, plus tokens locked on settlement chains, would all be exploited at once. * Is there a way to balance security, token fungibility (for preventing liquidity fragmentation and user confusion), cost, and delay? Yes! And guess what? IBC once had an opportunity to achieve all of these.
If a hub were imposed between all chains, it could keep a global ledger of how many tokens have been transferred to an execution chain. In this case, tokens remain fungible on all execution chains, while attacking losses are limited to the assets users explicitly choose to store on the hacked chain. Logical connections (dashed lines) can be established between any two execution chains, provided they have physical connections (solid lines) with the hub. As long as the Hub is fast enough and cheap enough, it can be kept invisible to users by utilizing multi-hop IBC packets. However, this system still has three weak points: relayers, hub, and peg zones.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://omnity.gitbook.io/litepaper/challenges/ibc-protocol.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.