You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently For transfer from AH to Ethereum, the bridge/export fee is configured in BridgeTable as EthereumBaseFee which will cover the execution cost on Ethreum, it will be charged from end user on AH directly.
It's problematic as the fee is volatile(e.g. affected by gas_price, exchange_rate) and can't be a runtime configuration.
Another issue is that by default we depend on SovereignPaidRemoteExporter routing the message to Ethreum through BH, internally it will WithdrawAsset from the Parachain sovereign and use that to BuyExecution on BH, means it requires an extra process to top-up the sov which is tedious.
Solution
For the first issue we need to move the execution cost on Ethreum out from the EthereumBaseFee and make it an user input which can be estimated by some runtime api. As Adrian suggested here, we can build custom XCM programs paying fees in various assets as we want and execute it using pallet_xcm::execute directly.
For the second issue we'd like to custom an Exporter which burns the fee from the user on AH and teleports to BH to pay fees, and we want to DescendOrigin to user which is required for the upcoming Transact feature.
Challenge
The challenge here is how to make sure the fee is burnt on AH reliably and how to stopping anyone from descending to any origin. There are limitations in current implementation of xcm as follows:
The SendXcm trait doesnt really have access to the source origin.
The FeeReason enum doesnt really have access to the destination.
we explore with 2 options and make a POC for each as follows:
Context
Currently For transfer from AH to Ethereum, the bridge/export fee is configured in BridgeTable as EthereumBaseFee which will cover the execution cost on Ethreum, it will be charged from end user on AH directly.
It's problematic as the fee is volatile(e.g. affected by gas_price, exchange_rate) and can't be a runtime configuration.
Another issue is that by default we depend on SovereignPaidRemoteExporter routing the message to Ethreum through BH, internally it will WithdrawAsset from the Parachain sovereign and use that to
BuyExecution
on BH, means it requires an extra process to top-up the sov which is tedious.Solution
For the first issue we need to move the execution cost on Ethreum out from the
EthereumBaseFee
and make it an user input which can be estimated by some runtime api. As Adrian suggested here, we can build custom XCM programs paying fees in various assets as we want and execute it usingpallet_xcm::execute
directly.For the second issue we'd like to custom an Exporter which burns the fee from the user on AH and teleports to BH to pay fees, and we want to
DescendOrigin
to user which is required for the upcoming Transact feature.Challenge
The challenge here is how to make sure the fee is burnt on AH reliably and how to stopping anyone from descending to any origin. There are limitations in current implementation of xcm as follows:
The SendXcm trait doesnt really have access to the source origin.
The FeeReason enum doesnt really have access to the destination.
we explore with 2 options and make a POC for each as follows:
Option 1: Custom Exporter + FeeHandler, the fee handler would need to subtract
EthereumBaseFee
from the fees(essentially the burning) for Ethereum destination, POC with Revamp xcm for the reserver tranfer from substrate to Ethreum & Implement a custom exporter Snowfork/polkadot-sdk#160 & Custom Feehandler & Add destination to FeeReason Snowfork/polkadot-sdk#167Option 2: Custom Exporter + Hacking
SendXcm
traits to add the source origin as param and return the fees for burning, allow for the burning of fee more explicitly, POC with PR Descend to user origin & Burn fee from the user Snowfork/polkadot-sdk#168 & Revamp SendXcm trait to include the source origin as param and return fees(optional) for burning Snowfork/polkadot-sdk#169The text was updated successfully, but these errors were encountered: