A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other. Bridge designs come in a variety of flavors ranging from centralised and trusted to more decentralised and trustless. Polkadot favors the latter bridge designs for its ecosystem. However, there is nothing that blocks a development team from building and deploying the former.
While bridge designs are now getting to a place where they are sufficiently planned out, there have not been too many used heavily in production. For this reason, you can consider this page a work in progress. It will be updated as more information is determined and available.
Bridges are specifically for making the Kusama ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCM, the native interoperability technology that allows parachains to communicate trustlessly, please see the dedicated cross consensus page on the Wiki.
Building a bridge that is as decentralised and trustless as possible can be done through any of the following methods (ordered by suggested methodology):
- Bridge pallets - For Substrate-native chains, use a bridge pallet (e.g. Kusama
<->Polkadot bridge, since both networks' parachains use Substrate).
- Smart contracts - If the chain is not on Substrate, you should have smart contracts on the non-Substrate chain to bridge (e.g. Ethereum mainnet will have a bridge smart contract that initiates Eth transactions based on incoming XCMP messages).
- Higher-order protocols - If your chain does not support smart contracts (e.g. Bitcoin), you should use XClaim or similar protocols to bridge.
via Bridge Pallets
Receiving messages on Kusama from an external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate instance can then be deployed to Kusama either as a system-level parachain (native extension to the core Kusama software) or as a community-operated parachain.
An example of a bridge that would strictly use bridge pallets would be a Kusama
bridge, since both use parachains based on Substrate.
For the standalone chains that will not have a parachain bridging module on Kusama (non-Substrate), it will be necessary to deploy bridge contracts (see below).
via Smart Contracts
Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Kusama and any other smart contract capable blockchain.
Those who are already familiar with Ethereum may know of the now archived
Parity Bridge and the efforts being made to connect
PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts,
one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage,
the initial Parity Bridge proof of concept connects two Ethereum chains,
deposited into the contract on
main generates a balance denominated in ERC-20 tokens on
Conversely, ERC-20 tokens deposited back into the contract on
side can free up Ether on
To learn more on how Bitcoin and Ethereum can cooperate and collaborate Through Kusama, check out this explainer video here
via Higher-Order Protocols
Higher-order protocols (like XCLAIM) can be used to bridge but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead.
An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart-contracts and it's not based on Substrate.
Ethereum Bridge (Smart Contracts <-> Polkadot)
As explained by Dr. Gavin Wood in a blog post from late 2019, there are three ways that the Kusama and Substrate ecosystem can be bridged to the Ethereum ecosystem.
- Kusama <-> Ethereum Public Bridge.
- Substrate <-> Parity Ethereum (Openethereum) Bridge.
- The Substrate EVM module.
Please read the blog article for fuller descriptions of each one of these options.
Bitcoin Bridge (XCLAIM <-> Substrate <-> Polkadot)
The Interlay team has written a specification on a Bitcoin bridge that is based on the XCLAIM design paper. The protocol enables a two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to Polkadot as PolkaBTC, and holders of PolkaBTC to burn their assets for BTC on the Bitcoin chain.
The Bitcoin bridge, as documented in the specification, is composed of two logically different components:
- The XCLAIM component maintains all accounts that own PolkaBTC.
- The BTC-Relay is responsible for verifying the Bitcoin state when a new transaction is submitted.
For full details on how it works, please refer to the specification.
There is now a reference implementation and testnet available.
Additional Resources and Examples
- Parity Bridges Common Resources
- Substrate/Ethereum Bridge - ChainSafe and Centrifuge were awarded a grant in W3F Grants Wave 5 to build a Substrate to Ethereum two-way bridge.
- PolkaBTC (Bitcoin <-> Polkadot Bridge)
- EOS Bridge - The Bifrost team was awarded a grant in W3F Grants Wave 5 to build a bridge to EOS.
- Tendermint Bridge - ChorusOne was awarded a grant in Wave 5 to build a GRANDPA light client in Tendermint.
- Interlay BTC Bridge - The Interlay team was awarded a grant in W3F grants Wave 5 to build a trust-minimized BTC bridge.
- ChainX BTC Bridge - ChainX have implemented a BTC to Substrate bridge for their parachain.
- POA Network
- Case study of POA Network's implementation of Parity's bridge chain solution.
- Edgeth Bridge - a bridge from Ethereum to Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example.
- XCLAIM - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets.