-
Notifications
You must be signed in to change notification settings - Fork 384
Girazoki enable native asset cross chain transfer in moonriver #1236
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
Girazoki enable native asset cross chain transfer in moonriver #1236
Conversation
…post-0.9.16-anchoring-logics-for-native-token' into girazoki-enable-native-asset-cross-chain-transfer-in-moonriver
…post-0.9.16-anchoring-logics-for-native-token' into girazoki-enable-native-asset-cross-chain-transfer-in-moonriver
…ative-asset-cross-chain-transfer-in-moonriver
runtime/moonriver/src/lib.rs
Outdated
|
|
||
| pub const TRANSACTION_BYTE_FEE: Balance = 10 * MICROMOVR * SUPPLY_FACTOR; | ||
| pub const STORAGE_BYTE_FEE: Balance = 100 * MICROMOVR * SUPPLY_FACTOR; | ||
| pub const WEIGHT_FEE: Balance = 50 * KILOWEI * SUPPLY_FACTOR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should do some basic testing to ensure this is reasonable for your use case. It appears to be taken from #1218, which is still a WIP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right in the sense that a token transfer through XCM would cost 50_000_000_000_000, or essentially, 50microMOVR. Maybe this is too low since for KSM we are charging 0.1KSM. I will increase it to match it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I increased it to 100KILOWEI. This means that for 1e9 weight (roughly, the amount needed for a token transfer in XCM) we charge 0.1milliMOVR, which I think gets us closer to what we charge for other assets
notlesh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing looks wrong to me here, but I don't have much context for the change that you're making. Maybe a short description of the PR (and any links to related upstream PRs) would help.
|
Updated the description, let me know if it feels better |
…ative-asset-cross-chain-transfer-in-moonriver
What does it do?
Enables transfer of MOVR through XCM to moonriver. For now it is not enabled in Moonbeam, but if suggested I can add it too.
Basically adds to AssetTransactors both
XcmCurrencyAdapterfor incoming assets matchingSelfReserveRepresentations, which includeOldAnchoringSelfReserveandNewAnchoringSelfReserve.The first matches incoming assets to
while the second matches incoming assets to:
Both represent our balances pallet, which is how we refer to our MOVR token. Both representations are necessary because of paritytech/polkadot#4470, which was introduced in 0.9.16 and which changes the way we receive our own token from absolute to relative view. Hence, we need to handle both pre and post 0.9.16 versions.
Additionally, we change the usage of
PalletInfotrait toPalletInfoAccess, because the latter does not use unwraps.Also, tests are added to runtime/moonriver/xcm_tests.ts sending the MOVR token.
What important points reviewers should know?
Is there something left for follow-up PRs?
What alternative implementations were considered?
Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?
What value does it bring to the blockchain users?