-
Notifications
You must be signed in to change notification settings - Fork 2.6k
V14 metadata doesn't provide enough information to decode extrinsic #12929
Comments
Yeah the call was always there, but more implicit by giving you all pallets and all their calls. We should probably revisit now as we have scale-info. |
We actually use the metadata already to decode extrinsics: To get the address, call, signature and extra details needed, we do this: Currently this means that we do rely on the Perhaps we should expose those type IDs directly under pub struct ExtrinsicMetadata<T: Form = MetaForm> {
/// The type of the extrinsic.
pub ty: T::Type,
/// Extrinsic version.
pub version: u8,
/// Type of the outermost Call enum.
pub call_ty: T::Type,
/// Type of the address.
pub address_ty: T::Type,
/// Type of the extrinsic signature.
pub signature_ty: T::Type,
/// The signed extensions in the order they appear in the extrinsic.
pub signed_extensions: Vec<SignedExtensionMetadata<T>>,
} Does that sound good? In the absense of anything saying otherwise, we'll aim to get this in to V15 metadata, because it seems like a sensible addition to me. |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/stablising-v15-metadata/2819/1 |
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
To properly decode extrinsic one needs to know
Address
Signature
Call
.While all the above types are included in the
.lookup.types
, there is no way to know which one is which.At Subsquid we look at paths and type parameters .
Polkadot.js uses its own set of hardcoded assumptions none of which is guaranteed to hold.
This is practical issue which hardens the maintenance of our stack.
Steps to reproduce
No response
The text was updated successfully, but these errors were encountered: