Kusama Support

The goal is support Kusama by composing the existing P↔K and P↔E bridges.

First, lets define what this support actually entails from the perspective of the user.

Users should be able to:

• One-click transfer assets from a source parachain on Kusama to Ethereum, and vice-versa.
• Send a transact from a source parachain on Kusama to Ethereum, and vice-versa.

Example Scenario

This scenario demonstrates a complicated use case that involves sending assets together with transact call from Kusama to Ethereum.

More specifically, Alice on AHK wants to send 2 WETH to contract Bob on Ethereum, and call Bob.hello()

Alice chooses to pay USDT for execution fees on AHK and AHP.

XCM:

# x0: XCM executioned on AHK
WithdrawAsset [(KUSDT, 10), (KWETH, 10)]
PayFees (KUSDT, 9) # AHK->AHP bridging fee
InitiateAssetTransfer
    Dest=/Polkadot/Para(AssetHub)
    Assets=[
        (KUSDT, DestinationReserve, 1)
        (KWETH, DestinationReserve, 10)
    ],
    Xcm=[
        # x1: XCM executed on AHP
        PayFees [
            (USDT, 1) # Local xcm execution fee
            (WETH, 8) # P->E Bridging fee
        ]
        InitiateAssetTransfer
            Dest=/Ethereum
            Assets=[
                (WETH, DestinationReserve, 2)
            ]
            Xcm=[
                # x2: XCM executed on Ethereum
                DepositAsset (WETH, 2, Bob)
                Transact Bob.hello()
            ]
    ]

Current Status

The following PR is a proof-of-concept of double-bridging, allowing any tokens to be transferred between Westend and Sepolia via Rococo.

https://github.com/paritytech/polkadot-sdk/pull/4888

The same configuration will need to be applied for the K↔P↔E bridge.

The design will entail:

• AHP trusts AHK as a reserve for all tokens native to Kusama
• AHP trusts our Gateway location /Ethereum(chain_id=1) as the reserve for all Ethereum tokens.

This solves the protocol-level mechanism for transferring tokens. However there are still some missing pieces:

• The gateway contract on Ethereum doesn’t support addressing double-bridged locations, or in other words, we need to make it understand Kusama parachains as a valid destinations for tokens.
• There is no mechanism to register Ethereum-native tokens as foreign assets on AHK, or in the other direction, registering Kusama-native tokens on Ethereum. It all currently needs to be done manually using governance. We need to add permissionless APIs to make this possible.
• No UX support

Fees

User→AHK→AHP→E

The user would need to supply a mix of fee tokens that can:

1. Pay for XCM execution on AHK and AHP
2. Pay for remote delivery to Ethereum

USDT, KSM, and WETH (and their wrapped variants) are all sufficient assets on AHK and AHP, and can be used for fees. However only WETH can be used for both (1) and (2).

Its up to the XCM builder acting as the user agent to validate that the choosen fee tokens are valid at each step of the journey.

In our V2 redesign, we expect that the XCM builder / user agent dry-runs the sequence of XCMs (x0, x1, x2) to calculate lowest possible fees that the user needs to pay.

It looks like we can tailor that process to also work for double-bridged scenarios, though we'll need to confirm first that the XCM dry-run APIs abstract over the K<->P bridge???