# Conflicts:
#	substrate/frame/staking/src/pallet/impls.rs

Adds `checked_sqrt` function to `FixedPointNumber` and renames `const fn
try_sqrt` in the `implement_fixed` macro to `const fn checked_sqrt`.

CLOSES: #8214 

## Integration

Any projects that use the **const** function `try_sqrt` from `FixedI64`,
`FixedU64`, `FixedI128`, `FixedU128` should now use `checked_sqrt`.

## Review Notes

- renamed the const `try_sqrt` with `checked_sqrt`
- updated tests for new name
- added `checked_sqrt` to impl of `FixedPointNumber`

We keep both the const version along with adding the non-const version
of `checked_sqrt` so that we can now access `checked_sqrt` from
associated types that implement `FixedPointNumber` without breaking all
of the uses of `sqrt` that rely on it being const.

---------

Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

Core devs should be okay to review everything under `substrate/frame/*`?
cc: @Kianenigma



---------

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

# Description

We made changes to `sc-tracing-proc-macro` in #7464 which weren't
carried to the prdoc, so once stable2503 got released there wasn't a
bump for `sc-tracing-proc-macro`, and now it is needed for updating
`parachain-template` repo to 2503. It seems that the prdoc check did not
catch the missing required bump (it might be because the change was in a
`proc-macro` crate).

## Integration

N/A

## Review Notes

Planning to update stable2503 prdocs retroactively (so the change itself
doesn't count for next patch release), and we should request either way
a force bump for the following crates:

1. `sc-tracing-proc-macro`
2. `sc-tracing` (depends on 1.)
3. `polkadot-sdk` (depends on 1. & 2.)

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>

# Description

Documentation for `pallet::vesting::{vested_transfer,
force_vested_transfer}` mentions the emission of a `VestingCreated`
event, which did not exist. This PR adds it.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Dónal Murray <donal.murray@parity.io>

Just a small doc improvement.

---------

Co-authored-by: Robert <robert@gonimo.com>
Co-authored-by: command-bot <>

# Description
This PR resolves issue #8236.

I recently graduated from PBA, and during one of our sessions,
[@shawntabrizi

](https://github.com/shawntabrizi) pointed out an
important issue related to error handling in Rust.

When using let _ = some_fallible_function();, if the result is not
followed by a ?, the error is silently swallowed without any warning or
compiler feedback.

In contrast, if we don’t use let _ = and forget to add a ?, the compiler
will correctly emit a warning or error — helping the developer catch the
issue early.

This behavior can easily lead to bugs going unnoticed and makes error
handling less reliable, especially for beginners following examples.


## Integration
This PR introduces no functional or logical changes, and therefore can
safely be integrated into existing downstream projects without
additional adjustments.

From my point of view, this issue can be classified as something like
`I4-Silent`.

## Review Notes

I went through all occurrences of `let _ =` with a fallible function.
Some of them return values tagged as `#[must_use]`. In these cases, I
retained the underscore operator intentionally _(see:
`polkadot/node/core/av-store/src/lib.rs` lines: 1099 & 1108,
`polkadot/xcm/xcm-builder/src/currency_adapter.rs` line: 217,
`substrate/frame/contracts/src/wasm/mod.rs` line: 360,
`substrate/frame/revive/src/wasm/mod.rs` line: 307)_.

Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

Pallet view functions are no longer marked as experimental, and their
use is suggested starting from this PR.

Your feedback is more than welcome.

See
[docs](https://paritytech.github.io/polkadot-sdk/master/frame_support/pallet_macros/attr.view_functions_experimental.html)
for a quick introduction. For more context, you can look at:

- #4722 
- #7412 
- #7830 : discussion on possible changes to pallet view functions

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

part of https://github.com/paritytech/polkadot-sdk/issues/3743

## Motivation

This PR removes the need for defining `RuntimeEvent` in the `Config`
trait of a pallet. It uses associated type bound feature under the hood
to make sure that `Event` of the pallet is convertible to the aggregated
runtime event type `frame_system::RuntimeEvent`.

This is an initial PR for `RuntimeEvent` type and will be followed with
other types, e.g `RuntimeCall`. As a demo, example pallets' config
definition is updated to use this feature.

With this change, we can do this (and have support for events):

```rs
#[pallet::config]
pub trait Config: frame_system::Config {
}
```

instead of this:

```rs
#[pallet::config]
pub trait Config: frame_system::Config {
        /// Overarching event type.
       type RuntimeEvent: From<Event<Self>> + IsType<<Self as frame_system::Config>::RuntimeEvent>;
}
```

The latter will emit deprecation warnings and is redundant.

polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

This PR fixes an issue with the sha256 checksums generated for the macOS
bins, as after the bins renaming it needs to be re-generated.

- Add gas_consumed in strace logs
- Add genesis config
- Mapped dev accounts in kitchensink genesis

One can test a local westend with endowed and mapped accounts with the
following approach

```sh
cargo build -p asset-hub-westend-runtime
chain-spec-builder -c /tmp/ah-westend-spec.json \
  create \
  --para-id 1000 \
  --relay-chain dontcare \
  --runtime ./target/debug/wbuild/asset-hub-westend-runtime/asset_hub_westend_runtime.wasm \
  named-preset development

# Endowed
# Alith:
# H160: 0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac
# SS58: 5CfCLa2N85aH2tUKT48LmRSGNx27DnJUayMXyiwqvvcU97VN2sk
# Private key (ecdsa): 0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133

# Alice:  (subkey inspect //Alice)
# SS58: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
# Private key (sr2259): 0xe5be9a5092b81bca64be81d212e7f2f9eba183bb7a90954f7b76361f6edb5c0a

jq '.genesis.runtimeGenesis.patch.balances.balances = [
    ["5CfCLa2N85aH2tUKT48LmRSGNx27DnJUayMXqvvcU97VN2sk", 1000000001000000000],
    ["5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY", 1000000001000000000]
  ]
| .genesis.runtimeGenesis.patch.revive.mappedAccounts = [ 
    "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY"
]
' /tmp/ah-westend-spec.json >~/ah-westend-spec.json
```

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Update the gas allowance of the `TransferToken` related commands. This
also means that the default fee needs to be increased as well as a
migration.

# Migration
In production mainnet to ensure no downtime, instead of increasing the
fee to account for the new gas fee, we will instead decrease the gas
cost so that it will not require a fee increase.

The pre remote fee in Wei:
```python
(185_000 + 100_000) * 10_000_000_000 + 250_000_000_000_000
> 3100000000000000
```
We are increasing the gas to 200k. 

The post remote fee Wei:
```python
(185_000 + 200_000) * 10_000_000_000 + 250_000_000_000_000
> 4100000000000000
```

This effectively increases the price for the end users transaction by
32%. Taking the inverse of 32 percent means we can decrease the gas cost
by ~74%. The migration script plays it safe and decreases it to 70%. The
post migration `try-runtime` check asserts that the new fee calculated
with the increased gas can is less than or equal to the old fee pre the
gas change.

# TODO
- [x] Add migration to half fee on bridge on start-up
- [x] Test in prod with chopsticks

# Testing
Tested with chopsticks on westend.

```console
$ npx @acala-network/chopsticks try-runtime \
  --endpoint wss://westend-bridge-hub-rpc-tn.dwellir.com \
  --runtime bridge_hub_westend_runtime.compact.wasm \
  --checks PreAndPost \
  --db westend-cache.sqllite \
  --disable-spec-check
```

Output
```console
$ cat output.log | grep ethereum_system
  ethereum_system::migration   INFO: Agents and channels are initialized. Initialization will not run.
  ethereum_system::migration   INFO: Ethereum system already initialized. Skipping.
  ethereum_system::migration   INFO: Pre fee per gas migration: pricing parameters = PricingParameters { exchange_rate: , rewards: Rewards { local: 1000000000000, remote: 1000000000000000 }, fee_per_gas: 20000000000, multiplier:  }, remote_fee_v1 = 8700000000000000, remote_fee_v2 = 5000000000000000
  ethereum_system::migration   INFO: Fee per gas migrated from 20000000000 to 14000000000.
  ethereum_system::migration   INFO: Post fee per gas migration: pricing parameters = PricingParameters { exchange_rate: , rewards: Rewards { local: 1000000000000, remote: 1000000000000000 }, fee_per_gas: 14000000000, multiplier:  } remote_fee_v1 = 6390000000000000 remote_fee_v2 = 3800000000000000
```

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: ron <yrong1997@gmail.com>

Authorize int discriminants for pallet::error

Why?
The raw hex value shows up in tools like polkadotjs, being able to
quiclkly scan the src code to find out what error was triggered can be
very useful, especially when the enum is large like in pallet-revive

e.g:

```rust

#[pallet::error]
#[repr(u8)]
pub enum Error<T> {
    /// Invalid schedule supplied, e.g. with zero weight of a basic operation.
    InvalidSchedule = 0x01,
    /// Invalid combination of flags supplied to `seal_call` or `seal_delegate_call`.
    InvalidCallFlags = 0x02,
    /// The executed contract exhausted its gas limit.
    OutOfGas = 0x03,
    /// ...
}
```

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Yet Another Parachain ported onto the latest master branch.

---------

Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: georgepisaltu <george.pisaltu@parity.io>
Co-authored-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: ordian <noreply@reusable.software>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: ordian <write@reusable.software>
Co-authored-by: Bastian Köcher <git@kchr.de>

# Description

The `assert_expected_events` does not correctly check event fields. Even
though the provided field values do not match, the macro did not raise
an error.

## Review Notes

The `meet_conditions` variable kept being reset to true, which means
that conditions not met would be overwritten with a positive value.

Closes: https://github.com/paritytech/polkadot-sdk/issues/2460

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>

# Description

Close #496

Make min_peers_to_start_warp_sync configurable.

In our project we want to use this to allow warp syncing a parachain
using only 1 trusted bootnode. Currently we are overriding the
`MIN_PEERS_TO_START_WARP_SYNC` variable directly, but that also changes
the value when warp syncing the relaychain, and that doesn't look safe.

## Integration

This PR keeps the old behavior by default, but parachain configs that
use `prepare_node_config` function from cumulus will use 1 peer.

## Review Notes

Intentionally not adding this to the CLI because I don't need it to be
configurable by users, only by project developers.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

resolves #7517 

### Issues

#### 1. Compile-Time vs Runtime Rank Mismatch
- **`promote_fast` Benchmark** uses mock runtime's `MaxRank` during
benchmark generation while allowing runtime overrides. Creating
potential parameter mismatch between benchmark metadata(i.e. generated
`r` values) and runtime configuration(i.e. `T::MaxRank`).


#### 2. Static Rank Assumptions
- **`bump_demote` Benchmark** initialized members at rank 2, making it
incompatible with `MaxRank=1` configurations
- **`promote` Benchmark** contained hardcoded rank values (1 → 2) which
fails for `MaxRank=1`


## Changes

#### Dynamic Rank Clamping
```rust
// promote_fast
// Get target rank for promotion.
let max_rank = T::MaxRank::get();
let target_rank = (r as u16).min(max_rank);

// promote
// Set `to_rank` dynamically based on `max_rank`.
let to_rank = (current_rank + 1).min(max_rank);

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Adding this for now to unblock the CI. I will investigate if it is a
real issue or not after or during
https://github.com/paritytech/polkadot-sdk/pull/8127

Part of #6504

---------

Co-authored-by: Giuseppe Re <giuseppe.re@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

# Description
From issue #8028 

Add --locked flag to cargo install occurrences in README files across
the repository. This change helps prevent dependency resolution issues
that can occur when using cargo install without version locking,
ensuring more consistent and predictable builds for users.

The --locked flag ensures cargo uses the exact dependency versions from
Cargo.lock rather than recalculating dependencies, which can sometimes
result in breaking changes if a minor update occurs in a dependency.
This PR adds the flag to multiple READMEs that become public-facing for
crates published on crates.io.

Co-authored-by: Bastian Köcher <git@kchr.de>

Keep calm and stand still, it's a hijacking of PR #3689 by @koute

. The
original description follows; please refer to the original PR for the
past discussions.

--- 8< --- cut here --- 8< ---

This PR refactors the way the host functions are defined.

Previously the way a given type was marshalled through the host <->
runtime boundary was hardcoded for every type by the virtue of it
implementing the relevant conversion traits.

This had two major consequences:
* It was not obvious how a given type is going to be passed just by
looking at its type alone, masking potentially expensive marshalling
strategies. (For example, returning `Option<u32>` was done through the
SCALE codec and involved extra memory allocations!)
* It was not possible to use multiple marshalling strategies for a
single type, making some of the future improvements we'd like to do
(e.g. move the runtime memory allocator into the runtime) very hard to
do.

So this PR disentangles this mess and makes the marshalling strategies
explicit. This makes it much more clear how a given type in a given host
function is marshalled, and also makes it possible to use different
marshalling strategies for the same type in different host functions.

Before this PR you'd define a host function like this:

```rust
    #[runtime_interface]
    trait MyInterface {
        fn say_hello_world(name: &str) {
            println!("Hello {name}!");
        }
    }
```

and after this PR you'll define it like this:

```rust
    #[runtime_interface]
    trait MyInterface {
        fn say_hello_world(name: PassFatPointerAndRead<&str>) {
            println!("Hello {name}!", name);
        }
    }
```

In this case the strategy for passing the `&str` is now explicitly
specified (`PassFatPointerAndRead`). Note that the *actual* API
generated by this macro and the way arguments are accessed is completely
unchanged! The `#[runtime_interface]` machinery automatically "strips"
away the marshalling strategy wrappers, so neither the body of the
`say_hello_world` function here nor its callers need to be changed.

This is a breaking change only for people who use `#[runtime_interface]`
to define their own custom host functions.

---------

Co-authored-by: Jan Bujak <jan@parity.io>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

# Description

- changed conversions based on `as` operator to `usize::try_from` in
`polkadot-runtime-parachains`

## Integration

N/A

## Review Notes

N/A

---------

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Bastian Köcher <info@kchr.de>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: Guillaume Thiolliere <guillaume.thiolliere@parity.io>

/cmd with the `--clean` flag should clean up the old comments but still
run the job

# Description

* This PR adds a new extrinsic `poke_deposit` to `pallet-society`. This
extrinsic will be used to re-adjust the deposits made in the pallet to
create a bid after AHM.
* Part of #5591 

## Review Notes

* Added a new extrinsic `poke_deposit` in `pallet-society`.
* Added a new event `DepositPoked` to be emitted upon a successful call
of the extrinsic.
* Although the immediate use of the extrinsic will be to give back some
of the deposit after the AH-migration, the extrinsic is written such
that it can work if the deposit decreases or increases (both).
* The call to the extrinsic would be `free` if an actual adjustment is
made to the deposit and `paid` otherwise.
* Added tests to test all scenarios.
* Added benchmark

## TO-DOs
* [x] Run CI cmd bot to benchmark

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Migrate pipeline from gitlab to gha.

---------

Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>

Update bn128 benchmarks

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR modifies the tx broadcast logic. Previously, we relied on the
import notification stream to fetch the latest available block. In this
revision, we use the available information of the `client.info()` to
prefix the import notification stream.

The change is needed because chains could be started with `InstantSeal`,
which would not produce blocks until they encounter transactions.

Closes: https://github.com/paritytech/polkadot-sdk/issues/8157

cc @paritytech/subxt-team

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

https://github.com/paritytech/polkadot-sdk/issues/7731

TODO:
- [x] Merge [this](https://github.com/paritytech/polkadot-sdk/pull/7986)
beforehand. It'll add some simplifications in the runtime (especially
for tests)
- [x] add more runtime tests
- [x] PRDoc

This PR replaces `parity/base-bin ` with the `paritytech/base-bin` image
in the docker files for `polkadot`, `polkadot-parachain` and general
one. And fixes few typos in the CI flows

Closes: https://github.com/paritytech/release-engineering/issues/256

For testing multi-hops transfer of PNA from Penpal to Ethereum, the
runtime configurations on Penpal have been revamped, including:

- Allow to teleport native asset from/to AH
- Allow to use native asset to pay fees
- Allow unpaid execution from relay chain for sudo calls

It's required for https://github.com/Snowfork/snowbridge/pull/1419 to
setup a local test environment to transfer PNA from third-party
parachains. It demonstrates that a one-click tranfer from a Parachain to
Ethereum is possible. In this case, the first hop-from Penpal to AH, is
teleport-based, while the next hop-from AH to Ethereum, is
reserved-based.

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>

Relates to: https://github.com/polkadot-fellows/runtimes/issues/651
Already used by: https://github.com/polkadot-fellows/runtimes/pull/626

# Description

This PR introduces a `LocationAsSuperuser` struct that implements
`ConvertOrigin` to allow some `Location` chosen by the XCM configuration
to act as Root on the local chain.

Implementation is generic over `Location` but was created for purposes
of allowing AssetHub system chain (by other system chains and relay
chains) to execute Root level extrinsics like `authorize_upgrade` on
them.

## TODO
* [ ] backport to stable2412
* [ ] backport to stable2503

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>

This enables the HTTP support for the OCW.


Closes: https://github.com/paritytech/polkadot-sdk/issues/8203

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

# Description

Moved the Rococo and Westend bridge- and asset- hub bridge primitives
into cumulus/parachains/runtimes/rococo(westend)/bridge-primitives, as
well as chain-rococo and chain-westend into polkadot/runtime as per the
third task of [this
issue](https://github.com/paritytech/parity-bridges-common/issues/2950)

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This pull request adds support to `ParachainBlockData` to support
multiple blocks at once. This basically means that cumulus based
Parachains could start packaging multiple blocks into one `PoV`. From
the relay chain POV nothing changes and these `PoV`s appear like any
other `PoV`. Internally this `PoV` then executes the blocks
sequentially. However, all these blocks together can use the same amount
of resources like a single `PoV`. This pull request is basically a
preparation to support running parachains with a faster block time than
the relay chain.

This changes the encoding of `ParachainBlockData`. However, encoding and
decoding is made in a backwards and forwards compatible way. This means
that there is no dependency between the collator and runtime upgrade.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

# Description

Moved the Rococo and Westend bridge- and asset- hub bridge primitives
into cumulus/parachains/runtimes/rococo(westend)/bridge-primitives, as
well as chain-rococo and chain-westend into polkadot/runtime as per the
third task of [this
issue](https://github.com/paritytech/parity-bridges-common/issues/2950)

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

# Description

Moved the internal folder of bp-bridge-hub-cumulus as per the last task
of [this
issue](https://github.com/paritytech/parity-bridges-common/issues/2950)
and refactored some constants into parachains-common. No implementation
changes (external package name remains bp-bridge-hub-cumulus).

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Fixes https://github.com/paritytech/polkadot-sdk/issues/8190

Remove useless `#[no_mangle]` from the panic handler which screws up the
panic handling machinery on recent versions of Rust.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

closes https://github.com/paritytech/polkadot-sdk/issues/6344.
related https://github.com/paritytech/substrate/pull/14048.

---

## Overview
Post-AHM, RC will no longer have validator exposure information, as all
of it will move to AH alongside `pallet-staking`. Currently, we use
`Exposure` to identify a validator when an offence report is received.
After this change, we’ll only need to check whether the validator exists
in the session.

Also, the storage map `pallet-offences::Reports` depends on the
`Exposure` type and is heavily bloated (and never cleared). There was
[some work](https://github.com/paritytech/substrate/pull/14048) to clean
it up, but it was never completed. Replacing `Exposure` with `Existence`
would make the old storage undecodable, and migrating it would be a
pain. The `pallet-offences` storage layout needs to be redesigned, and I
didn’t want to make any rushed decisions there that could lead to
long-term issues.

Instead, this PR introduces a new type, `ExistenceOrLegacyExposure`,
with a custom encoder/decoder that can handle both the legacy `Exposure`
and the new `Existence` type.

It also introduces `ExistenceOf` and `ExistenceOrLegacyExposureOf`,
which replaces `ExposureOf`. With this change, runtimes can be
configured to identify a validator based solely on their presence,
without needing full exposure data.

This is useful when configuring historical sessions. For example:
```
impl pallet_session::historical::Config for Runtime {
	type FullIdentification = pallet_staking::Existence;
	type FullIdentificationOf = pallet_staking::ExistenceOf<Runtime>;
}
```

## Backward Compatibility

For existing runtimes that still depend on the Exposure type in
pallet-offences — typically configured like this:

```
impl pallet_offences::Config for Runtime {
        ...
	type IdentificationTuple = pallet_session::historical::IdentificationTuple<Self>;
}
```

Where `IdentificationTuple` is defined as:
```
pub type IdentificationTuple<T> =
	(<T as pallet_session::Config>::ValidatorId, <T as Config>::FullIdentification);

```

You should now use `ExistenceOrLegacyExposureOf`. This type includes a
custom encoder/decoder that supports both the legacy `Exposure` and the
new `Existence` types.

This compatibility layer is essential to ensure the `Offences::Reports`
storage map can still decode older entries.


## TODO
- [x] TryStateCheck to see existing offence report decodes correctly.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>