-
Notifications
You must be signed in to change notification settings - Fork 668
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
XCM Runtime API fee estimation UX improvement #6126
Comments
I could implement a PoC. However, due to other current tasks, I won't be able to anytime soon (beginning of 2025, it seems). Please tag me if someone finds the suggestion sound and wants to implement a PoC themselves. I'd like to look at it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We (Unique Network's team) have been building a JS package to estimate XCM fees. Although it kind of works, the estimation process is very inconvinient. Moreover, we can only accurately estimate the execution fees. To estimate the delivery fees, we'd need to analyze each program and find the instructions that forward new programs. This requires constant maintenance of the library since, with new XCM versions, there could be new such instructions (e.g.,
InitiateAssetsTransfer
in XCM v5). It would be good to have a future-proof universal solution backed by a generic Runtime API. Also, new kinds of fees can be introduced in the future, which could require special handling similar to delivery fees (see this discussion).The current implementation of dry-running doesn't help here since if there are not enough fees inside the dry-running extrinsic/xcm-program, it will just fail without telling us how much fee asset we'd need. The current design of calling
XcmPaymentApi
first and thenDryRunApi
has proven inconvenient.Suggestion
Make the XCM executor participate in the dry-running process directly instead of relying on the different parts of its configuration, such as its Routers.
The XCM executor could record all the taken fees directly (inside the
take_fee
function). It should not fail if there are not enough fees during the dry-running; it should just set a flag about that and report an error at the very end of the program execution.If we make the XCM executor do this, we don't need to reimplement the fee calculation logic separately in the Runtime API. Instead, the
DryRunApi
should be able to read this info from the XCM executor after a program dry-running.Also, the XCM executor should record the forwarded programs directly (inside the
send
function). This will eliminate the #5878 instantly.DryRunApi
should then collect all the info it currently provides and also report all the required fees that the XCM executor tried to collect. This way, we don't need to think about different kinds of fees. It's the XCM executor's business. Users want to ensure they pay enough for everything to get their XCM program through all the chains.In the end, the
DryRunApi
would just take the needed info from the XCM executor. This means theDryRunApi
would need exactly one implementation, and any chain team that already configured the XCM executor could just plug theDryRunApi
in their Runtime.If implemented, we can remove most of the
XcmPaymentApi
methods. We'd need to preserve thequeryAcceptablePaymentAssets
method only.The text was updated successfully, but these errors were encountered: