Option 2: Use dedicated bridge lane with AH as exporter
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:
// following bridge-teleport only allowed for certain origins,
// e.g. TOK owner
XCM(
// withdraw native asset for fees and pay for transport and remote fees
WithdrawAsset(TOK),
PayFees(TOK),
// initiate a transfer directly to Ethereum including custom logic
InitiateTransfer(
// send to Ethereum
dest: Ethereum,
// teleport TOK over the bridge
remote_fee: Teleport(TOK, fee),
assets: Teleport(TOK, rest),
// executes on Ethereum
remote_xcm: XCM(
// deposit `rest` TOK to ESC on Ethereum
Deposit(All, ESC)
)
)
)
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 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.
Drawbacks
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.
Parachain integration steps
TODO: @snowfork-team to publish these when design is complete.