(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".
Let's first start with a list of capabilities/requirements; the exact subset of these requirements for your (parachains’) business use-case will also inform the best deployment option.
Transact
support. Support for calling a function/smart-contract/etc on the other side while preserving the original origin (actual caller).A bridge lane is a dedicated XCM transport channel between two chains on opposite sides of the bridge. Conceptually, it serves the same purpose as an HRMP channel between two sibling parachains.
Today, Snowbridge has such a lane deployed between AssetHub and Ethereum.
Making use of this existing lane is the easiest option for a parachain to expose the bridge to its users, while satisfying the vast majority of bridge usecases.
Example using XCMv5: Alice
on ParaP
can send any asset to Ethereum
and even transact on Ethereum
as ParaP/Alice
origin:
UserAgent (UI/wallet/etc) executes XCM1
on ParaP
using Alice
signed account:
Note: XCM programs described above do not contain the details of how to calculate and include exact fees, or how the program above actually works under the hood to make everything happen; that will be covered by separate documentation linked to in lower section Parachain-integration-steps.
Satisfies requirements 1, 2, 3, and 5. Can be "massaged" to support 4, but with some gotchas (covered in next section Drawbacks).
Supports (1) "Bidirectional classic transfer" by allowing native XCM transfers for assets understood/registered-on AssetHub and Ethereum. These assets are held in reserve on their native ecosystem on AssetHub, respectively Ethereum, and 1:1 derivatives are used on the other side.
Supports (2) "Ecosystem recognizes/accepts the bridged assets" because (bridged) assets registered on AssetHub are recognized and supported by the rest of the ecosystem.
Supports (3) "XCM Transact support" by being able to persist the original origin across hops to the final destination. Requires XCMv5.
The MAJOR advantage of this option is property (5) "No (extra) offchain infrastructure required". By using the existing and already serviced AssetHub lane, parachains do not need to deploy or worry about incentivizing others to deploy offchain relayers.
Another big advantage is that user agents (UIs, wallets, Phone apps, Web apps) that support this lane, automatically or very easily support all parachains using it. Tooling will be more accessible.
(4) Custom tokenomics XCMs can be run on the final destination (e.g. ReceiveTeleportedAsset
to teleport over the bridge), but with the drawback that special care or error handling needs to be built for potential failures along the way.
The AssetHub intermediate hop does not process the custom tokenomics logic meant for final destination, so for example, if you burn TOK on source then encapsulate a message to mint TOK on destination all is good as long as the final XCM reaches destination. If it errors out on AH, the inner TOK logic is "lost", TOKs are not automatically trapped on AssetHub.
Does NOT support (6) "control over bridge traffic flow, QoS, pricing, latency". All bridge traffic on the AssetHub lane is bulked together with no differentiation. Pricing and latency are controlled by AssetHub (and existing relayers).
Detailed description of an example flow including fees calculation can be found in the Snowbridge V2 design doc.
TODO: We will follow up with more details on:
Snowfork team plans to support a feature where parachains on Polkadot can permissionlessly open dedicated bridge lanes with Ethereum. This would be deployed on AssetHub and it would be the functional equivalent of the same feature on the P<>K bridge.
This feature/option does not yet have an estimated delivery date, but I expect it to be live by end of 2025.
A "dedicated bridge lane" is a direct logical XCM channel between the parachain and Ethereum, while using "AH as exporter" means the actual message transport still goes through AssetHub to make use of existing bridging logic there. Visualisation for it:
The dedicated lane uses AH as XCM exporter, meaning that XCMs destined for Ethereum are intercepted by a local Bridge Router on source parachain, wrapped in an ExportXCM
and sent to AssetHub for exporting to Ethereum. The Ethereum exporter on AssetHub will unwrap the original XCM and dispatch it to Ethereum while including some origin-altering instructions so that the original XCM executes with the original origin (e.g. ParaP/Alice
).
User agents (UIs/wallets/etc) can use the bridge as if there are no intermediary hops. The intermediary AssetHub hop is abstracted away by the deployed Bridge Router
and by AssetHub machienery.
This is an example for an important usecase where custom tokenomics are supported between Polkadot parachain ParaP
and Ethereum smart contract ESC
, where the TOK token is fungible on both networks:
Note: XCM programs described above do not contain the details of how to calculate and include exact fees, or how the program above actually works under the hood to make everything happen; that will be covered by separate documentation specific to this Option 2
.
As you can see from the example, one advantage is that the parachain has direct XCM communication with Ethereum. The indirect hop through the exporter (AssetHub) is hidden away from the User Agent.
Satisfies requirements 1, 3, 4.
The major advantage is easy support for (4) Custom tokenomics. The parachain team is free to impose any asset rules it wants. E.g. they can treat their native tokens as fungible between their Polkadot parachain and their Ethereum Smart Contract, allow teleporting them from one side to the other, thus effectively merging them in a single unified asset, and economically consolidate their multi-chain tokenomics and business.
Supports (1) "Bidirectional classic transfer" by allowing native XCM transfers between the two chains. But any bridged assets are not recognized/accepted by the rest of the Ecosystem and do not integrate with Asset Hub. Note that teleported/translated/merged tokens (such as merged native tokens) do not suffer from this problem. E.g. ETOK (native to Ethereum) teleported to ParaP is minted on ParaP directly as PTOK (native to ParaP), it is not a bridged-asset really, each ecosystem on both sides of the bridge treats TOK as native (just that its total supply is split between the two ecosystems).
Supports (3) "XCM Transact support" as it allows direct XCM communication between chains.
Kind of a compromise between (5) "No (extra) offchain infrastructure required" and (6) "control over bridge traffic flow, QoS, pricing, latency" where you sort of get a bit of both. Offchain infra is required, but it's standard software. E.g. parachain needs to deploy and run offchain relayer but doesn't need to maintain its code, can use the standard Snowfork relayer software. By having a dedicated lane and dedicated offchain relayers, the parachain team can control the traffic flow and latency (maybe even pricing with some further enhancements).
Does not support (2) Ecosystem recognizes/accepts the bridged assets as described above. This option is useful for custom tokenomics for specific parachain-native assets but doesn't play well with general purpose ecosystem assets.
Another disadvantage worth mentioning is that if the parachain-bridge-router-generated-XCM fails to execute on the exporter (AssetHub), the inner/exported XCM is lost and any inner assets with it. They are not trapped on AssetHub as it happens with Option 1
, because AssetHub does not process or inspect the inner/exported XCM. However, in practice this should never happen once the parachain deploys a robust bridge-router that generates robust XCMs.
TODO: @snowfork-team to publish these when design is complete.