Skip to content
Snippets Groups Projects
Select Git revision
  • 6994
  • 7703
  • 7995
  • 7882
  • 7286
  • 7894
  • 6137
  • 8011
  • 7567
  • gh-readonly-queue/master/pr-7835-98c6ffcea6794d338514cf9bd84446d2f276cb63 protected
  • 7835
  • 7983
  • gh-readonly-queue/master/pr-7402-b82ef548cfa4ca2107967e114cac7c3006c0780c protected
  • master default protected
  • 7952
  • 7833
  • gh-readonly-queue/master/pr-7903-b82ef548cfa4ca2107967e114cac7c3006c0780c protected
  • 7994
  • gh-readonly-queue/master/pr-7939-b2526906f389c86a6a581c6bcf8fb86fabc65192 protected
  • 7944
20 results
Search by author
  • Any Author
  • Aaro Altonen Aaro Altonen altonen
  • Administrator Administrator Admin0
  • Alexander Alexander alvicsam
  • Alexander Kalankhodzhaev Alexander Kalankhodzhaev kalaninja
  • Alexander Theißen Alexander Theißen athei
  • Alexandra Alexandra a13xndra
  • Alin Dima Alin Dima alindima
  • Andrew Jones Andrew Jones ascjones
  • André Silva André Silva andresilva
  • Anthony Lazam Anthony Lazam lazam
  • Anton Anton melekes
  • Anton Vilhelm Ásgeirsson Anton Vilhelm Ásgeirsson antonva
  • Arsham Teymouri Arsham Teymouri ArshamTeymouri
  • Artyom Bakhtin Artyom Bakhtin bakhtin
  • Bernardo A. Rodrigues Bernardo A. Rodrigues bernardoaraujor
  • Bradley Olson Bradley Olson BradleyOlson64
  • Branislav Kontur Branislav Kontur bkontur
  • Bulat Saifullin Bulat Saifullin BulatSaif
  • Chevdor Chevdor chevdor
  • Chris Kerr Chris Kerr piffle-rack
20 authors
  1. Nov 26, 2024
  3. Nov 22, 2024
    • gupnik's avatar
      Adds `BlockNumberProvider` in multisig, proxy and nft pallets (#5723) · 7c5224cb
      gupnik authored 
      
Step in https://github.com/paritytech/polkadot-sdk/issues/3268

This PR adds the ability for these pallets to specify their source of
the block number. This is useful when these pallets are migrated from
the relay chain to a parachain and vice versa.

This change is backwards compatible:
1. If the `BlockNumberProvider` continues to use the system pallet's
block number
2. When a pallet deployed on the relay chain is moved to a parachain,
but still uses the relay chain's block number

However, we would need migrations if the deployed pallets are upgraded
on an existing parachain, and the `BlockNumberProvider` uses the relay
chain block number.

---------

Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      Unverified
      7c5224cb
  5. Nov 20, 2024
    • Branislav Kontur's avatar
      Bridges testing improvements (#6536) · bd0d0cde
      Branislav Kontur authored 
      
This PR includes:  
- Refactored integrity tests to support standalone deployment of
`pallet-bridge-messages`.
- Refactored the `open_and_close_bridge_works` test case to support
multiple scenarios, such as:
  1. A local chain opening a bridge.  
  2. Sibling parachains opening a bridge.  
  3. The relay chain opening a bridge.  
- Previously, we added instance support for `pallet-bridge-relayer` but
overlooked updating the `DeliveryConfirmationPaymentsAdapter`.

---------

Co-authored-by: default avatarGitHub Action <action@github.com>
      Unverified
      bd0d0cde
  7. Nov 15, 2024
  9. Nov 12, 2024
  11. Nov 11, 2024
  13. Nov 08, 2024
  15. Nov 06, 2024
  17. Nov 05, 2024
    • Nazar Mokrynskyi's avatar
      Remove `sp_runtime::RuntimeString` and replace with `Cow<'static, str>` or... · c5444f38
      Nazar Mokrynskyi authored 
      Remove `sp_runtime::RuntimeString` and replace with `Cow<'static, str>` or `String` depending on use case (#5693)

# Description

As described in https://github.com/paritytech/polkadot-sdk/issues/4001
`RuntimeVersion` was not encoded consistently using serde. Turned out it
was a remnant of old times and no longer actually needed. As such I
removed it completely in this PR and replaced with `Cow<'static, str>`
for spec/impl names and `String` for error cases.

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

## Integration

For downstream projects the upgrade will primarily consist of following
two changes:
```diff
#[sp_version::runtime_version]
pub const VERSION: RuntimeVersion = RuntimeVersion {
-	spec_name: create_runtime_str!("statemine"),
-	impl_name: create_runtime_str!("statemine"),
+	spec_name: alloc::borrow::Cow::Borrowed("statemine"),
+	impl_name: alloc::borrow::Cow::Borrowed("statemine"),
```
```diff
		fn dispatch_benchmark(
			config: frame_benchmarking::BenchmarkConfig
-		) -> Result<Vec<frame_benchmarking::BenchmarkBatch>, sp_runtime::RuntimeString> {
+		) -> Result<Vec<frame_benchmarking::BenchmarkBatch>, alloc::string::String> {
```

SCALE encoding/decoding remains the same as before, but serde encoding
in runtime has changed from bytes to string (it was like this in `std`
environment already), which most projects shouldn't have issues with. I
consider the impact of serde encoding here low due to the type only
being used in runtime version struct and mostly limited to runtime
internals, where serde encoding/decoding of this data structure is quite
unlikely (though we did hit exactly this edge-case ourselves
:sweat_smile:

).

## Review Notes

Most of the changes are trivial and mechanical, the only non-trivial
change is in
`substrate/primitives/version/proc-macro/src/decl_runtime_version.rs`
where macro call expectation in `sp_version::runtime_version`
implementation was replaced with function call expectation.

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [ ] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/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.
* [ ] I have made corresponding changes to the documentation (if
applicable)

---------

Co-authored-by: default avatarGitHub Action <action@github.com>
Co-authored-by: default avatarGuillaume Thiolliere <guillaume.thiolliere@parity.io>
Co-authored-by: default avatarBastian Köcher <info@kchr.de>
      Unverified
      c5444f38
    • Adrian Catangiu's avatar
      Remove leftover references of Wococo (#6361) · ec61396e
      Adrian Catangiu authored 
      Remove references of now defunct Wococo network.

The XCM `NetworkId::Wococo` will also be removed with [XCMv5
PR](https://github.com/paritytech/polkadot-sdk/pull/4826)
      Unverified
      ec61396e
    • Adrian Catangiu's avatar
      snowbridge: allow account conversion for Ethereum accounts (#6221) · 6969be36
      Adrian Catangiu authored 
      Replace `GlobalConsensusEthereumConvertsFor` with
`EthereumLocationsConverterFor` that allows `Location` to `AccountId`
conversion for the Ethereum network root as before, but also for
Ethereum contracts and accounts.

The new converter only matches explicit `parents: 2` Ethereum locations,
meaning it should be used only on/by parachains.
      Unverified
      6969be36
  19. Nov 04, 2024
    • Cyrill Leutwiler's avatar
      [pallet-revive] rework balance transfers (#6187) · d69a80e6
      Cyrill Leutwiler authored 
      
This PR removes the `transfer` syscall and changes balance transfers to
make the existential deposit (ED) fully transparent for contracts.

The `transfer` API is removed since there is no corresponding EVM opcode
and transferring via a call introduces barely any overhead.

We make the ED transparent to contracts by transferring the ED from the
call origin to nonexistent accounts. Without this change, transfers to
nonexistant accounts will transfer the supplied value minus the ED from
the contracts viewpoint, and consequentially fail if the supplied value
lies below the ED. Changing this behavior removes the need for contract
code to handle this rather annoying corner case and aligns better with
the EVM. The EVM charges a similar deposit from the gas meter, so
transferring the ED from the call origin is practically the same as the
call origin pays for gas.

---------

Signed-off-by: default avatarxermicus <cyrill@parity.io>
Signed-off-by: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: default avatarGitHub Action <action@github.com>
Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      Unverified
      d69a80e6
    • PG Herveou's avatar
      [eth-rpc] Fixes (#6317) · 7f80f452
      PG Herveou authored 
      
Various fixes for the release of eth-rpc & ah-westend-runtime

- Bump asset-hub westend spec version
- Fix the status of the Receipt to properly report failed transactions
- Fix value conversion between native and eth decimal representation

---------

Co-authored-by: default avatarGitHub Action <action@github.com>
      Unverified
      7f80f452
  21. Nov 01, 2024
  23. Oct 29, 2024
    • georgepisaltu's avatar
      [Identity] Decouple usernames from identities (#5554) · cc4fe1ec
      georgepisaltu authored 
      
This PR refactors `pallet-identity` to decouple usernames from
identities.

Main changes in this PR:
- Separate usernames from identities in storage, allowing for correct
deposit accounting
- Introduce the option for username authorities to put up a deposit to
issue a username
- Allow authorities to remove usernames by declaring the intent to do
so, then removing the username after the grace period expires
- Refactor the authority storage to be keyed by suffix rather than owner
account.
- Introduce the concept of a system provider for a username, different
from a governance allocation, allowing for usernames set by the system
and not a specific authority
- Implement multi-block migration to enable all of the changes described
above

---------

Signed-off-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
Co-authored-by: default avatarAnkan <10196091+Ank4n@users.noreply.github.com>
      Unverified
      cc4fe1ec
  25. Oct 28, 2024
  27. Oct 25, 2024
  29. Oct 23, 2024
  31. Oct 22, 2024
  33. Oct 21, 2024
    • Dónal Murray's avatar
      [Coretime chain] Add high assignment count mitigation to testnets (#6022) · a3bca4bb
      Dónal Murray authored 
      
Fixed in Polkadot and Kusama in
https://github.com/polkadot-fellows/runtimes/pull/434 and this PR just
adds to testnets.

We can handle a maximum of 28 assignments inside one XCM, while it's
possible to have 80 (if a region is interlaced 79 times).
This can be chunked on the coretime chain side but currently the
scheduler on the relay makes assumptions that means we can't send more
than one chunk for a given core.

This just truncates the additional assignments until we can extend the
relay to support this. This means that the first 27 assignments are
taken, the final 28th is used to pad with idle to complete the mask (the
relay also assumes that every schedule is complete). Any other
assignments are dropped.

---------

Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
      Unverified
      a3bca4bb
    • Andrii's avatar
      Improved TrustedQueryAPI signatures (#6129) · 95483a88
      Andrii authored 
      
Changed returned type of API methods from `Result<bool,
xcm_runtime_apis::trusted_query::Error>` to a typed one `type
XcmTrustedQueryResult = Result<bool,
xcm_runtime_apis::trusted_query::Error>;`
Follow-up of
[PR-6039](https://github.com/paritytech/polkadot-sdk/pull/6039)

---------

Co-authored-by: default avatarBastian Köcher <git@kchr.de>
Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      Unverified
      95483a88
  35. Oct 18, 2024
    • georgepisaltu's avatar
      FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` (#3685) · b76e91ac
      georgepisaltu authored 
      
Original PR https://github.com/paritytech/polkadot-sdk/pull/2280
reverted in https://github.com/paritytech/polkadot-sdk/pull/3665

This PR reintroduces the reverted functionality with additional changes,
related effort
[here](https://github.com/paritytech/polkadot-sdk/pull/3623).
Description is copied over from the original PR

First part of [Extrinsic
Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)

Introduces a new trait `TransactionExtension` to replace
`SignedExtension`. Introduce the idea of transactions which obey the
runtime's extensions and have according Extension data (né Extra data)
yet do not have hard-coded signatures.

Deprecate the terminology of "Unsigned" when used for
transactions/extrinsics owing to there now being "proper" unsigned
transactions which obey the extension framework and "old-style" unsigned
which do not. Instead we have __*General*__ for the former and
__*Bare*__ for the latter. (Ultimately, the latter will be phased out as
a type of transaction, and Bare will only be used for Inherents.)

Types of extrinsic are now therefore:
- Bare (no hardcoded signature, no Extra data; used to be known as
"Unsigned")
- Bare transactions (deprecated): Gossiped, validated with
`ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
`TransactionExtension` (deprecated).
  - Inherents: Not gossiped, validated with `ProvideInherent`.
- Extended (Extra data): Gossiped, validated via `TransactionExtension`.
  - Signed transactions (with a hardcoded signature) in extrinsic v4.
- General transactions (without a hardcoded signature) in extrinsic v5.

`TransactionExtension` differs from `SignedExtension` because:
- A signature on the underlying transaction may validly not be present.
- It may alter the origin during validation.
- `pre_dispatch` is renamed to `prepare` and need not contain the checks
present in `validate`.
- `validate` and `prepare` is passed an `Origin` rather than a
`AccountId`.
- `validate` may pass arbitrary information into `prepare` via a new
user-specifiable type `Val`.
- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`. It is encoded *for the entire transaction* and
passed in to each extension as a new argument to `validate`. This
facilitates the ability of extensions to acts as underlying crypto.

There is a new `DispatchTransaction` trait which contains only default
function impls and is impl'ed for any `TransactionExtension` impler. It
provides several utility functions which reduce some of the tedium from
using `TransactionExtension` (indeed, none of its regular functions
should now need to be called directly).

Three transaction version discriminator ("versions") are now permissible
(RFC [here](https://github.com/polkadot-fellows/RFCs/pull/84)) in
extrinsic version 5:
- 0b00000100 or 0b00000101: Bare (used to be called "Unsigned"):
contains Signature or Extra (extension data). After bare transactions
are no longer supported, this will strictly identify an Inherents only.
Available in both extrinsic versions 4 and 5.
- 0b10000100: Old-school "Signed" Transaction: contains Signature, Extra
(extension data) and an extension version byte, introduced as part of
[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md).
Still available as part of extrinsic v4.
- 0b01000101: New-school "General" Transaction: contains Extra
(extension data) and an extension version byte, as per RFC99, but no
Signature. Only available in extrinsic v5.

For the New-school General Transaction, it becomes trivial for authors
to publish extensions to the mechanism for authorizing an Origin, e.g.
through new kinds of key-signing schemes, ZK proofs, pallet state,
mutations over pre-authenticated origins or any combination of the
above.

`UncheckedExtrinsic` still maintains encode/decode backwards
compatibility with extrinsic version 4, where the first byte was encoded
as:
- 0b00000100 - Unsigned transactions
- 0b10000100 - Old-school Signed transactions, without the extension
version byte

Now, `UncheckedExtrinsic` contains a `Preamble` and the actual call. The
`Preamble` describes the type of extrinsic as follows:
```rust
/// A "header" for extrinsics leading up to the call itself. Determines the type of extrinsic and
/// holds any necessary specialized data.
#[derive(Eq, PartialEq, Clone)]
pub enum Preamble<Address, Signature, Extension> {
	/// An extrinsic without a signature or any extension. This means it's either an inherent or
	/// an old-school "Unsigned" (we don't use that terminology any more since it's confusable with
	/// the general transaction which is without a signature but does have an extension).
	///
	/// NOTE: In the future, once we remove `ValidateUnsigned`, this will only serve Inherent
	/// extrinsics and thus can be renamed to `Inherent`.
	Bare(ExtrinsicVersion),
	/// An old-school transaction extrinsic which includes a signature of some hard-coded crypto.
	/// Available only on extrinsic version 4.
	Signed(Address, Signature, ExtensionVersion, Extension),
	/// A new-school transaction extrinsic which does not include a signature by default. The
	/// origin authorization, through signatures or other means, is performed by the transaction
	/// extension in this extrinsic. Available starting with extrinsic version 5.
	General(ExtensionVersion, Extension),
}
```

## Code Migration

### NOW: Getting it to build

Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
accompanied by renaming your aggregate type in line with the new
terminology. E.g. Before:

```rust
/// The SignedExtension to the basic transaction logic.
pub type SignedExtra = (
	/* snip */
	MySpecialSignedExtension,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
```

After:

```rust
/// The extension to the basic transaction logic.
pub type TxExtension = (
	/* snip */
	AsTransactionExtension<MySpecialSignedExtension>,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
```

You'll also need to alter any transaction building logic to add a
`.into()` to make the conversion happen. E.g. Before:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let extra: SignedExtra = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */),
	);
	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		extra,
	)
}
```

After:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let tx_ext: TxExtension = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */).into(),
	);
	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		tx_ext,
	)
}
```

### SOON: Migrating to `TransactionExtension`

Most `SignedExtension`s can be trivially converted to become a
`TransactionExtension`. There are a few things to know.

- Instead of a single trait like `SignedExtension`, you should now
implement two traits individually: `TransactionExtensionBase` and
`TransactionExtension`.
- Weights are now a thing and must be provided via the new function `fn
weight`.

#### `TransactionExtensionBase`

This trait takes care of anything which is not dependent on types
specific to your runtime, most notably `Call`.

- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`.
- Weight must be returned by implementing the `weight` function. If your
extension is associated with a pallet, you'll probably want to do this
via the pallet's existing benchmarking infrastructure.

#### `TransactionExtension`

Generally:
- `pre_dispatch` is now `prepare` and you *should not reexecute the
`validate` functionality in there*!
- You don't get an account ID any more; you get an origin instead. If
you need to presume an account ID, then you can use the trait function
`AsSystemOriginSigner::as_system_origin_signer`.
- You get an additional ticket, similar to `Pre`, called `Val`. This
defines data which is passed from `validate` into `prepare`. This is
important since you should not be duplicating logic from `validate` to
`prepare`, you need a way of passing your working from the former into
the latter. This is it.
- This trait takes a `Call` type parameter. `Call` is the runtime call
type which used to be an associated type; you can just move it to become
a type parameter for your trait impl.
- There's no `AccountId` associated type any more. Just remove it.

Regarding `validate`:
- You get three new parameters in `validate`; all can be ignored when
migrating from `SignedExtension`.
- `validate` returns a tuple on success; the second item in the tuple is
the new ticket type `Self::Val` which gets passed in to `prepare`. If
you use any information extracted during `validate` (off-chain and
on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
pass it through with this. For the tuple's last item, just return the
`origin` argument.

Regarding `prepare`:
- This is renamed from `pre_dispatch`, but there is one change:
- FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
`validate`!!
- (This is different to `SignedExtension` which was required to run the
same checks in `pre_dispatch` as in `validate`.)

Regarding `post_dispatch`:
- Since there are no unsigned transactions handled by
`TransactionExtension`, `Pre` is always defined, so the first parameter
is `Self::Pre` rather than `Option<Self::Pre>`.

If you make use of `SignedExtension::validate_unsigned` or
`SignedExtension::pre_dispatch_unsigned`, then:
- Just use the regular versions of these functions instead.
- Have your logic execute in the case that the `origin` is `None`.
- Ensure your transaction creation logic creates a General Transaction
rather than a Bare Transaction; this means having to include all
`TransactionExtension`s' data.
- `ValidateUnsigned` can still be used (for now) if you need to be able
to construct transactions which contain none of the extension data,
however these will be phased out in stage 2 of the Transactions Horizon,
so you should consider moving to an extension-centric design.

---------

Signed-off-by: default avatargeorgepisaltu <george.pisaltu@parity.io>
Co-authored-by: default avatarGuillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Unverified
      b76e91ac
  37. Oct 17, 2024
  39. Oct 15, 2024
    • Francisco Aguirre's avatar
      Add assets in pool with native to query_acceptable_payment_assets's return (#5599) · d2ba5677
      Francisco Aguirre authored 
      
`XcmPaymentApi::query_acceptable_payment_assets` is an API that returns
the assets that can be used to pay fees on the runtime where it's
called.
For relays and most system chains this was configured only as the native
asset: ROC and WND.
However, the asset hubs have the asset conversion pallet, which allows
fees to be paid in any asset in a pool with the native one.
This PR adds the list of assets in a pool with the native one to the
return value of this API for the asset hubs.

---------

Co-authored-by: default avatarBranislav Kontur <bkontur@gmail.com>
      Unverified
      d2ba5677
    • Branislav Kontur's avatar
      Remove `check-migrations` for rococo chain (#6061) · f7119e40
      Branislav Kontur authored 
      This PR removes the `check-migrations` pipelines for all Rococo chains
because they are going down:
https://github.com/paritytech/devops/issues/3589, and these checks are
starting to fail, e.g.:

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535485254?pr=4982

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535486189?pr=4982

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535486471?pr=4982

Additionally, `coretime-westend` was added to the `check-migrations`
matrix.
      Unverified
      f7119e40
  41. Oct 10, 2024
    • Francisco Aguirre's avatar
      Remove redundant XCMs from dry run's forwarded xcms (#5913) · 4a70b2cf
      Francisco Aguirre authored 
      # Description

This PR addresses
https://github.com/paritytech/polkadot-sdk/issues/5878.

After dry running an xcm on asset hub, we had redundant xcms showing up
in the `forwarded_xcms` field of the dry run effects returned.
These were caused by two things:
- The `UpwardMessageSender` router always added an element even if there
were no messages.
- The two routers on asset hub westend related to bridging (to rococo
and sepolia) getting the message from their queues when their queues is
actually the same xcmp queue that was already contemplated.

In order to fix this, we check for no messages in UMP and clear the
implementation of `InspectMessageQueues` for these bridging routers.
Keep in mind that the bridged message is still sent, as normal via the
xcmp-queue to Bridge Hub.
To keep on dry-running the journey of the message, the next hop to
dry-run is Bridge Hub.
That'll be tackled in a different PR.

Added a test in `bridge-hub-westend-integration-tests` and
`bridge-hub-rococo-integration-tests` that show that dry-running a
transfer across the bridge from asset hub results in one and only one
message sent to bridge hub.

## TODO
- [x] Functionality
- [x] Test

---------

Co-authored-by: command-bot <>
      Unverified
      4a70b2cf
    • RadiumBlock's avatar
      Add RadiumBlock bootnodes to Coretime Polkadot Chain spec (#5967) · cb1f19c5
      RadiumBlock authored 
      ✄
-----------------------------------------------------------------------------

Thank you for your Pull Request! :pray:

 Please make sure it follows the
contribution guidelines outlined in [this

document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md)
and fill out the
sections below. Once you're ready to submit your PR for review, please
delete this section and leave only the text under
the "Description" heading.

# Description

Please consider adding RadiumBlock bootnodes to Coretime Polkadot Chain
spec

## Integration

*In depth notes about how this PR should be integrated by downstream
projects. This part is mandatory, and should be
reviewed by reviewers, if the PR does NOT have the `R0-Silent` label. In
case of a `R0-Silent`, it can be ignored.*

## Review Notes

*In depth notes about the **implementation** details of your PR. This
should be the main guide for reviewers to
understand your approach and effectively review it. If too long, use

[`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)*.

*Imagine that someone who is depending on the old code wants to
integrate your new code and the only information that
they get is this section. It helps to include example usage and default
value here, with a `diff` code-block to show
possibly integration.*

*Include your leftover TODOs, if any, here.*

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [ ] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/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.
* [ ] 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)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

Co-authored-by: default avatarVeena <veena.john@radiumblock.com>
Co-authored-by: default avatarDónal Murray <donal.murray@parity.io>
      Unverified
      cb1f19c5
  43. Oct 08, 2024
  45. Oct 07, 2024
    • Juan Ignacio Rios's avatar
      Generic slashing side-effects (#5623) · c0ddfbae
      Juan Ignacio Rios authored 
      # Description
## What?
Make it possible for other pallets to implement their own logic when a
slash on a balance occurs.

## Why?
In the [introduction of
holds](https://github.com/paritytech/substrate/pull/12951) @gavofyork
said:
> Since Holds are designed to be infallibly slashed, this means that any
logic using a Freeze must handle the possibility of the frozen amount
being reduced, potentially to zero. A permissionless function should be
provided in order to allow bookkeeping to be updated in this instance.

At Polimec we needed to find a way to reduce the vesting schedules of
our users after a slash was made, and after talking to @Kianenigma

 at
the Web3Summit, we realized there was no easy way to implement this with
the current traits, so we came up with this solution.



## How?
- First we abstract the `done_slash` function of holds::Balanced to it's
own trait that any pallet can implement.
- Then we add a config type in pallet-balances that accepts a callback
tuple of all the pallets that implement this trait.
- Finally implement done_slash for pallet-balances such that it calls
the config type.

## Integration
The default implementation of done_slash is still an empty function, and
the new config type of pallet-balances can be set to an empty tuple, so
nothing changes by default.

## Review Notes
- I suggest to focus on the first commit which contains the main logic
changes.
- I also have a working implementation of done_slash for pallet_vesting,
should I add it to this PR?
- If I run `cargo +nightly fmt --all` then I get changes to a lot of
unrelated crates, so not sure if I should run it to avoid the fmt
failure of the CI
- Should I hunt down references to fungible/fungibles documentation and
update it accordingly?

**Polkadot address:** `15fj1UhQp8Xes7y7LSmDYTy349mXvUwrbNmLaP5tQKBxsQY1`

# 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](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/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.
* [ ] I have made corresponding changes to the documentation (if
applicable)

---------

Co-authored-by: default avatarKian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: command-bot <>
Co-authored-by: default avatarFrancisco Aguirre <franciscoaguirreperez@gmail.com>
      Unverified
      c0ddfbae
  47. Oct 06, 2024
  49. Oct 04, 2024
  51. Oct 02, 2024