Introduces a swap implementation that allows the exchange of a credit
(aka Negative Imbalance) of one asset for a credit of another asset.
This is particularly useful when a credit swap is required but may not
have sufficient value to meet the ED constraint, hence cannot be
deposited to temp account before. An example use case is when XCM fees
are paid using an asset held in the XCM executor registry and has to be
swapped for native currency.
Additional Updates:
- encapsulates the existing `Swap` trait impl within a transactional
context, since partial storage mutation is possible when an error
occurs;
- supplied `Currency` and `Assets` impls must be implemented over the
same `Balance` type, the `AssetBalance` generic type is dropped. This
helps to avoid numerous type conversion and overflow cases. If those
types are different it should be handled outside of the pallet;
- `Box` asset kind on a pallet level, unbox on a runtime level - here
[why](https://substrate.stackexchange.com/questions/10039/boxed-argument-of-a-dispatchable/10103#10103);
- `path` uses `Vec` now, instead of `BoundedVec` since it is never used
in PoV;
- removes the `Transfer` event due to it's redundancy with the events
emitted by `fungible/s` implementations;
- modifies the `SwapExecuted` event type;
related issue:
- https://github.com/paritytech/polkadot-sdk/issues/105
related PRs:
- (required for) https://github.com/paritytech/polkadot-sdk/pull/1845
- (caused) https://github.com/paritytech/polkadot-sdk/pull/1717
// DONE make the pallet work only with `fungibles` trait and make it
free from the concept of a `native` asset -
https://github.com/paritytech/polkadot-sdk/issues/1842
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
When we call the `set_accept_ownership` method, we increase the number
of account consumers, but then we don't decrease it on collection
transfer, which leads to the wrong consumers number an account has.
A small PR to publicly expose the `pallet_uniques` state that is not
accessible through the nonfungibles implementation.
Currently, this state is unreachable from chain extensions.
closes https://github.com/paritytech-secops/srlabs_findings/issues/78.
Removes `BetterUnsignedThreshold` from pallet EPM. This will essentially
mean any solution submitted by the validator that is strictly better
than the current queued solution would be accepted.
The reason for having these thresholds is to limit number of solutions
submitted on-chain. However for unsigned submissions, the number of
solutions that could be submitted on average is limited even without
thresholding (calculation shown in the corresponding issue).
Fixes #https://github.com/paritytech/polkadot-sdk/issues/2699
Modifying `expect_validator_set()` in order to be able to walk back
until block 0. The chain state at block 0 is available even if we use
`--sync fast` or `--sync warp`. This way we can retrieve the initial
authority set even when BEEFY genesis is 1 and there is no authority
change entry in the headers log.
Credits to @acatangiu for the solution
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
https://github.com/paritytech/polkadot-sdk/pull/1343/ introduced Tasks
API. This one moves `do_task` call in frame_system under the
experimental flag, till the previous one is audited.
---------
Co-authored-by: command-bot <>
`atty` is unmaintaned. See the advisory
https://github.com/advisories/GHSA-g98v-hv3f-hcfr
I picked is-terminal because rustix is already in-tree, so doesn't
increase the dependency footprint, and I am not sure if we can rely on
`IsTerminal` from the std because I am not sure what our MSRV.
In the move from the old `Currency` traits to the new `fungible/s`
family of traits, we already had the `FungiblesAdapter` and
`NonFungiblesAdapter` for multiple fungible and non fungible assets
respectively. However, for handling only one fungible asset, we were
missing a `FungibleAdapter`, and so used the old `CurrencyAdapter`
instead. This PR aims to fill in that gap, and provide the new adapter
for more updated examples.
I marked the old `CurrencyAdapter` as deprecated as part of this PR, and
I'll change it to the new `FungibleAdapter` in a following PR.
The two stages are separated so as to not bloat this PR with some name
fixes in tests.
---------
Co-authored-by: command-bot <>
In `Currency`, we have a dummy impl that we can use for mocks or
examples where we only want to satisfy the trait bounds. I added the
same dummy implementations to `fungible` and `fungibles` regular traits.
---------
Co-authored-by: command-bot <>
This PR adds a round check to the `Call::submit` extrinsic to make sure
that the solution submission has been prepared for the current election
round and avoid penalties for delayed submissions.
Related to
https://github.com/paritytech-secops/srlabs_findings/issues/329
---------
Co-authored-by: command-bot <>
We currently use a bit of a hack in `.cargo/config` to make sure that
clippy isn't too annoying by specifying the list of lints.
There is now a stable way to define lints for a workspace. The only down
side is that every crate seems to have to opt into this so there's a
*few* files modified in this PR.
Dependencies:
- [x] PR that upgrades CI to use rust 1.74 is merged.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
# Description
- What does this PR do?
This PR make some methods of `OverlayedChanges` public which were
previously only visible in same crate.
- Why are these changes needed?
Since, some methods of the `OverlayedChanges` only have crate level
visibility, which makes `OverlayedChanges` somewhat unusable outside the
crate to create custom implementation of `Externalities`. We make those
method public to enable `OverlayedChanges` to remedy this.
- How were these changes implemented and what do they affect?
Changes are implemented by replacing crate visibility to public
visibility of 4 functions.
# Checklist
- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
required)
- [ ] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
Bumps [names](https://github.com/fnichol/names) from 0.13.0 to 0.14.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/fnichol/names/releases">names's
releases</a>.</em></p>
<blockquote>
<h2>Release 0.14.0</h2>
<h2><a
href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">0.14.0</a>
- 2022-06-28</h2>
<h3>Changed</h3>
<ul>
<li>upgrade to <code>regex</code> 1.5.6</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/fnichol/names/blob/main/CHANGELOG.md">names's
changelog</a>.</em></p>
<blockquote>
<h2>[0.14.0] - 2022-06-28</h2>
<h3>Changed</h3>
<ul>
<li>upgrade to <code>regex</code> 1.5.6</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/fnichol/names/commit/8f09d5bf9860582c485b5856cbb325642d3e82c2"><code>8f09d5b</code></a>
release: names 0.14.0</li>
<li><a
href="https://github.com/fnichol/names/commit/b589b911b489812aa4a279efa1b91e6fe7ff7dfa"><code>b589b91</code></a>
release: update CHANGELOG.md</li>
<li><a
href="https://github.com/fnichol/names/commit/e1bed3056d38a98a22f28f39db42211404a00953"><code>e1bed30</code></a>
merge: <a
href="https://redirect.github.com/fnichol/names/issues/20">#20</a></li>
<li><a
href="https://github.com/fnichol/names/commit/12eb753220007a2aafe741031af83562c1e617f6"><code>12eb753</code></a>
Bump regex from 1.5.4 to 1.5.6</li>
<li><a
href="https://github.com/fnichol/names/commit/ed520b76b8542fdca09d9d80658f4ea0b8914464"><code>ed520b7</code></a>
merge: <a
href="https://redirect.github.com/fnichol/names/issues/19">#19</a></li>
<li><a
href="https://github.com/fnichol/names/commit/852eaee067bcadfb2a59e78b432919a87983fe6d"><code>852eaee</code></a>
chore: start next iteration 0.13.1-dev</li>
<li>See full diff in <a
href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">compare
view</a></li>
</ul>
</details>
<br />
[](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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Partially Addresses #2500
Adds a `deprecate_controller_batch` call to the staking pallet that is
callable by `Root` and `StakingAdmin`. To be used for controller account
deprecation and removed thereafter. Adds
`MaxControllersDeprecationBatch` pallet constant that defines max
possible deprecations per call.
- [x] Add `deprecate_controller_batch` call, and
`MaxControllersInDeprecationBatch` constant.
- [x] Add tests, benchmark, weights. Tests that weight is only consumed
if unique pair.
- [x] Adds `StakingAdmin` origin to staking's `AdminOrigin` type in
westend runtime.
- [x] Determined that worst case 5,900 deprecations does fit into
`maxBlock` `proofSize` and `refTime` in both normal and operational
thresholds, meaning we can deprecate all controllers for each network in
one call.
## Block Weights
By querying `consts.system.blockWeights` we can see that the
`deprecate_controller_batch` weights fit within the `normal` threshold
on Polkadot.
#### `controller_deprecation_batch` where i = 5900:
#### Ref time: 69,933,325,300
#### Proof size: 21,040,390
### Polkadot
```
// consts.query.blockWeights
maxBlock: {
refTime: 2,000,000,000,000
proofSize: 18,446,744,073,709,551,615
}
normal: {
maxExtrinsic: {
refTime: 1,479,873,955,000
proofSize: 13,650,590,614,545,068,195
}
maxTotal: {
refTime: 1,500,000,000,000
proofSize: 13,835,058,055,282,163,711
}
}
```
### Kusama
```
// consts.query.blockWeights
maxBlock: {
refTime: 2,000,000,000,000
proofSize: 18,446,744,073,709,551,615
}
normal: {
maxExtrinsic: {
refTime: 1,479,875,294,000
proofSize: 13,650,590,614,545,068,195
}
maxTotal: {
refTime: 1,500,000,000,000
proofSize: 13,835,058,055,282,163,711
}
}
```
---------
Co-authored-by: command-bot <>
Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com>
This PR makes the block number provider configurable through the Config
trait in pallet-vesting, this gives parachains the option to use the
relay chain block number provider from ParachainSystem.
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
The `lazy_static` package does not work well in `no-std`: it requires
`spin_no_std` feature, which also will propagate into `std` if enabled.
This is not what we want.
This PR removes public/private key hash-maps and replaces them with
simple static byte arrays.
`&T` versions of `AsRef/Deref/From` traits implementation were removed.
Little const helper for converting hex strings into array during compile
time was also added. (somewhat similar to _hex_literal_).
---------
Co-authored-by: command-bot <>
Co-authored-by: Koute <koute@users.noreply.github.com>
Treasury Pallet Instance for the Fellowship in Westend Collectives.
In this update, we present a Treasury Pallet Instance that is under the
control of the Fellowship body, with oversight from the Root and
Treasurer origins. Here's how it is governed:
- the Root origin have the authority to reject or approve spend
proposals, with no amount limit for approvals.
- the Treasurer origin have the authority to reject or approve spend
proposals, with approval limits of up to 10,000,000 DOT.
- Voice of all Fellows ranked at 3 or above can reject or approve spend
proposals, with a maximum approval limit of 10,000 DOT.
- Voice of Fellows ranked at 4 or above can also reject or approve spend
proposals, with a maximum approval limit of 10,000,000 DOT.
Additionally, we introduce the Asset Rate Pallet Instance to establish
conversion rates from asset A to B. This is used to determine if a
proposed spend amount involving a non-native asset is permissible by the
commanding origin. The rates can be set up by the Root, Treasurer
origins, or Voice of all Fellows.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: joepetrowski <joe@parity.io>
Closes https://github.com/paritytech/polkadot-sdk/issues/2319
Changes:
- Ensure that only `enqueue_message(s)` is callable from within the
message processor. This prevents messed up storage that can currently
happen when the pallet is called into recursively.
- Use `H256` instead of `[u8; 32]` for clearer API.
## Details
The re-entracy check is done with the `environmental` crate by adding a
`with_service_mutex(f)` function that runs the closure exclusively. This
works since the MQ pallet is not instantiable.
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
# Description
- What does this PR do? Allows to generate JSON schema for subset of XCM
in std builds
- Why are these changes needed? To support XCM messages in CosmWasm
contracts which require Schemars to generate contract clients
- How were these changes implemented and what do they affect? We will
use schema feature flag to build XCM pallet with JSON schema enabled
# Checklist
- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [x] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
required)
- [x] I have made corresponding changes to the documentation (if
applicable)
- [x] I have added tests that prove my fix is effective or that my
feature works (if applicable)
- [x] If this PR alters any external APIs or interfaces used by
Polkadot, the corresponding Polkadot PR is ready as well
as the corresponding Cumulus PR (optional)
# Description
Trivial change that resolves
https://github.com/paritytech/polkadot-sdk/issues/2185.
Since there was a mix of `who` and `peer_id` argument names nearby I
changed them all to `peer_id`.
# Checklist
- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [x] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
required)
- [x] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
# Motivation (+testing)
### Enable easy `ForeignAssets` transfers using `pallet-xcm`
We had just previously added capabilities to teleport fees during
reserve-based transfers, but what about reserve-transferring fees when
needing to teleport some non-fee asset?
This PR aligns everything under either explicit reserve-transfer,
explicit teleport, or this new flexible `transfer_assets()` which can
mix and match as needed with fewer artificial constraints imposed to the
user.
This will enable, for example, a (non-system) parachain to teleport
their `ForeignAssets` assets to AssetHub while using DOT to pay fees.
(the assets are teleported - as foreign assets should from their owner
chain - while DOT used for fees can only be reserve-based transferred
between said parachain and AssetHub).
Added `xcm-emulator` tests for this scenario ^.
# Description
Reverts `(limited_)reserve_transfer_assets` to only allow reserve-based
transfers for all `assets` including fees.
Similarly `(limited_)teleport_assets` only allows teleports for all
`assets` including fees.
For complex combinations of asset transfers where assets and fees may
have different reserves or different reserve/teleport trust
configurations, users can use the newly added `transfer_assets()`
extrinsic which is more flexible in allowing more complex scenarios.
`assets` (excluding `fees`) must have same reserve location or otherwise
be teleportable to `dest`.
No limitations imposed on `fees`.
- for local reserve: transfer assets to sovereign account of destination
chain and forward a notification XCM to `dest` to mint and deposit
reserve-based assets to `beneficiary`.
- for destination reserve: burn local assets and forward a notification
to `dest` chain to withdraw the reserve assets from this chain's
sovereign account and deposit them to `beneficiary`.
- for remote reserve: burn local assets, forward XCM to reserve chain to
move reserves from this chain's SA to `dest` chain's SA, and forward
another XCM to `dest` to mint and deposit reserve-based assets to
`beneficiary`.
- for teleports: burn local assets and forward XCM to `dest` chain to
mint/teleport assets and deposit them to `beneficiary`.
## Review notes
Only around 500 lines are prod code (see `pallet_xcm/src/lib.rs`), the
rest of the PR is new tests and improving existing tests.
---------
Co-authored-by: command-bot <>
André Silva