As defined in https://github.com/paritytech/polkadot-sdk/issues/6347, we
want to run the omni-benchers overhead command in the CI to be sure that
it keeps working.

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

The page
[2-token-economics](https://research.web3.foundation/en/latest/polkadot/overview/2-token-economics.html)
is a dead link, replacing it with
[token-economics](https://research.web3.foundation/Polkadot/overview/token-economics).

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

Fix pallet-revive-uapi resolution when building pallet-revive-fixtures
contracts
follow up from https://github.com/paritytech/polkadot-sdk/pull/7844

---------

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

Changes the POV format used by pov exporter and validator. The
`pov-validator` will now work with PoVs recovered from relay chain DA
and created by the collator pov exporter.

---------

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Co-authored-by: ordian <write@reusable.software>

This brings support for declaring variables in parameters as `mut`
inside of `impl_runtime_apis!`.

---------

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

Shouldn't matter much, but this is run on every produced block so free
performance

Add missing pre-compiles 02 -> 09

[weights
changes](https://weights.tasty.limo/compare?repo=polkadot-sdk&threshold=10&path_pattern=substrate%2Fframe%2F**%2Fsrc%2Fweights.rs%2Cpolkadot%2Fruntime%2F*%2Fsrc%2Fweights%2F**%2F*.rs%2Cpolkadot%2Fbridges%2Fmodules%2F*%2Fsrc%2Fweights.rs%2Ccumulus%2F**%2Fweights%2F*.rs%2Ccumulus%2F**%2Fweights%2Fxcm%2F*.rs%2Ccumulus%2F**%2Fsrc%2Fweights.rs&method=asymptotic&ignore_errors=true&unit=time&old=master&new=pg%2Fprecompiles02_09&pallet=revive)

---------

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

Asset Hub was using the native token for benchmarking xcm instructions.
This is not the best since it's cheaper than using something in
`pallet-assets` for example.
Had to remove some restrictive checks from `pallet-xcm-benchmarks`.

I'll bring back the checks with a better framework in the future that
allows for handling multiple assets (`fungibles::*` traits).

---------

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

Set timeout to 60mins. Prevent failures like this one
https://github.com/paritytech/polkadot-sdk/actions/runs/13651327605/job/38160444244?pr=7790


Thanks!

---------

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

# Description

It is difficult to spot changes to umbrella features when reviewing,
when defined on a long line, so made sure tomls formatting will be
applied to long array lines by splitting them on multiple lines. This
will be applied to any tomls in the monorepo that is not excluded from
taplo.

## Integration

N/A

## Review Notes

Set global taplo config `array_auto_expand` to true.

---------

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

Update pallet-revive-fixtures so that it can build without looking up
dependencies from the workspace

---------

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

This PR punishes behaviors that deviate from the notification spec. When
a peer misbehaves by writing data on an unidirectional read stream, the
peer is banned and disconnected immediately.

In this PR:
- The `NotificationOutError` is enriched with termination reason and
made publically available for higher levels
- The protocol misbehavior is propagated through the `CloseDesired`
events
- The network behavior of the protocol is responsible for banning the
peer.
- The peer is banned immediately and, as a result, the reputation system
disconnects the malicious / misbehaving peer
- Logs are enriched with protocol names

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


cc @paritytech/networking

---------

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

# Description

Part of #3326 

As per title, the `pallet:getter` usage has been removed from:
- `pallet-bridge-beefy`
- `pallet-bridge-grandpa`
- `pallet-bridge-messages`
- `pallet-bridge-relayers`
- `pallet-xcm-bridge-hub-router`


polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp

---------

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

Support "latest" blocktag in ethGetLogs from_block and to_block
parameters
This is not in specs
(https://github.com/ethereum/execution-apis/blob/main/src/schemas/filter.yaml#L17)

but defined and used by 3rd parties and in some other reference docs 

See 

https://docs.metamask.io/services/reference/ethereum/json-rpc-methods/eth_getlogs/

---------

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

giving the wrong origin in `extrinsic_call` would result in:
```
   |
43 | #[benchmarks]
   | ^^^^^^^^^^^^^
   | |
   | expected associated type, found `Result<RawOrigin<...>, ...>`
   | arguments to this function are incorrect
   |
   = note: expected associated type `<T as frame_system::Config>::RuntimeOrigin`
                         found enum `Result<RawOrigin<<T as frame_system::Config>::AccountId>, <T as frame_system::Config>::RuntimeOrigin>`
note: method defined here
  --> $WORKSPACE/substrate/frame/support/src/traits/dispatch.rs
   |
   |     fn dispatch_bypass_filter(self, origin: Self::RuntimeOrigin) -> DispatchResultWithPostInfo;
   |        ^^^^^^^^^^^^^^^^^^^^^^
   = note: this error originates in the attribute macro `benchmarks` (in Nightly builds, run with -Z macro-backtrace for more info)
```

Now it results in an error message with good span.

---------

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

This PR adds a convenience extrinsic `manual_slash` for the governance
to slash a validator manually.

## Changes

* The `on_offence` implementation for the Staking pallet accepts a slice
of `OffenceDetails` including the full validator exposure, however, it
simply
[ignores](https://github.com/paritytech/polkadot-sdk/blob/c8d33396

/substrate/frame/staking/src/pallet/impls.rs#L1864)
that part. I've extracted the functionality into an inherent
`on_offence` method that takes `OffenceDetails` without the full
exposure and this is called directly in `manual_slash`
* `manual_slash` creates an offence for a validator with a given slash
percentange

## Questions

- [x] should `manual_slash` accept session instead of an era when the
validator was in the active set? staking thinks in terms of eras and we
can check out of bounds this way, which is why it was chosen for this
implementation, but if there are arguments against, happy to change to
session index
- [X] should the accepted origin be something more than just root?
Changed to `T::AdminOrigin` to align with `cancel_deferred_slash`
- [X] should I adapt this PR also against
https://github.com/paritytech/polkadot-sdk/pull/6996? looking at the
changes, it should apply mostly without conflicts

---------

Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>
Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com>

The xcm-executor will not support `ExecuteWithOrigin` from the start. It
might be implemented again in the future when more time can be spent on
it.

---------

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

## Summary
The existing fungible migration code has an issue when handling
partially unbonding accounts, leaving them in an inconsistent state.
These changes fix it by properly withdrawing overstake from unlock
chunks.

This PR also removes the `withdraw_overstake` extrinsic from
pallet-staking, as this scenario could only occur before the fungible
migration. With fungibles, over-staking is no longer possible.

## TODO
- [ ] Backport to stable2503.

---------

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

Co-authored-by: Ankan <ankan.anurag@gmail.com>

This PR makes the litep2p backend the default network backend in Kusama.

We performed a gradual rollout in Kusama by asking validators to
manually switch to litep2p. The rollout went smoothly, with 250
validators running litep2p without issues. This PR represents the next
step in testing the backend at scale.

Thanks to everyone who contributed to making this happen! A special
shoutout to the validators for their prompt support and cooperation 



While at it, the litep2p release is bumped to the latest 0.9.2, which
downgrades a spamming log to debug.


### CLI Testing Done


```
### Kusama without network backend specified
RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output
2025-03-10 14:24:18.503  INFO main sub-libp2p: Running litep2p network backend

### Kusama with libp2p
RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output --network-backend libp2p
INFO main sub-libp2p: Running libp2p network backend

### Kusama with litep2p
RUST_LOG=info ./target/release/polkadot --chain kusama --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output --network-backend litep2p
INFO main sub-libp2p: Running litep2p network backend

### Polkadot without network backend specified
RUST_LOG=info ./target/release/polkadot --chain polkadot --pruning=1000 --in-peers 50 --out-peers 50 --sync=warp --detailed-log-output
2025-03-10 14:27:03.762  INFO main sub-libp2p: Running libp2p network backend 

 ```

cc @paritytech/networking

---------

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

This PR contains few fixes for the Promote RC to final flow:
- Now the `polkadot-preapre-worker` and `polkadot-execute-worker`
artefacts will be uploaded alongside with the `polakdot` artefact (it
was missing before)
- Added missing upload of the deb package 
- Few typos fixed

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

[pallet-revive] Add support for eip1898 block notation
https://eips.ethereum.org/EIPS/eip-1898

---------

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

This PR includes:

- deduplicating some XCM decoding logic
- making use of `decode_with_depth_limit` consistently for
`VersionedXcm`
- some cleanup

**Summary:** This PR enables authoring of multiple blocks in one AURA
slot in the slot-based collator and stabilizes the slot-based collator.

## CLI Changes
The flag `--experimental-use-slot-based` is now marked as deprecated. I
opted to introduce `--authoring slot-based` instead of just removing the
`experimental` prefix. By introducing the `authoring` variant, we get
some future-proofing in case we want to introduce further options.

## Change Description
With elastic-scaling, we are able to author multiple blocks with a
single relay-chain parent. In the initial iteration, the interval
between two blocks was determined by the `slot_duration` of the
parachain. This PR introduces a more flexible model, where we try to
author multiple blocks in a single slot if the runtime allows it.

The block authoring loop is largely the same. The
[`SlotTimer`](https://github.com/paritytech/polkadot-sdk/blob/f1935bd9/cumulus/client/consensus/aura/src/collators/slot_based/slot_timer.rs#L48-L48)
now lives in a separate module and is updated with the last seen [core
count](https://github.com/paritytech/polkadot-sdk/blob/f1935bd9

/cumulus/client/consensus/aura/src/collators/slot_based/block_builder_task.rs#L231-L231).
It will then trigger rounds in the block-building loop based on the core
count.

This allows some flexibility where elastic-scaling chains can run on a
single core in quiet times. Previously, running on 1 core with a 3-core
elastic-scaling chain would result in authors getting skipped because
the `slot_duration` was too low.

## Parameter Considerations
The core logic does not change, so there are a few things to consider:
- The `ConsensusHook` implementation still determines how many blocks
are allowed per relay-chain block. So if you add arbitrary cores to an
async-backing, 6-second parachain, `can_build_upon` in the runtime will
deny block-building of additional blocks.
- The `MINIMUM_PERIOD` in the runtime needs to be configured to allow
enough blocks in the slot. A "classic" configuration of
`SLOT_DURATION/2` will lead to slot mismatches when running with 3
cores.
- We fetch available cores at least once every relay chain block. So if
a parachain runs with a 12-second slot duration and 1 fixed core, we
would still author 2 blocks if the parachain runtime allows it.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
Co-authored-by: Javier Viola <javier@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

Follow up of : #7217, #7529 

When the zombienet tests were integrated into github, it seems like the
gitlab ones remained active. But they look a lot more unstable. This
causes confusion when the same tests fail and pass at the same time
(aside from extra costs). This PR attempts to get rid of the gitlab
ones.

As proposed by Gui :)

Closes #6851 

This PR adds an `EventEmitter` trait to the XCM Executor configuration,
enabling event emission for XCM handling. The implementation introduces
three dedicated functions to emit relevant events:

- `emit_sent_event`: Emits a `Sent` event when an XCM is successfully
sent.
- `emit_send_failure_event`: Emits a `SendFailed` event when an XCM
fails to send.
- `emit_process_failure_event`: Emits a `ProcessXcmError` event when an
XCM fails during processing.

Kusama address: FkB6QEo8VnV3oifugNj5NeVG3Mvq1zFbrUu4P5YwRoe5mQN

---------

Co-authored-by: Raymond Cheung <178801527+raymondkfcheung@users.noreply.github.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Close: https://github.com/paritytech/polkadot-sdk/issues/7816

---------

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

Closes #7845

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Guillaume Thiolliere <guillaume.thiolliere@parity.io>

# Description

Chains like moonbeam work with an ED deposit of 0 (insecure-ed-0) which
is unsable with the current pallet-transaction-payment benchmark. This
PR adds an if-else case in case the existential deposit found is 0.

Bumping trie-db to latest version to pick up
https://github.com/paritytech/trie/pull/216

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

Allow using the legacy data field for GenericTransaction

#### PR Description

This pull request introduces measures to handle finality stalls by :
- notifying outdated transactions with a
[`FinalityTimeout`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/api/src/lib.rs#L145-L147)
event.
- removing outdated views from the `view_store`

An item is considered _outdated_ when the difference between its
associated block and the current block exceeds a pre-defined threshold.

#### Note for Reviewers
The core logic is provided in the following small commits:
- `ViewStore`: new method
[`finality_stall_view_cleanup`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/src/fork_aware_txpool/view_store.rs#L869-L903)
for removing stale views was added: 64267000
- `ForkAwareTransactionPool`: core logic for tracking finality stalls
added here: 7b37ea6f. Entry point in
[`finality_stall_cleanup`](https://github.com/paritytech/polkadot-sdk/blob/d821c84d/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L1096-L1136)
- Some related renaming was made to better reflect purpose/shorten the
names: 1a3a1284, a511601f. Also new method
[`transactions_finality_timeout`](https://github.com/paritytech/polkadot-sdk/blob/a511601f/substrate/client/transaction-pool/src/fork_aware_txpool/multi_view_listener.rs#L771-L790)
for triggering external events was added for `MultiViewListener`.
- `included_transactions` which basically is mapping `block hash ->
included transactions hashes`, is also used to find to included
transactions.

I also sneaked in some minor improvements:
- fixed per-transaction logging: 1572f721
- `handle_pre_finalized` method was removed, it was some old leftover
which is no longer needed: a6f84ad0

,

closes: #5482

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>
Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>

# Description

Builds up towards addressing #5497 by creating some zombienet-sdk code
infra that can be used to spin regular networks, as described in the
fork aware transaction pool testing setup added here #7100. It will be
used for developing tests against such networks, and to also spawn them
on demand locally through tooling that will be developed in follow ups.

## Integration

Node/runtime developers can run tests based on the zombienet-sdk infra
that spins frequently used networks which can be used for analyzing
behavior of various node related components, like fork aware transaction
pool.

## Review Notes

- Uses ttxt API implemented here:
https://github.com/michalkucharczyk/tx-test-tool/pull/22/files
- currently, only two test scenarios are considered: 10k future & 10k
ready txs are sent to two separate networks - one parachain and one
relaychain, asserting at the end on the finalization of all 20k txs on
both networks.

---------

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

This pr ensures that we remove the `authorization` for a runtime upgrade
if the version check failed. If that check is failing, it means that the
runtime upgrade is invalid and the check will never succeed.

Besides that the pr is doing some clean ups.

---------

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

If the inner transaction extension used inside `SkipCheckIfFeeless` are
multiples then the metadata is not correct, it is now fixed.

E.g. if the transaction extension is `SkipCheckIfFeeless::<Runtime,
(Payment1, Payment2)>` then the metadata was wrong.

---------

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

# Description

* This PR adds a new extrinsic `poke_deposit` to `pallet-proxy`. This
extrinsic will be used to re-adjust the deposits made in the pallet to
create a proxy or to create an announcement.
* Part of #5591 

## Review Notes

* Added a new extrinsic `poke_deposit` in `pallet-proxy`.
* This extrinsic checks and adjusts the deposits made for either
creating a proxy or creating an announcement or both.
* 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 for creating a proxy or to the deposit for creating
an announcement or both and `paid` otherwise (when no deposit is
changed).
* Added a new enum `DepositKind` to differentiate between proxy deposit
adjusted and announcement deposit adjusted when emitting events.
* Added tests to test all scenarios.

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

---------

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

More details
[here](https://github.com/paritytech/security/issues/103#issuecomment-2682362253)

cc https://github.com/paritytech/security/issues/103