Cross-chain within Polkadot Within Polkadot, businesses can easily operate cross-chain. Polkadot chains are natively interconnected, with cross-chain messages' validity and reliability guaranteed by the core protocol. On top of this transport protocol, XCM can be used to allow businesses to expand their scope and easily operate within the whole Polkadot Ecosystem. A business's token can move across the ecosystem through XCM in manner trusted by the whole ecosystem, thus liquidity or utility moves freely and can be easily deployed where needed. This allows the business to operate outside the confinements of its own chain, and expose to its customers chain-agnostic (infrastructure-agnostic) products. Cross-chain outside Polkadot Other ecosystems also have cross-chain models of operation with varying degrees of efficiency and success. This article does not attempt to compare them to Polkadot's, but it is important to understand that it is a critical topic for any ecosystem that moved or plans on moving from a single-chain model to a multi-chain one. We can use Ethereum as a case-study, where we see its move to the multi-chain rollups model has heavily fragmented the ecosystem and where they are now working hard on cross-chain mechanisms meant to stich it back together. It is worth noting though, that the mechanisms they are developing are Ethereum-specific. These mechanisms are very opinionated towards EVM Contracts usecases, and are not natively compatible with other Ecosystems, Polkadot included.

Bridges on-chain components (Polkadot side) Very simplified: 1. Consensus layer This is the protocol layer resposible for following and exposing the other chain's consensus protocol, with the principal component being an on-chain light client for the other chain. The "input" of this layer is consensus proofs generated by the bridged chain's validators. The on-chain light-client can understand and process these proofs. The "output" of this layer is a stream of finalized headers belonging to the other chain.

(equivalent doc for P<>K bridge here) There are a few options available to parachains that want to make use of Snowbridge. This document lists and describes them starting from the easiest to integrate and most general-purpose, to more involved configurations that allow higher levels of customization on the bridge behavior. Please note that there are components of the bridge not presented or covered by this document as they are already working live under the hood and are not exposed or meant to be used directly by ecosystem parachains. One major such component is bridge consensus (Polkadot and Ethereum tracking each other's consensus and finality - including Ethereum tracking finality of Polkadot parachains) currently running on Bridge Hub. While this is a major part of the bridge infrastructure, it is not exposed to parachain teams or builders, so not covered in this doc. Also note that we decided to expose builder-facing bridging components on Asset Hub for easier integrations. Bridge Hub has become "invisible infrastructure".

(equivalent doc for Polkadot<>Ethereum bridge here) There are a few options available to parachains that want to make use of the Polkadot<>Kusama bridge. This document lists and describes them starting from the easiest to integrate and most general-purpose, to more involved configurations that allow higher levels of customization on the bridge behavior. Please note that there are components of the bridge not presented or covered by this document as they are already working live under the hood and are not exposed or meant to be used directly by ecosystem parachains. One major such component is bridge consensus (Polkadot and Kusama tracking each other's consensus and finality - including tracking finality of the other side's parachains) currently running on Bridge Hub. This is useful to everyone but only directly exposed to parachain teams that deploy Option 3 listed further down in this document. Also note that we decided to move builder-facing bridging components to Asset Hub for easier integrations. Bridge Hub is just "invisible infrastructure".

Hello Fellows, I am Adrian Catangiu (GitHub: @acatangiu), and I've been contributing to Polkadot for a couple of years now. Most of my contributions have been blockchain bridges related, from within the Parity Bridges team. This year, however, I've pivoted to various other priority topics such as XCM development and cross-chain asset transfers machinery. Over the years, I've delivered a number of important Polkadot components, as well as improving others, with high focus on quality and testing. I've worked on implementing BEEFY and MMR pallets and gadgets which are prerequisites critical components of a Polkadot<>Ethereum bridge, and to Polkadot's "light-client only" future. Implemented BEEFY consensus, going from research PoC to fully functional node & runtime consensus components, currently being deployed on Kusama & Polkadot. Highlighted BEEFY-related PRs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13. Redesigned MMR pallet implementation to allow using offchain storage, highlighted MMR-related PRs: 1, 2, 3, 4. The other main focus of mine was the development (and impending launch) of the Polkadot<>Kusama bridge, where I mostly did design, overview and review work, but where I can also highlight some personal PRs: 1, 2, 3, 4, 5.