(Please, do not merge until SA, reverted and restored of
https://github.com/paritytech/polkadot-sdk/pull/4944)

Original PR with more context:
https://github.com/paritytech/parity-bridges-common/pull/2211
Relates to:
https://github.com/paritytech/parity-bridges-common/issues/2210

## TODO

- [x] fresh weighs for `pallet_bridge_messages`
- [x] add `try_state` for `pallet_bridge_messages` which checks for
unpruned messages - relates to the
[comment](https://github.com/paritytech/parity-bridges-common/pull/2211#issuecomment-1643224831)
- [x] ~prepare migration, that prunes leftovers, which would be pruned
eventually from `on_idle` the
[comment](https://github.com/paritytech/parity-bridges-common/pull/2211#issuecomment-1643224831)~
can be done also by `set_storage` / `kill_storage` or with
`OnRuntimeUpgrade` implementatino when `do_try_state_for_outbound_lanes`
detects problem.

## Open question

- [ ] Do we really need `oldest_unpruned_nonce` afterwards?
- after the runtime upgrade and when `do_try_state_for_outbound_lanes`
pass, we won't need any migrations here
    - we won't even need `do_try_state_for_outbound_lanes`
- please check comments bellow:
https://github.com/paritytech/polkadot-sdk/pull/4944#discussion_r1666737961

---------

Signed-off-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Serban Iorga <serban@parity.io>
Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com>
Co-authored-by: command-bot <>

Following this:
https://github.com/paritytech/polkadot-sdk-parachain-template/pull/11

---------

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

## Context

Currently, many crates have no readme files, even though they are public
and available on crates.io.
Others have just a couple of words that does not look super presentable.

Even though probably nobody starts a journey with `polkadot-sdk` or its
documentation with a readme of a random low-level crate, I think it
would look more mature to have a little better readmes there.

So, in an attempt to improve [the
aesthetics](https://github.com/paritytech/eng-automation/issues/10) of
`polkadot-sdk`, I propose a set of consistent, branded, better-looking
readmes for all published crates.

## What's inside

- ~~New readme files for published crates.~~
- A python script to generate new readmes, for the crates that have
none.
  - It will skip crates that do have a readme, and private crates.
- Added a new image asset to the repo - logo with a background.
- The main readme of the repo uses a [nice
trick](https://github.com/paritytech/polkadot-sdk/blob/ce6938ae/README.md?plain=1#L4-L5)
to accompany both light and dark modes - but that doesn't work on
`crates.io` so a single logo with a background is needed.

## Example

### Current

![Screenshot 2024-08-04 at 16 13
36](https://github.com/user-attachments/assets/3ae0881d-0f40-4614-9d2c-3c95029f0820)

### Changed

![Screenshot 2024-08-04 at 16 12
28](https://github.com/user-attachments/assets/fa7eadc8-aec8-4f77-84d9-54d63ce189cd)

This is a heavily modified and stripped down version of
`pallet_contracts`. We decided to fork instead of extend the old pallet.
Reasons for that are:

- There is no benefit of supporting both on the same pallet as the
intended payload for the new pallet (recompiled YUL) will be using a
different ABI.
- It is much easier since it allows us to remove all the code that was
necessary to support Wasm and focus fully on running cross compiled YUL
contracts.

**The code is reviewable but can't be merged because it depends on an
unreleased version of PolkaVM via git.**

## Current state

All tests are passing and the code is not quick and dirty but written to
last. The work is not finished, though. It is included in the
`kitchensink-runtime` and a node can be built. However, we merge early
in order to be able to start testing other components as early as
possible.

Outstanding changes are tracked here and will be merged separately:
https://github.com/paritytech/polkadot-sdk/issues/5308

## Syscall Interface

The syscall interface is best explored by generating the docs of this
crate and looking at the `SyscallDoc` trait. Arguments are passed in
registers a0-a5 in the order they are listed. If there are more than 6
arguments (call, instantiate) a pointer to a packed struct of the
arguments is expected as the only argument. I plan to create variants of
those syscalls with less arguments specifically for YUL.

Functions are just referenced by their name as ASCII within the PolkaVM
container. Rather than by a syscall number as it was the case in the
last implementation.
 

## Changes vs. `pallet_contracts`

The changes are too numerous to list them all here. This is an
incomplete list:

- Use PolkaVM instead of wasmi to execute contracts
- Made Runtime generic over a new `Memory` trait as we can't map memory
directly on PolkaVM anymore
- No static verification on code upload. Everything is a determinstic
runtime failure
- Removed all migrations and reset the pallet version
- Removed the nonce storage item and instead use the deployers account
nonce to generate a unique trie
- We now bump the deployers account nonce on contract instantiation to
they are bumped even within a batch transaction
- Removed the instantiation nonce host function: We should add a new
`instantiate` variant as a replacement for thos
- ContractInfoOf of uses the indentity hasher now
- Remove the determinism feature: User of that feature should switch to
soft floats
- The `unstable` attribute has been replaced by a `api_version`
attribute to declare at which version an API became available
	- leaving out that attribute makes the API effectively unstable
- a new `api_version` field on the CodeInfo makes sure that old
contracts can't access new APIs (necessary due to lack of static
verification.
- Added a `behaviour_version` field to CodeInfo that can used if we need
to introduce breaking changes and keep the old behaviour for existing
contracts
- Unified storage vs. transient and fixed vs. variable sized keys all
into one set of multiplexing host functions
- Removed all contract observeable limits from the `Config` trait and
instead hardcode them
- Removed the Schedule
- Removed all deprecated host functions
- Simplify chain extension as preperation for making it a pre-compile

---------

Co-authored-by: command-bot <>

# Description
Updates `template.rs` to reflect the two OZ templates available and a
short description

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [x] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
* External contributors: ask maintainers to put the right label on your
PR.
* [x] I have made corresponding changes to the documentation (if
applicable)

---------

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

I'm not sure if this is exactly what
https://github.com/paritytech/polkadot-sdk/issues/3537 meant, but I
think it should be fine to wait for relay chain before initializing
parachain node fully, which removed the need for background task and
extra hacks throughout the stack just to know where warp sync should
start.

Previously there were both `WarpSyncParams` and `WarpSyncConfig`, but
there was no longer any point in having two data structures, so I
simplified it to just `WarpSyncConfig`.

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

There are numerous reasons for invalid imports, most of them would
likely be caused by bugs. On the other side, dispute distribution
handles all connections fairly, thus there is little harm in keeping a
problematic connection open.

---------

Co-authored-by: eskimor <eskimor@no-such-url.com>
Co-authored-by: ordian <write@reusable.software>

This PR backports regular version bumps and `prdoc` reorganisation from
the `stable2407` release branch to master

Add the Polkadot Coretime chain-spec to the directory with the other
system chain-specs.

This is the chain-spec used at genesis and for which the genesis head
data was generated.

It is also included in the assets for fellowship [release
v1.3.0](https://github.com/polkadot-fellows/runtimes/releases/tag/v1.3.0)

This PR aims to make the logging from the peer store a bit more clear.

In the past, we aggressively produced warning logs from the peer store
component, even in cases where the reputation change was not malicious.
This has led to an extensive number of logs, as well to node operator
confusion.

In this PR, we produce a warning message if:
- The peer crosses the banned threshold for the first time. This is the
actual reason of a ban
- The peer misbehaves again while being banned. This may happen during a
batch peer report

cc @paritytech/networking 

Part of: https://github.com/paritytech/polkadot-sdk/issues/5379.

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: Dmitry Markin <dmitry@markin.tech>

Just fixing the beefy primitives link to the right one after moving
these primitives to `consensus`

Related to https://github.com/paritytech/polkadot-sdk/issues/5210

Migrated the following scripts to GHA
- test-doc
- test-rustdoc
- build-rustdoc
- build-implementers-guide
- publish-rustdoc (only runs when `master` is modified)

Resolves paritytech/ci_cd#1016

---

Some questions I have:
- Should I remove the equivalent scripts from the `gitlab-ci` files?

---------

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

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

If a new block is generated between these 2 lines:

```
  const proof = await apis[nodeName].rpc.mmr.generateProof([1, 9, 20]);

  const root = await apis[nodeName].rpc.mmr.root()
```

we will try to verify a proof for the previous block with the mmr root
at the current block. Which will fail.

So we generate the proof and get the mmr root at block 21 for
consistency.

We preallocated the approvals field in the ApprovalEntry by up to a
factor of two in the worse conditions, since we can't have more than 6
approvals and candidates.len() will return 20 if you have just the 20th
bit set.
This adds to a lot of wasted memory because we have an ApprovalEntry for
each assignment we received

This was discovered while running rust jemalloc-profiling with the steps
from here: https://www.magiroux.com/rust-jemalloc-profiling/

Just with this optimisation approvals subsystem-benchmark memory usage
on the worst case scenario is reduced from 6.1GiB to 2.4 GiB, even cpu
usage of approval-distribution decreases by 4-5%.

---------

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

Backport fixes from
https://github.com/polkadot-fellows/runtimes/pull/426

This PR fixes the issue with the publishing flow of the
`chain-speck-builder` image
Closes: https://github.com/paritytech/release-engineering/issues/219

## Before

<img width="320px"
src="https://github.com/user-attachments/assets/27c4c50b-632b-4a3b-a154-0e828a1ac650"/>

## After

<img width="320px"
src="https://github.com/user-attachments/assets/314954fa-7f49-415d-82dd-a9a99983a283"/>

The CI isn't happy with the amount of output:
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7035621/raw

---------

Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

There was no need for it to be `&mut self` since block import can happen
concurrently for different blocks and in many cases it was `&mut Arc<dyn
BlockImport>` anyway :man_shrugging:

Similar in nature to
https://github.com/paritytech/polkadot-sdk/pull/4844

Fix https://github.com/paritytech/polkadot-sdk/issues/5184

`owner` can set himself as a `freezer` and freeze the asset so
requirement is not really needed. And requirement is not implemented.

---------

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

This removes the workspace of the minimal template, which (I think) is
redundant. The other two templates do not have such a workspace.

The synchronized template created [it's own
workspace](https://github.com/paritytech/polkadot-sdk-minimal-template/blob/master/Cargo.toml)
anyway, and the new readme replaced the old docs contained in `lib.rs`.

Closes
https://github.com/paritytech/polkadot-sdk-minimal-template/issues/11

Silent because the crate was private.

After

https://github.com/paritytech/polkadot-sdk/commit/0636ffdc


approval-distribution did not terminate anymore if Conclude signal was
received.

This should have been caught by the subsystem tests, but it wasn't
because the subsystem is also exiting on error when the channels are
dropped so the test overseer was dropped which made the susbystem exit
and masked the problem.

This pr fixes both the test and the subsystem.

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

Add more logs in `is_potential_spam` revealing why a statement was
marked as a spam.

---------

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

After https://github.com/paritytech/polkadot-sdk/pull/4129, a zombienet
bridge test was broken.
This is because XCMv4 locations have an array in the `interior` field,
which also has to appear in PJS.

---------

Co-authored-by: Serban Iorga <serban@parity.io>

- Typos.
- Those telemetry links like https://telemetry.polkadot.io/#list/Kusama
didn't seem to properly point to a proper list (anymore?) - updated
them.
- Also looks like it was trying to use rust-style linking instead of
markdown linking, changed that.
- Relative links do not work on crates.io - updated to absolute,
similarly as some already existing links, such as contribution
guidelines.

..without needing to provide your own `newtype` around it.  

This will allow `type Reason = u8` to be used as `FreezeReason` and
`HoldReason`, which I think is a nice simplification if one doens't want
to deal with the complications.

At the same time, it is a bit of an anti-pattern.

Putting it out there to check people's vibes.

Fixes https://github.com/paritytech/ci_cd/issues/1015

- Where applicable, use a regular [`reference`] instead of
`../../../reference/index.html`.
- Typos.
- Update a link to `polkadot-evm` which has moved out of the monorepo.
- ~~The link specification for `chain_spec_builder` is invalid~~
(actually it was valid) - it works fine without it.

Part of https://github.com/paritytech/eng-automation/issues/10

fix #3631 

Types which are impacted and fixed here are `ItemTip`,
`PriceWithDirection`, `PreSignedMint`, `PreSignedAttributes`.

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

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

We only want to build one block per slot for Aura on parachains.
However, we still need to build on each relay chain fork, which is using
the same slot.

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

---------

Co-authored-by: Davide Galassi <davxy@datawok.net>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

Update Identity pallet README.md according to the up-to-date docs,
particularly to explain the _username_ concept of the pallet.

---------

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

Bumps [trie-db](https://github.com/paritytech/trie) from 0.29.0 to
0.29.1.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/paritytech/trie/commit/48fcfa99c439949f55d29762e35f8793113edc91"><code>48fcfa9</code></a>
memory-db: update parity-util-mem (<a
href="https://redirect.github.com/paritytech/trie/issues/166">#166</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/02b030a24bc60d46ed7f156888bdbbed6498b216"><code>02b030a</code></a>
Prepare trie-db 0.24.0 release (<a
href="https://redirect.github.com/paritytech/trie/issues/163">#163</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/aff1cbac8f03e8dc7533263b374dc0fcd17444ad"><code>aff1cba</code></a>
Introduce trie level cache &amp; recorder (<a
href="https://redirect.github.com/paritytech/trie/issues/157">#157</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/aa3168d6de01793e71ebd906d3a82ae4b363db59"><code>aa3168d</code></a>
Bump actions/checkout from 2 to 3 (<a
href="https://redirect.github.com/paritytech/trie/issues/160">#160</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/d597275768f4796417c7fc9f8ad64f9b26be14d8"><code>d597275</code></a>
Add GHA to dependabot and CODEOWNERS (<a
href="https://redirect.github.com/paritytech/trie/issues/159">#159</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/5c9267c1133000aa41a5983d8acd6d0968ab8032"><code>5c9267c</code></a>
test prefix seek more precisely (<a
href="https://redirect.github.com/paritytech/trie/issues/158">#158</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/f64e1b0a8ced1b4b574d2b705202bf790d4394e4"><code>f64e1b0</code></a>
Do not check for root in <code>TrieDB</code> and <code>TrieDBMut</code>
constructors (<a
href="https://redirect.github.com/paritytech/trie/issues/155">#155</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/8d5b8675fcc8ecc8648206d08f2e4c06ab489593"><code>8d5b867</code></a>
Update dependencies. (<a
href="https://redirect.github.com/paritytech/trie/issues/154">#154</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/fac100cbf49c197c49d102f12040bccbfa38827e"><code>fac100c</code></a>
Adding support for eip-1186 proofs (<a
href="https://redirect.github.com/paritytech/trie/issues/146">#146</a>)</li>
<li><a
href="https://github.com/paritytech/trie/commit/2e1541e44989f24cec5dbe3081c7cecf00d8b509"><code>2e1541e</code></a>
Fix hex trace output (<a
href="https://redirect.github.com/paritytech/trie/issues/153">#153</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/paritytech/trie/compare/trie-db-v0.29.0...reference-trie-v0.29.1">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=trie-db&package-manager=cargo&previous-version=0.29.0&new-version=0.29.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

The NotifyRevenue XCM from relay to coretime chain fails to pass the
barrier when revenue is 0.


https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/parachains/src/coretime/mod.rs#L401
pushes notifyrevenue onto an [empty
vec](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/parachains/src/coretime/mod.rs#L361)
when `revenue == 0`, so it never explicitly requests unpaid execution,
because that happens only in [the block where revenue is `>
0`](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/parachains/src/coretime/mod.rs#L387).

This will need to be backported to 1.14 when merged.

closes https://github.com/paritytech-secops/srlabs_findings/issues/408.
This fixes how ProxyDelegator accounts are derived but may cause issues
in Westend since it would use the old derivative accounts. Does not
affect Polkadot/Kusama as this pallet is not deployed to them yet.

---------

Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com>

## Context
Pool members using the old `TransferStake` strategy were able to
transfer all their funds to the pool. With `DelegateStake` changes, we
want to ensure similar behaviour by allowing members to delegate all
their stake to the pool.

## Changes
- Ensure all the balance including ED of an account can be delegated
(and used in the pool) by adding a provider for delegators.
- Gates calls that mutates the pool or pool member if they are in
unmigrated state. Closes
https://github.com/paritytech-secops/srlabs_findings/issues/409.
- Adds remote test to migrate all pools and members to `DelegateStake`
which can be used with `Kusama` and `Polkadot` runtime state. closes
https://github.com/paritytech/polkadot-sdk/issues/4629.
- Add new runtime apis to read pool and member balance.

## Addressing possible migration errors 
Pool members migrating can run into two types of errors:
- Already Staking: If the pool member is already staking, we cannot
migrate them to `DelegateStake` since this may mean they are able to use
the same staked funds in the pool. Users would need to withdraw all
their funds from staking, in order to migrate their pool funds.
- Pool contribution below ED: For these cases transfer from pool account
to member account would fail. The affected users can top up their
accounts and redo migration.

Another error that was earlier possible was when member's free balance
is below ED. This PR adds a provider to delegator allowing all user
balance including ED can be contributed towards the pool. This helps
`1095` accounts in Polkadot and `41` accounts in Kusama to migrate now
which would have earlier failed.

## Results from RemoteExternalities Tests.

### Kusama
`Migration stats: success: 3017, direct_stakers: 361, unexpected_errors:
0`

### Polkadot
`Migration stats: success: 42859, direct_stakers: 643,
unexpected_errors: 0`

## TODO
- [x] Add runtime api for member total balance.
- [x] New
[issue](https://github.com/paritytech/polkadot-sdk/issues/5009) to reap
pool members with contribution below ED.
- [x] Add provider for delegators so whole balance including ED can be
held while contributing to pools.
- [x] Gate all pool extrinsics if pool/member is in non-migrated state.

---------

Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com>

The same exact `matches!()` was duplicated in
`Configuration::no_genesis()` method and inline in full node parts
creation. Since this is the same exact logic and reason, it makes sense
to de-duplicate them.

---------

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

Changes:
- Run the prdoc command in a docker container since otherwise the
set-up-gh script wont work.
- Take try-runtime snapshot at night to avoid spamming the node with
snapshot jobs at day.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>