Option 2: Use dedicated bridge lane with AH as exporter
With upcoming polkadot-fellows/runtimes v1.4.x (ETA Q1 2025) we are deploying a feature where parachains on Polkadot and Kusama can permissionlessly open dedicated bridge lanes between each other. As described in previous section, a “lane” is a direct logical XCM channel between two chains. Visualisation for it:
The dedicated lanes use AHs as XCM exporters, meaning that XCMs destined for the other parachain are intercepted by a local Bridge Router on source parachain, wrapped in an ExportXCM and sent to local AssetHub for exporting to the other side. The other Asset Hub will unwrap the original XCM and dispatch it to the final destination 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 hops are abstracted away by the deployed Bridge Router and by Asset Hub machienery.
To showcase a similar usecase as with first option:
Alice on ParaP reserve-transfers some asset to ParaK and even transacts on ParaK as ParaP/Alice origin within same XCM (XCMv5):
// executes on ParaP with Alice local origin
XCM(
// withdraw assets for transfer
WithdrawAsset(WhateverYouWant),
// withdraw native asset for fees and pay for transport
WithdrawAsset(TOK),
PayFees(TOK),
// initiate a transfer directly to ParaK including custom logic
InitiateTransfer(
// send to Kusama/ParaK
dest: Kusama/ParaK,
// teleport TOK over the bridge
remote_fee: Teleport(TOK),
// include the other assets
assets: WhateverYouWant,
// executes on Kusama/ParaK
remote_xcm: XCM(
// transact on ParaK as ParaP/Alice
Transact(Whatever),
// refund any fees not spent
RefundSurplus,
// deposit all remaining assets to Bob on ParaK
Deposit(All, Bob)
)
)
)
Another important usecase showing custom tokenomics capability: ParaP teleports (custom tokenomics) some asset to ParaK (this time using only already available XCMv4 instructions):
// executes on ParaP
XCM(
// withdraw native asset for transferring
WithdrawAsset(TOK),
// initiate teleport to Kusama/ParaK
InitiateTeleport(
dest: Kusama/ParaK,
assets: TOK,
// executes on Kusama/ParaK
remote_xcm: XCM(
// buy execution on ParaK
BuyExecution(TOK)
// deposit all remaining assets to Bob on ParaK
Deposit(All, Bob)
)
)
)
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.
Properties
As you can see from the examples, one advantage is that the two parachains have direct XCM communication. The indirect hops through the exporter are hidden away from the User Agent.
Satisfies requirements 1, 3, 4, 5.
The major advantage is easy support for (5) Custom tokenomics. The two parachains are free to impose any asset rules they want. E.g. they can treat their native tokens as fungible between each other, allow teleporting them from one side to the other, thus effectively merging them in a single unified asset.
Supports (1) “Bidirectional classic transfer” by allowing native XCM transfers between the two parachains. 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. KusamaTOK (native to ParaK) teleported to ParaP is minted on ParaP directly as PolkadotTOK (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” and (4) “Full XCM support” as it allows direct XCM communication between chains.
Drawbacks
Kind of a compromise between (6) “No (extra) offchain infrastructure required” and (7) “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 Parity 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 Asset Hub as it happens with Option 1, because Asset Hub 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.
Parachain integration steps
TODO: We will follow up with documentation detailing:
- Relevant components required by parachains to add to their runtimes,
- Relevant parachain runtime configs required,
- Example flow including fees calculation,
- from the point of view of the User Agent (how to build program, how to calculate fees),
- from the point of view of the involved chains once it executes,
- Documentation on how to run a messages relayer for a dedicated lane.