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
{{ message }}
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Experiencing problems? Have you tried our Stack Exchange first?
This is not a support question.
Description of bug
I have a situation where I have a constant defined in my runtime (but not in any pallet) which I want to expose with the runtime itself in some way.
Specifically, there is a constant used as a multiplier in our runtime's WeightToFee implementation. This multiplier used to be part of transaction-payment's constants until #11415 converted WeightToFee into a trait.
Before this change, we were able to query api.consts.transactionPayment.weightToFee[0] to effectively obtain this constant. This allowed a client to have all the information it needed to precisely calculate fees, which is something we used very extensively in testing.
I can think of a couple ways to address this now:
Provide an RPC endpoint to query this
Create a "dummy" pallet which can provide a client-side query
Both seem like they would add a lot of bloat for what seems to be a trivial problem. Am I missing anything, or would it make sense to add a feature to address this?
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
I have a situation where I have a constant defined in my
runtime(but not in anypallet) which I want to expose with the runtime itself in some way.Specifically, there is a constant used as a multiplier in our runtime's
WeightToFeeimplementation. This multiplier used to be part oftransaction-payment's constants until #11415 convertedWeightToFeeinto a trait.Before this change, we were able to query
api.consts.transactionPayment.weightToFee[0]to effectively obtain this constant. This allowed a client to have all the information it needed to precisely calculate fees, which is something we used very extensively in testing.I can think of a couple ways to address this now:
Both seem like they would add a lot of bloat for what seems to be a trivial problem. Am I missing anything, or would it make sense to add a feature to address this?
(Sorry, this is a cross-post from this stale stack exchange post, please forgive me!)
Steps to reproduce
No response