-
Notifications
You must be signed in to change notification settings - Fork 248
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
ChargeAssetTxPayment
: support providing u32 or MultiLocation in default impl
#1162
Comments
ChargeAssetTxPayment
: support providing u32 _or_ MultiLocation in default implChargeAssetTxPayment
: support providing u32 or MultiLocation in default impl
@jsdw I looked into this a bit, but cannot find the
Am I doing something wrong? |
Polkadot doesn't have it (you can't have different types of assets on Polkadot, only DOTs, so no need for it there); Polkadot instaed has The default substrate node ( |
Oh yeah, you are right, I can see it via |
Putting another thought on options out there: We make Then, concrete instances of this can decide what the asset type is. Then, for our
Maybe we should do 1 and 2. Specifically I mean:
I think this has a nice balance of:
I'm not a huge fan of adding a type to Config, but the alternative is just adding some extra generic param on |
See https://github.com/bee344/subxt/tree/anp-asset-conversion also; a custom impl that might shed some light on things too. |
@jsdw I like the approach you proposed and implemented it so far, but I am not sure if we should provide a complete copy of the |
Pulling in the crate looks like it's fairly heavy in terms of deps unfortunately, eg:
I'd rather avoid hiding this behind substrate-compat if possible, because I don't want to encourage or force anybody to need that feature flag for doing anything in Subxt ideally, so offhand I think we have two options:
Might be worth trying both of these to see what they are like, and if we go for 2 it'd be good to double check that it works as expected too :) |
ChargeAssetTxPayment
is generic over the asset ID type. On the kitchensink runtime it'su32
, and so that's what was implemented (actually this was done a while ago). On Asset Hub, it'sMultiLocation
.Subxt decides which signed extensions from the provided ones to use based on their names. Since the name is the same here and yet the types/encoding is different, we can't just add some other signed extension which supports MultiLocations to the list.
Instead, we can use the metadata in the
ChargeAssetTxPayment
extension to see what the asset ID type is, and have special handling foru32
orMultiLocation
. If other chains use different parameters for the extension, then those won't be supported and they will have to implement their own version.Alternative
The alternative option is to add an
AssetId
or something to theConfig
, and then use this to determine the type in theChargeAssetTxPayment
signed extension impl. This would generally be cleaner, but has the downsides of:Config
a little more complex; one more type to know how to configureConfig
impl to be used across these different chains, rather than one config that will work with both.Advantages though would be:
MultiLocation
(and then ignore one or the other. It's more "correct".There might be a middle ground option too wherein we provide only one API to add an Asset ID, and accept some type which impls
EncodeAsType
, and then use the signed extension metadata to try to encode it appropriately, or error otherwise. No extra Config type or extra API needed, but the downside that it's much easier to provide invalid types.I'm going back and forth on which option is best here.
The text was updated successfully, but these errors were encountered: