Most blockchains cannot talk to each other. Bitcoin does not know Ethereum exists, and neither one can read state from Polkadot. Every network keeps its own ledger, its own consensus rules, and its own asset formats, which leaves liquidity and data trapped in silos. Bridges are the infrastructure that opens those silos, and Polkadot treats bridging as a first-class design concern rather than an afterthought.
So what is a Polkadot bridge?
A Polkadot bridge connects the Polkadot network to external blockchains such as Ethereum, Bitcoin, and Kusama. It carries assets, arbitrary data, and smart contract instructions between Polkadot and chains that do not share its consensus, extending the interoperability Polkadot already provides natively between its parachains.
This guide explains how blockchain bridges actually work, the trust models behind them, the bridges built in the Polkadot ecosystem, the three technical approaches Polkadot uses to connect external chains, and how the Parity bridges codebase is structured if you want to run one yourself.
What Are Blockchain Bridges?
A blockchain bridge, also called a cross-chain bridge, is a protocol that lets two independent blockchains exchange assets and data. Since each chain only validates its own state, the bridge must prove to chain B that an event really happened and was finalized on chain A, ideally without asking users to trust a middleman.
The most common transfer pattern is lock and mint. To move an asset from chain A to chain B, the bridge locks the original asset in a contract or vault on chain A and mints a wrapped representation on chain B. Moving back reverses the flow: the wrapped token is burned on chain B and the original is released on chain A. Send a Solana asset to Ethereum this way and what arrives is an ERC-20 token backed by the locked original.
Moving the token is the easy part. The hard part is verification: how does chain B know the lock on chain A actually happened? Bridge designs answer that question in three broad ways, and the answer determines how much you have to trust and whom.
- Custodial (trusted) bridges. A company or a small multisig committee observes chain A and mints on chain B. Fast and cheap to operate, but the committee can be hacked, coerced, or simply run off with the funds. Users inherit the committee's security, not the chains' security.
- Optimistic bridges. Transfers are assumed valid and can be challenged during a dispute window by watchers who submit fraud proofs. This cuts verification cost, at the price of withdrawal delays and a liveness assumption on honest watchers.
- Light client (trustless) bridges. Chain B runs an on-chain light client of chain A that verifies A's consensus signatures and finality proofs directly. There is no committee to trust, but the design is expensive: you are re-implementing one chain's consensus verification inside another chain's runtime.
The trust model is not an academic detail. Bridges concentrate large amounts of locked value behind a single verification mechanism, which has made them the most attacked component in crypto infrastructure. The Poly Network exploit of August 2021 drained roughly 610 million dollars from a cross-chain bridge in a single incident. That history is why Polkadot's bridge work leans heavily toward light client designs.
What Is Polkadot Bridge?
A Polkadot bridge is a bridge that connects Polkadot's Relay Chain and its parachains to external networks, public or private, that do not share Polkadot's consensus. It moves assets, data, and smart contract calls between Polkadot and chains such as Ethereum, Bitcoin, and Kusama.
Inside Polkadot itself, no bridge is needed. Parachains share the Relay Chain's security and exchange messages through XCM, Polkadot's cross-consensus message format. Bridges exist for the boundary: connecting that shared-security zone to everything outside it.
In the current architecture, external bridges run on Bridge Hub, a system parachain dedicated to bridging. Bridge Hub hosts the on-chain light clients and messaging pallets, and other parachains reach external networks by routing XCM messages through it. Concentrating the heavy verification logic on one system chain means individual parachains do not each have to implement it. Two production bridges follow this design: the Polkadot to Kusama bridge, and Snowbridge, a trustless bridge to Ethereum that verifies Ethereum beacon chain finality on the Polkadot side and Polkadot finality proofs in contracts on the Ethereum side. The Polkadot Wiki documents both.
Bridges Built in the Polkadot Ecosystem
Several teams, many supported by Web3 Foundation grants, have built bridges connecting Polkadot to external networks. Each targets a different chain and sits at a different point on the trust spectrum.
| Bridge | Connected Networks | Design |
|---|---|---|
| Interlay | Bitcoin, Polkadot | Trustless bridge based on the XCLAIM protocol; mints iBTC (formerly PolkaBTC) backed one to one by BTC held by collateralized vaults. |
| Snowbridge | Ethereum, Polkadot | General-purpose trustless bridge built by Snowfork, live on Bridge Hub; moves ETH, ERC-20 assets, and arbitrary messages using on-chain light clients on both sides. |
| Darwinia | EVM chains, Polkadot | Noncustodial, permissionless bridging protocol focused on programmable cross-chain token and message transfer with light client verification. |
| ChainBridge (Centrifuge & ChainSafe) | Multi-directional | Modular, asset-agnostic relayer bridge for fungible and non-fungible tokens; simpler to deploy, but trust rests on its relayer set. |
| ChainX | Bitcoin, Substrate | BTC to Substrate bridge managed by validators staked in ChainX's consensus, who jointly control a Bitcoin multisig. |
| Bifrost | EOS, Polkadot | Cross-chain asset transfers verified through on-chain light nodes and Merkle proofs. |
Interlay: A Trustless Link to Bitcoin
Interlay built a trustless bridge between Bitcoin and Polkadot on the XCLAIM protocol. Users lock BTC with collateralized vault operators and mint iBTC (originally launched as PolkaBTC) on Polkadot, backed one to one by the locked Bitcoin. Vaults post collateral worth more than the BTC they custody, so misbehavior is punishable by slashing rather than prevented by trust. The result brings Bitcoin liquidity into Polkadot DeFi without a central custodian, and the design is censorship-resistant by construction.
Snowbridge: The Trustless Ethereum Bridge
Snowfork's Snowbridge is a general-purpose bridge between Ethereum and Polkadot, running in production on the Bridge Hub system parachain. It is more than an asset mover: it transfers ETH, ERC-20 tokens, and arbitrary data, and supports cross-chain contract calls. Verification is fully on-chain in both directions. An Ethereum beacon chain light client runs on Bridge Hub, and Polkadot finality is verified by contracts on Ethereum, so no permissioned relayer set sits in the trust path.
Darwinia: Programmable Cross-Chain Messaging
Darwinia positions itself as a cross-chain bridge hub, with a noncustodial and permissionless protocol for moving tokens and messages between EVM chains and the Polkadot ecosystem. Its focus is efficient, low-cost decentralized verification, combining light clients with optimistic mechanisms to keep proof costs down.
ChainBridge: The Centrifuge and ChainSafe Collaboration
Centrifuge and ChainSafe jointly built ChainBridge, a modular, asset-agnostic, multi-directional bridge that moves both fungible and non-fungible tokens between chains. It is open source and intentionally simple to integrate, which made it a common starting point for teams that need bridging quickly. The trade-off is its trust model: transfers are attested by a configured relayer set rather than verified by light clients.
ChainX: Validator-Managed Bitcoin Bridging
ChainX, a crypto asset exchange platform, operates a bridge between Bitcoin and a Substrate-based chain. The bridge is managed by validators staked in ChainX's proof-of-stake consensus, who jointly control a Bitcoin multisig wallet. Economic stake secures the custody, placing it between fully custodial and fully trustless designs.
Bifrost: Light-Node Transfers for EOS
Bifrost developed a bridge for EOS networks that provides cross-chain asset transfers through on-chain light nodes and Merkle tree verification, keeping validation on-chain instead of delegating it to an external committee.
Three Ways to Bridge a Blockchain to Polkadot
How a bridge gets built depends on what the other chain can do. Does it run Substrate? Does it support smart contracts? Does it support neither? Polkadot's answer differs for each case, and the three approaches below cover the full spectrum.
Bridge Pallets for Substrate Chains
When both sides are Substrate-based, the bridge is implemented as runtime modules called pallets, compiled directly into each chain's logic. The Polkadot to Kusama bridge works this way: each side runs a pallet that acts as an on-chain light client of the other, verifying GRANDPA finality proofs as they arrive.
A bridge pallet can also be deployed on a system parachain, or on a community-operated parachain, to receive messages from an external network on behalf of the whole ecosystem. This is exactly the role Bridge Hub plays today.
Smart Contracts for EVM Chains
When the other chain is not Substrate-based but supports smart contracts, the bridge logic is deployed as smart contracts on that chain. On Ethereum, a bridging contract executes transactions based on the cross-chain messages it receives, and because the EVM's contract languages are Turing-complete, the full verification logic can live on-chain.
The classic two-contract pattern illustrates the mechanics. One contract is deployed on each chain, and value moves between them: depositing ETH into the main chain contract credits a balance denominated in ERC-20 tokens on the other side, and depositing those tokens back releases the ETH. Snowbridge applies the same principle with a stronger verification layer, replacing trusted authorities with light client proofs in both directions.
Higher-Order Protocols for Everything Else
Some chains offer neither Substrate compatibility nor expressive smart contracts. Bitcoin is the canonical example. For these, bridges use higher-order protocols such as XCLAIM, which secure transfers economically instead of programmatically: every swappable asset must be backed by collateral worth more than the asset itself, so any vault that misbehaves loses more than it could steal.
For connecting Substrate chains to Ethereum specifically, three routes exist:
- The Substrate EVM module, which runs EVM bytecode inside a Substrate chain
- The Polkadot to Ethereum public bridge
- The Substrate to Parity Ethereum (OpenEthereum) bridge
How to Set Up and Run a Parity Bridge
Parity's bridges codebase combines Substrate pallets with off-chain relayer applications, and ships everything needed to run a bridged pair of test chains locally. The code lives in the parity-bridges-common repository on GitHub; the actively maintained version has since been folded into the Polkadot SDK monorepo, but the standalone repository remains the clearest reference for the architecture.
Installation
You need two Rust toolchains: stable for most of the build, and nightly for compiling the WebAssembly runtime that bridge nodes execute. Install the nightly toolchain with rustup, then add the wasm32-unknown-unknown compilation target to it.
With Rust ready, clone the parity-bridges-common repository from GitHub, then run a full Cargo build and the Cargo test suite across the workspace to confirm everything compiles and passes. If you prefer containers, Parity publishes a bridges CI Docker image (paritytech/bridges-ci) that carries the complete toolchain; mount the repository and a cache directory into the container and run the same Cargo build inside it.
Understanding the High-Level Architecture
The core idea: a bridged chain follows the consensus of a foreign chain. Suppose you are bridging two Substrate chains, X and Y. Chain X must be able to receive Y's headers and verify their integrity, which it does through a runtime module that acts as an on-chain light client tracking GRANDPA finality, Polkadot's finality gadget.
The two chains cannot connect to each other directly, so an external service called a relayer carries the proofs. The relayer subscribes to chain Y's finalized headers over RPC and submits them, with finality proofs, to the light client module on chain X. A second relayer does the same in the opposite direction. Relayers are untrusted couriers: they can censor by going offline, but they cannot forge anything, because every submission is verified on-chain against the tracked consensus.
Project Layout
The repository is organized around that architecture:
- bin: the node and runtime definitions for the test Substrate chains
- modules: the Substrate pallets, including the on-chain GRANDPA light client, the cross-chain message passing module, and the dispatch module that executes messages on the target chain
- primitives: types shared between modules, runtimes, and relays
- relays: the off-chain applications that ferry headers and messages between chains
- deployments: scripts and tooling for spinning up test networks, including a Docker Compose setup
Getting the Bridge Running
The relayer connects to the RPC interface of a node on each side of the bridge. You can run everything from source or use the provided Docker Compose deployment; from source, the flow is:
- Build three binaries with Cargo: the two bridge node packages (one per chain) and the substrate-relay package
- Start both dev nodes using the launch scripts under deployments/local-scripts
- Start the header relayers in each direction with the relay scripts in the same folder
- Once headers are syncing, start the message relayers for both directions
When the header relayers are running you will see log lines reporting finality proofs being submitted, for example a debug entry announcing the proof of a chain Y header being sent to chain X, followed by an info line confirming how many headers have synced. Once message relayers join, the two dev chains exchange messages end to end: a complete miniature cross-chain system on one machine.
Example Use Cases of Polkadot Bridge
Bridges matter because of what they unlock. Here are the applications that drive real usage of Polkadot's bridges today.
Bridging Polkadot and Ethereum
Gavin Wood outlined three pathways for connecting the Polkadot and Substrate ecosystem with Ethereum in a 2019 talk: a public Polkadot to Ethereum bridge, a Substrate to Parity Ethereum bridge, and the Substrate EVM module. The public bridge path is now production reality through Snowbridge. Ethereum assets can move into Polkadot DeFi with light client verification at both ends, and parachain applications can trigger contract calls on Ethereum. For a team building a dApp, that means Ethereum's liquidity with Polkadot's execution environment, without handing custody to a bridge operator.
Connecting Bitcoin and Polkadot
Bitcoin has no smart contracts, yet it holds the deepest liquidity in crypto. Interlay's XCLAIM-based bridge makes that liquidity usable on Polkadot. BTC holders lock coins with collateralized vaults and mint iBTC on Polkadot; burning iBTC releases the BTC on the Bitcoin chain. The specification defines two components: the XCLAIM component, which manages all accounts holding the bridged asset, and BTC-Relay, which verifies Bitcoin's state whenever a new transaction is submitted. The collateral requirement means users are protected by economics, not promises.
Enterprise and Private Chain Connectivity
Bridges are not limited to public networks. Because Polkadot bridges private Substrate chains as readily as public ones, an organization can run a permissioned chain for internal records and settle or publish selected state to the public ecosystem through a bridge. That pattern suits consortium networks, supply chain systems, and regulated businesses that need selective transparency without putting everything on a public ledger.
How Webisoft Helps You Build on Polkadot
Webisoft is a Montreal-based software engineering firm that designs and ships blockchain systems end to end, including cross-chain architecture in the Polkadot ecosystem.
Polkadot and Substrate Engineering
Our engineers work across the Polkadot stack, from Substrate runtime development to XCM integration, and help teams build decentralized apps (dApps) that interoperate across chains rather than living on one island.
Custom Cross-Chain Architecture
Bridge selection is an architecture decision with real security consequences. We evaluate trust models, verification costs, and liquidity needs for your specific case, then design and build the integration: smart contracts, blockchain development, custom dApps, or wiring blockchain rails into existing systems.
Full-Cycle Delivery
We take projects from specification through audit-ready implementation to deployment and maintenance. One team owns the outcome, which keeps accountability clear and integration problems visible early instead of at launch.
Where Cross-Chain Interoperability Goes Next
Polkadot bridges connect the Relay Chain and its parachains to external networks like Ethereum and Bitcoin, using bridge pallets for Substrate chains, smart contracts for EVM chains, and collateral-backed protocols like XCLAIM where neither is available. The direction of travel is clear: trust-minimized, light-client-based designs like Snowbridge are replacing committee-run bridges, because the history of bridge exploits has made the trust model the deciding factor.
Ready to build cross-chain applications? Get in touch with Webisoft and put a senior engineering team behind your Polkadot bridge integration.
It depends on the target chain. If both chains are Substrate-based, use bridge pallets with on-chain GRANDPA light clients. If the target is an EVM chain, deploy bridge smart contracts, ideally with light client verification as Snowbridge does. If the target has no smart contracts at all, like Bitcoin, use a collateral-backed higher-order protocol such as XCLAIM.
No. Parachains share the Relay Chain's security and communicate natively through XCM, Polkadot's cross-consensus message format. Bridges are only needed to connect Polkadot to external networks that do not share its consensus, such as Ethereum, Bitcoin, or Kusama.
Snowbridge, the production Polkadot to Ethereum bridge running on the Bridge Hub system parachain, is trustless by design. An Ethereum beacon chain light client runs on the Polkadot side and Polkadot finality proofs are verified by contracts on Ethereum, so no permissioned committee sits in the verification path. Relayers only carry proofs; they cannot forge them.
PolkaBTC was the original name of Interlay's Bitcoin-backed asset on Polkadot. It launched in production as iBTC. The mechanism is unchanged: BTC is locked with collateralized vaults under the XCLAIM protocol, iBTC is minted one to one on Polkadot, and burning iBTC releases the underlying Bitcoin.
The dominant risk is a compromise of the bridge's verification mechanism: a hacked multisig on a custodial bridge, a bug in a bridge contract, or a flaw in a light client implementation. Bridges concentrate large locked balances behind that single mechanism, which is why incidents like the Poly Network exploit were so costly. Prefer bridges with on-chain verification or over-collateralized designs, and treat the trust model as the first evaluation criterion.
