-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure Polkadot <> Kusama Bridge to Use Asset Conversion to Buy Execution #104
Comments
With https://kusama.subsquare.io/referenda/258 and https://polkadot.subsquare.io/referenda/122 we now have So we no longer need to manage (and periodically balance) these sovereign accounts of AHs on each respective side. But, I believe we still need to use asset conversion (i.e. E.g.: Alice transfers 10 DOT from
So, my guess is we'd use |
I think ultimately we will need #606 to make that work. Asset Conversion can publish recent rates of selected assets (e.g. KSM, USDT, ETH, etc.) and the Bridge Hub could subscribe to those. |
This is all concerning target AssetHub, not BridgeHub. I spoke to @bkontur and have more detail/context on what happens at target AH: On I guess this is ok(ish):
but it'd be better if we could use
that way, all weight "costs" the same in native token, regardless of what is used to pay.
Right now, we don't charge anything on target BH so we don't need this, but yes, we would use it if we start charging (possibly XCM HRMP delivery fee to target AH). |
Ok, so we have #105 exactly for what I described above. I guess we can close this issue then. 👍 |
* archive/call: Return a JSON-RPC object Signed-off-by: Alexandru Vasile <[email protected]> * archive/call: Adjust params Signed-off-by: Alexandru Vasile <[email protected]> * Adjust sudo_sessionKeys Signed-off-by: Alexandru Vasile <[email protected]> * Update src/api/archive_unstable_call.md Co-authored-by: James Wilson <[email protected]> --------- Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: James Wilson <[email protected]>
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
…aritytech#104) * mute warnings from sub2sub module+relay * cargo fmt --all
close on behalf of #105 |
At least initially, we expect the Polkadot<>Kusama bridge to maintain some assets on each side with which to buy execution. For example, we'd expect the Kusama Asset Hub (AH) to have some DOT in its sovereign account on Polkadot's AH, and then charge users extra KSM for transacting on Kusama's AH over the bridge to Polkadot's AH, where the XCM program would withdraw some DOT from its sovereign account to pay for execution locally.
This has some flaws, like ensuring that the correct additional amount is withdrawn on the Kusama side, and that it will be sufficient given the current weight-to-fee rate on Polkadot's AH, and the fact that this account would need to be occasionally topped up via governance.
By using asset conversion, the bridge could buy execution (accurately) in any asset it sends over, provided there is a pool for it (e.g. a pKSM <> DOT pair).
The text was updated successfully, but these errors were encountered: