DotSama parachains options for using Polkadot<>Kusama bridge

Ecosystem
,
2

Option 1: Use AssetHub(s) bridge lane

A bridge lane is a dedicated XCM transport channel between two parachains on opposite sides of the bridge. Conceptually, it serves the same purpose as an HRMP channel between two sibling parachains.

Today, the P<>K bridge has such a lane deployed between PAH (Polkadot Asset Hub) and KAH (Kusama Asset Hub).

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 ParaK and even transact on ParaK as ParaP/Alice origin:

P<>K using AH lane
P<>K using AH lane821×229 24.1 KB

UserAgent (UI/wallet/etc) executes XCM1 on ParaP using Alice signed account:

// 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 to PAH including custom logic
    InitiateTransfer(
        // send to PAH
        dest: PolkadotAssetHub,
        // teleport TOK if registered as foreign asset,
        // reserve-transfer otherwise, to pay fees (on PAH)
        remote_fee: ReserveDeposit/Teleport(TOK),
        // include the other assets
        assets: WhateverYouWant,
        // executes on PAH
        remote_xcm: XCM(
            // exchange TOK for some DOT for fees
            ExchangeAsset(TOK, DOT),
            // initiate transfer to KAH including custom logic
            InitiateTransfer(
                // send to KAH
                dest: KusamaAssetHub,
                // send DOT to pay remote fees (on KAH)
                remote_fee: ReserveDeposit(DOT),
                // include the other assets
                assets: WhateverYouWant,
                // executes on KAH
                remote_xcm: XCM(
                    // exchange DOT for some KSM for fees
                    ExchangeAsset(DOT, KSM),
                    // initiate transfer to ParaK including custom logic
                    InitiateTransfer(
                        // send KSM to pay remote fees (on ParaP)
                        remote_fee: ReserveDeposit(KSM),
                        // include any other assets
                        assets: WhateverYouWant,
                        // executes on 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)
                        )
                    )
                )
            )
        )
    )
)

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 1.

Properties

Satisfies requirements 1, 2, 3, and 6.
Mostly supports 4 and can even be “massaged” to support 5, 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(s). These assets are held in reserve on the AssetHub of their native ecosystem, and 1:1 derivatives are used on the other side.

Supports (2) “Ecosystem recognizes/accepts the bridged assets” because (bridged) assets registered on Asset Hub 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.

Major advantage is property (6) “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 potentially big advantage is that user agents (UIs, wallets, Phone apps, Web apps) that support this for one parachain pair, automatically support it for others too. Tooling will be more accessible.

Another advantage worth mentioning is that all hops along the way understand and explicitly process all assets, so if there is any error on any hop, that hop will successfully trap the assets, with an easy recovery mechanism.

Drawbacks

Complicated XCM programs could be built to cover (4) “Full XCM support”, but they would obviously be more complex having to go through multiple hops when compared to the same functional equivalent when going point to point.

(5) 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 intermediate hops do 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 along the way, the inner TOK logic is “lost”, TOKs are not automatically trapped on AssetHub(s).

Does not support (7) “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 Asset Hub.

Parachain integration steps

TODO: We will follow up with documentation detailing:

  • Relevant 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.
1 Like