# Upcoming Metadata V16 - Features to include in V16
**URL:** https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153
**Category:** Tech Talk
**Created:** [May 20, 2024, 2:21pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153 "2024-05-20T14:21:04Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@lexnv](https://forum.polkadot.network/u/lexnv)
#### Post date: [May 20, 2024, 2:21pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/1 "2024-05-20T14:21:05Z")
Metadata in Substrate is a scale-encoded blob containing essential information to interact with Substrate nodes generically.
### Metadata V15
Metadata V15 was stabilized nearly a year ago. This version includes support for Runtime APIs, pallet documentation, and more. Additionally, it provides a mechanism to upgrade metadata in the future through the following runtime APIs:
- [Metadata\_metadata\_versions() → sp\_std::vec::Vec;](https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/primitives/api/src/lib.rs#L832-L835) - Returns a list of supported metadata versions
- [Metadata\_metadata\_at\_version(version: u32) → Option](https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/primitives/api/src/lib.rs#L826-L830) - Returns the metadata at the specified version if it exists
An upgrade to Metadata V16 is planned for the upcoming quarters.
### Requested Features for V16
This is the tracking issue for requested features: [Metadata V16: Features to include in V16](https://github.com/paritytech/polkadot-sdk/issues/4520):
- [Enrich metadata with associated types of config traits](https://github.com/paritytech/polkadot-sdk/issues/4519) - Expose the associated types of config traits for each pallet generically. This is particularly useful for tools like [subxt](https://github.com/paritytech/subxt/pull/1566) to eliminate the need for hard-coded configurations when communicating with chains.
- [Extend metadata with deprecation](https://github.com/paritytech/polkadot-sdk/issues/4098) - Introduce a deprecation flag, potentially including the date and reason for deprecation, to announce when a particular call, storage item, or constant is deprecated
- [Encode required origin for extrinsics in metadata](https://github.com/paritytech/polkadot-sdk/issues/349) - More details can be found [here](https://github.com/paritytech/polkadot-sdk/issues/349#issuecomment-1850235455)
- [Subscribe-able runtime apis](https://github.com/paritytech/polkadot-sdk/issues/3594) - Enable subscription to accessed storage items and prefixes during runtime execution, which might necessitate metadata indicating which runtime calls are subscribable
- [pallet::dynamic\_parameter attribute](https://github.com/paritytech/polkadot-sdk/issues/3238) - Define dynamic parameters within metadata using the `pallet::dynamic_parameter` attribute
We would love to hear feedback from the ecosystem on use cases and features to be included in Metadata V16. Please share any specific metadata features you anticipate, issues with the current metadata or improvements. Any suggestions are welcomed 😃
---
### Author:  [@ntn\_x2](https://forum.polkadot.network/u/ntn_x2)
#### Post date: [May 24, 2024, 11:35am UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/2 "2024-05-24T11:35:21Z")
Not sure if it’s within the scope of what the metadata could expose, but at KILT we have been wondering about how we can re-use more code between our node and our clients (our SDK). Runtime APIs solve this halfway, as they allow code to be implemented on the node and being invoked by clients. Would there be a possibility for the metadata to expose WASM blobs that can be executed locally by a client whenever needed, without needing to involve at least one round-trip and load the server with something that can be done locally by the client? If there’s an existing solution to this problem, I’d be more than happy to know about them!
---
### Author:  [@lexnv](https://forum.polkadot.network/u/lexnv)
#### Post date: [May 24, 2024, 12:05pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/3 "2024-05-24T12:05:00Z")
The metadata is currently exposing only type information. This is something we have thought about but not articulated in an issue so far.
Having the metadata express code, even as a WASM blob, would be beneficial. For example, in subxt we rely on the `Config::Hashing` type to determine the hashing used to communicate with the substrate-based node. We’ll be able to be generic over this with the addition of the associated types of config traits in the metadata. However, if the chain uses a custom in-house built hasher, we won’t be able to generate the code for that.
I think expressing WASM code like `fn sing(message: &[u8], raw_private_key: &[u8]) -> Vec` becomes a bit problematic since there is no way to know programmatically that the WASM blob won’t expose in the output the private key. This needs a bit more thought indeed, but generally I think we could expose eventually a WASM blob.
One workaround that I can think of would be to express the WASM blob as a [CustomValueMetadata](https://github.com/paritytech/frame-metadata/blob/94e7743fa454963609763cf9cccbb7f85bc96d2f/frame-metadata/src/v15.rs#L331-L336) in the current metadata V15. Then, on the client side decode and instantiate a WASM instance from that blob of data.
I’m curious, what type of functionality would you like to share between nodes and clients? 😃
---
### Author:  [@ntn\_x2](https://forum.polkadot.network/u/ntn_x2)
#### Post date: [May 24, 2024, 12:43pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/4 "2024-05-24T12:43:37Z")
> I think expressing WASM code like `fn sing(message: &[u8], raw_private_key: &[u8]) -> Vec` becomes a bit problematic since there is no way to know programmatically that the WASM blob won’t expose in the output the private key. This needs a bit more thought indeed, but generally I think we could expose eventually a WASM blob.
So we can’t be sure the node serving the WASM blob is trusted not to serve malicious blobs? Or more of a doubt as to what should be allowed to be in a WASM blob?
Can I/we do anything to start the conversation and investigate if other people have similar needs? It looks that subxt could already benefit from such a solution, so it would already be a good argument to take some steps into trying to see how this could look like.
> One workaround that I can think of would be to express the WASM blob as a [CustomValueMetadata](https://github.com/paritytech/frame-metadata/blob/94e7743fa454963609763cf9cccbb7f85bc96d2f/frame-metadata/src/v15.rs#L331-L336) in the current metadata V15. Then, on the client side decode and instantiate a WASM instance from that blob of data.
Ok I was not aware this was a possibility. We will explore what we can do it with, thank you!
> I’m curious, what type of functionality would you like to share between nodes and clients? 😃
A very stupid example is here for the chain part ([kilt-node/runtimes/spiritnet/src/lib.rs at b0e6bf240db5137efdd58c8557f9ac6044d3ea06 · KILTprotocol/kilt-node · GitHub](https://github.com/KILTprotocol/kilt-node/blob/b0e6bf240db5137efdd58c8557f9ac6044d3ea06/runtimes/spiritnet/src/lib.rs#L1024)) and here for the SDK part ([sdk-js/packages/did/src/DidDetails/FullDidDetails.ts at 23c5b045dc7d3d587aeca5f6650736bb1218130b · KILTprotocol/sdk-js · GitHub](https://github.com/KILTprotocol/sdk-js/blob/23c5b045dc7d3d587aeca5f6650736bb1218130b/packages/did/src/DidDetails/FullDidDetails.ts#L33)). We want to understand what DID key is required to authorise what extrinsic. So every time we add a new extrinsic or pallet, we potentially have to release a new version of our SDK. Having the possibility to fetch the latest implementation from the metadata would greatly reduce maintenance efforts.
---
### Author:  [@lexnv](https://forum.polkadot.network/u/lexnv)
#### Post date: [June 5, 2024, 3:24pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/5 "2024-06-05T15:24:47Z")
I’ve created this issue in substrate to continue the discussions around the WASM blobs: [https://github.com/paritytech/polkadot-sdk/issues/4714](https://github.com/paritytech/polkadot-sdk/issues/4714)
> So we can’t be sure the node serving the WASM blob is trusted not to serve malicious blobs? Or more of a doubt as to what should be allowed to be in a WASM blob?
The node could in theory alter the WASM blob to generate malicious behaviors. For example, if the metadata contains at some point the `fn hash(private_key: &[u8]) -> Vec` a malicious node could modify the code to pass through the private\_key and leak it in the returned vector. Then, when the user submits the hash to the node, the node will gain access to the user’s private key.
---
### Author:  [@bkchr](https://forum.polkadot.network/u/bkchr)
#### Post date: [August 26, 2024, 3:46pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/6 "2024-08-26T15:46:55Z")
> [@ntn\_x2](#):
>
> Would there be a possibility for the metadata to expose WASM blobs that can be executed locally by a client whenever needed, without needing to involve at least one round-trip and load the server with something that can be done locally by the client?
You can just execute the runtime api locally in your context. This way you don’t need any extra round trip.
---
### Author:  [@carlosala](https://forum.polkadot.network/u/carlosala)
#### Post date: [August 28, 2024, 11:04am UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/7 "2024-08-28T11:04:05Z")
> [@bkchr](#):
>
> You can just execute the runtime api locally in your context. This way you don’t need any extra round trip.
I agree. I wouldn’t add any unneeded blobs to the metadata that would significantly increase its size.
---
### Author:  [@lexnv](https://forum.polkadot.network/u/lexnv)
#### Post date: [December 12, 2024, 2:48pm UTC](https://forum.polkadot.network/t/upcoming-metadata-v16-features-to-include-in-v16/8153/8 "2024-12-12T14:48:07Z")
We’re excited to share that the Metadata V16 unstable version will be exposed by RPC nodes starting with the upcoming Polkadot 2412 release. This milestone represents a step toward stabilizing Metadata V16 and expanding its capabilities.
For more details see [#4520](https://github.com/paritytech/polkadot-sdk/issues/4520).
### Key Metadata Changes in V16
1. Support for Multiple Extrinsic Versions
2. Unified Call Type
3. Renaming of Signed Extensions
4. Group Transaction Extensions by Versions
### What’s Next?
As we move closer to stabilizing Metadata V16, we’re working on introducing `PalletViewFunctions`. This important feature, currently under review in PR #4722, will further enhance the metadata capabilities.
We aim to complete stabilization by January, allowing developers to explore and test Metadata V16, and to share their feedback ahead of its final release.