# Ecosystem info
- `fn validate_unsigned`/`fn pre_dispatch_unsigned` in the `SignedExtension`
- Diference between `SignedExtension` and `ValidateUnsigned` traits.
- Polkadot Parachains investigation -> https://docs.google.com/spreadsheets/d/1xKu4KuLijhj-YWhvuRVKaN_Saa-v5GJ8PERUndH_-NM/edit#gid=0
- Check if anyone reimplements Extrinsic trait
- Or otherwise relies on being able to switch in their own type of Checked/UncheckedExtrinsic
- [#2160](https://github.com/paritytech/polkadot-sdk/issues/2160) might be related.
- Previous related work -> https://github.com/paritytech/polkadot-sdk/issues/365
## `fn validate_unsigned`
### Examples
#### Acala
[Source code](https://github.com/AcalaNetwork/Acala/blob/cab5cd8a8f234a0931bec4a854e805fdb896ffc6/modules/cdp-engine/src/lib.rs#L571)
```rust=
#[pallet::validate_unsigned]
impl<T: Config> ValidateUnsigned for Pallet<T> {
type Call = Call<T>;
fn validate_unsigned(_source: TransactionSource, call: &Self::Call) -> TransactionValidity {
match call {...}
}
}
```
#### Crust
[Source Code](https://github.com/crustio/crust/blob/34668d7db168fcd5aa4edd3a7b34841c15925de9/cstrml/claims/src/lib.rs#L447)
```rust=
impl<T: Config> sp_runtime::traits::ValidateUnsigned for Module<T> {
type Call = Call<T>;
fn validate_unsigned(_source: TransactionSource, call: &Self::Call) -> TransactionValidity {
const PRIORITY: u64 = 100;
...
}
}
```
Look for SignedExtension for -> https://github.com/paritytech/substrate/blob/ec3bedd5c8cd0caa77a312b53a3cf3306149276c/frame/system/src/extensions/check_genesis.rs#L55. This would give us a list of people re-implementing this.
pre-dispatch -> prepare
validate ->
validate_unsigned trait changing name too.
Try to devide between re-implementation and usage.
For extrinsics -> look for Extrinsic for
deleting validate_unsigned and pre_dispatch_unsigned functions.
This would force people to use the new stuff. It will still exist, but deprecated.
Related -> https://github.com/paritytech/polkadot-sdk/pull/2280
>...type of Checked/UncheckedExtrinsic
runtime config -> https://github.com/polkadot-fellows/runtimes/blob/7bd91e826e4b2d95f6d2ee7f6bb0f0f47d095859/system-parachains/asset-hubs/asset-hub-polkadot/src/lib.rs#L796
might break some code. If anyone is using their own, it might break. Look the TODO.
---
Hey hey! Hope everything is going well!
Wanted to reach out because I wanted to understand how you guys are using some components within your runtime. There is some refactoring being worked upon and I'd like to have a better understanding on how you're currently using this.
- Are you using `fn validate_unsigned` and `fn pre_dispatch_unsigned` from the `SignedExtensions` trait?
- Are you re-implementing the `Extrinsics` trait? Or otherwise rely on being able to switch in their own type of Checked/UncheckedExtrinsic?
I'd been looking into your repos to see if I could find any instances of these, and I could/couldn't find.
Tomorrow we have the Technical Roundtable and it'd be good to discuss it there if need be! However if you want to share some info with me beforehand, that'd be great.
---
Hey Gav!
Coming back to this, we've inspected several teams' code a lot more with the help of the data team, and I spoke with the parachain CTOs to understand the implications better. All raw data can be found [here](https://docs.google.com/spreadsheets/d/1_LXVKea8NmLvsI-Xyxm5ZGB5R8hTmMXqFrJFrEQPnB0/edit#gid=675594937).
Key takeaways are:
1. `fn validate_unsigned` and `fn pre_dispatch_unsigned` in the `SignedExtension` trait are mostly used for testing purposes or for emergency/maintenance pallets like [this one](https://github.com/UniqueNetwork/unique-chain/blob/081791eb4c218ace1b627990c5eede5c0ab46cba/runtime/common/maintenance.rs#L32) from Unique. In general nothing major got reported by anyone in the ecosystem.
2. Most usage of `fn validate_unsigned` comes directly from the `ValidateUnsigned` trait as you pointed out the other day. This is the main usage, and I wonder if given [#365](https://github.com/paritytech/polkadot-sdk/issues/365) and this refactoring, there's something we'd like to push forward in the ecosystem.
3. The `SignedExtension` trait itself is being used a bit more around the ecosystem, however the two functions being discussed are not part of the implementation. [Here's](https://github.com/galacticcouncil/HydraDX-node/blob/0056a79f89961a57c8227165ce16e927341c3253/pallets/claims/src/lib.rs#L218) an example from HydraDX to illustrate this.
4. Frontier seems to be the biggest thing to watchout for with this refactoring. We can let Wei know in advance and discuss it with him, and also alert other teams in the ecosystem using the pallet in due time.
5. Acala raised the potential issue (it's also detailed on [#2160](https://github.com/paritytech/polkadot-sdk/issues/2160#issuecomment-1793838916)) that this might need a bump on the `tx version` and hence they will need to update other things (like their ledger app). From what I gather this would not be necessary, and also we do expect to have the Polkadot Generic App ready in the next couple of months.
6. There were no concerns raised wrt re-implementation of the Extrinsics trait. Only found one instance of this being used in Avail's codebase, but it was for testing purposes.
I'm still waiting for some feedback from InvArch and some validations from Moonbeam, but wanted to send this across nonetheless.