-
Notifications
You must be signed in to change notification settings - Fork 349
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
Remove all dependencies to repository open-runtime-module-library #2969
Conversation
WASM runtime size check:Compared to target branchMoonbase runtime: 2268 KB (no changes) ✅ Moonbeam runtime: 2244 KB (no changes) ✅ Moonriver runtime: 2224 KB (no changes) ✅ Compared to latest release (runtime-3200)Moonbase runtime: 2268 KB (+308 KB compared to latest release) Moonbeam runtime: 2244 KB (+320 KB compared to latest release) Moonriver runtime: 2224 KB (+300 KB compared to latest release) |
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.
Added a few remarks. But the overall changes look good to me
Co-authored-by: Rodrigo Quelhas <[email protected]>
test/suites/dev/moonbase/test-precompile/test-precompile-xtokens.ts
Outdated
Show resolved
Hide resolved
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 left a comment, overall it looks good to me.
I did a quick search for 'orml' and there are some matches in typescript-api, but I guess they will be gone when updating the augmented api.
What does it do?
To reduce the complexity of moonbeam runtimes and maintenance work, we want to reduce the number of dependencies, and in particular the number of git directories.
We use the orml repository only fo xTokens pallet, which we added historically because at the time pallet-xcm was too limited. Now pallet-xcm has matured and is more stable than xTokens, so we want to remove the xTokens pallet.
Selectors
transferWithFee
andtransferMultiassetWithFee
no longer take thefee
parameter into account. Now, if you want to limit the maximum amount of fees, you'll have to use a different asset from the one you wish to transfer.For example, if you previously transferred an asset A and used the same asset A to pay xcm fees on the destination chain, now use another asset B to pay the fees on the destination chain (and use transfer_multi* selectors to transfer assets A and B at the same time).
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?