XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

bkontur · 2025-01-16T10:53:39Z

Resolves (partially): #7148
Depends on: #7169

Description

This PR addresses partially #7148 (Problem 2) and ensures the proper checking of nested local instructions. It introduces two new barriers - DenyNestedLocalInstructions and DenyNestedLocalInstructionsThenTry - to provide more refined control over instruction denial. The main change is the replacement of DenyThenTry with DenyNestedLocalInstructionsThenTry which handles both top-level and nested local instructions by applying allow condition after denial.

For context and additional information, please refer to Problem 2 - Barrier vs nested XCM validation.

TODO

Evaluate PoC, more details at poc(XCM): Deny Nested XCM Barriers #7351:

DenyNestedXcmInstructions: Keep it as it is and be explicit:
1. Name the Deny barriers for the top level.
2. Name the Deny barrier for nested with DenyInstructionsWithXcm.
DenyNestedLocalInstructionsThenTry: Alternatively, hard-code those three instructions in DenyThenTry, so we wouldn’t need DenyInstructionsWithXcm. However, this approach wouldn’t be as general.
DenyNestedLocalInstructions: Another possibility is to check DenyInstructionsWithXcm::Inner for the actual message, so we don’t need duplication for top-level and nested (not sure, maybe be explicit is good thing) - see Problem2 - example. Instead of this:

DenyThenTry<
             (
                            // Deny for top level XCM program 
                            DenyReserveTransferToRelayChain,
                            // Dedicated barrier for nested XCM programs
                            DenyInstructionsWithXcmFor<
                                             // Repeat all Deny filters here 
                                             DenyReserveTransferToRelayChain,
                             >
             ),

we could just use:

DenyThenTry<
             (
                            // Dedicated barrier for XCM programs
                            DenyInstructionsWithXcmFor<
                                             // Add all `Deny` filters here 
                                             DenyReserveTransferToRelayChain,
                                             ...
                             >
             ),

POC Evaluation
Consider better name DenyInstructionsWithXcm => DenyNestedLocalInstructions and DenyNestedLocalInstructionsThenTry, more details at here
Clean-up and docs
Merge xcm: fix for DenyThenTry Barrier #7169 or rebase this branch on the top of yrong:fix-for-deny-then-try
Set for the runtimes where we use DenyThenTry => DenyNestedLocalInstructionsThenTry
Schedule sec.audit

…tytech/polkadot-sdk into bko-deny-nested-xcm-barrier

raymondkfcheung · 2025-01-29T10:37:26Z

polkadot/xcm/xcm-builder/src/barriers.rs

+/// Applies the `Inner` filter to the nested XCM for the `SetAppendix`, `SetErrorHandler`, and `ExecuteWithOrigin` instructions.
+///
+/// Note: The nested XCM is checked recursively!
+pub struct DenyInstructionsWithXcm<Inner>(PhantomData<Inner>);


Regarding the naming, maybe we can use DenyNestedXcmInstructions, which may be better to state clearly with nested XCMs.

I think DenyNestedXcmInstructions is a better name, but we still need to ensure it's explicitly used only for the following instructions: SetAppendix, SetErrorHandler, and ExecuteWithOrigin—which are meant to be executed on the local chain.

This is important because there are other instructions with nested XCM, such as DepositReserveAsset { xcm: Xcm<()>, ... } and InitiateReserveWithdraw { xcm: Xcm<()>, ... }, where the inner xcm is executed on a remote chain.

Good point! If we want to check all nested XCM instructions recursively (including those executed remotely), we could rename it to DenyNestedXcmInstructions and adjust the logic accordingly.

However, since this implementation currently applies only to instructions executed on the local chain (SetAppendix, SetErrorHandler, and ExecuteWithOrigin), we could instead introduce two separate types for clarity:

DenyNestedLocalInstructions: Covers only local execution cases (current behavior).

DenyNestedRemoteInstructions: Specifically targets instructions like DepositReserveAsset and InitiateReserveWithdraw, ensuring remote execution filtering.

Would this separation make sense, or do you think a more unified approach is preferable?

DenyNestedRemoteInstructions: Specifically targets instructions like DepositReserveAsset and InitiateReserveWithdraw, ensuring remote execution filtering.

Generally, a local chain should not assume rules about other chains' rules/barriers.

The design is that each chain only enforces its own local rules.

It is the job of the offchain component (wallet/ui/app) building the XCM to validate (e.g. through XCM dry-run APIs) that the XCM they build will pass barriers on all involved chains.

I've defined a new NestedXcmType when performing the deny execution. This categorises nested XCM calls as either Local or Remote, ensuring we handle them separately.

Right now, both types go through deny_recursively, but I can implement two different denial strategies (DenyNestedLocalInstructions and DenyNestedRemoteInstructions) if needed. Let me know if you see any difference in behavior, or if you'd prefer keeping a single DenyNestedXcmInstructions that applies to both.

Or shall I use origin: &Location to determine whether it's Local or Remote? If it's Remote, then I could deny all location-based instructions.

we should not care to validate "remote" parts - only what is locally executed - the remote part will be validated by the barrier on the remote chain

@raymondkfcheung yes, agree with Adrian, other words, I think we need just DenyNestedLocalInstructions (for those: SetAppendix, SetErrorHandler, ExecuteWithOrigin). The barrier should handle just incoming XCM and check whether to execute or not on the local chain.

DenyNestedRemoteInstructions could be a potentially "good" addition, but we don't have that scenario and probably don't want to support that either. For example, for filtering/denying outgoing XCMs, we could/would add a custom XCM router - some wrapper implementation of SendXcm trait with filtering capabilities.

Okay, we can focus to implement, DenyNestedLocalInstructions. If it's required, then we can adjust for remote instructions. I'll adjust the PR accordingly.

raymondkfcheung · 2025-01-29T10:43:40Z

/cmd fmt

raymondkfcheung · 2025-01-29T14:39:56Z

/cmd fmt

polkadot/xcm/xcm-builder/src/tests/barriers.rs

Resolves (partially): #7148 Depends on: #7169, #7200 # Description For context and additional information, please refer to #7148 and #7200. # TODOs * [x] Rebase #7169 and #7200 * [x] Evaluate PoC described on #7200 | POC | Top-Level Denial | Nested Denial | Try `Allow` | Remark | |--------------------------------|--------------------|--------------------|--------------------|----------------------------------------------------------------------------------| | `DenyThenTry` | ✅ | ❌ | ✅ | Blocks top-level instructions only. | | `RecursiveDenyThenTry` | ✅ | ✅ | ✅ | Blocks both top-level and nested instructions. | | `DenyInstructionsWithXcm` | ❌ | ✅ | ❌ | Focuses on nested instructions, requires additional checks for top-level denial. | | `DenyFirstInstructionsWithXcm` | ✅ | ✅ | ❌ | Prioritises top-level denial before recursive checks. | --------- Co-authored-by: ron <yrong1997@gmail.com> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: command-bot <> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

raymondkfcheung · 2025-01-31T14:48:27Z

polkadot/xcm/xcm-builder/src/tests/barriers.rs

+	// `DenyThenTry`: Top-level=Deny, Nested=Allow, TryAllow=Yes
+	assert_barrier::<DenyThenTry<Denies, AllowAll>>(Err(ProcessMessageError::Unsupported), Ok(()));
+
+	// `RecursiveDenyThenTry`: Top-level=Deny, Nested=Deny, TryAllow=Yes
+	assert_barrier::<RecursiveDenyThenTry<Denies, AllowAll>>(
+		Err(ProcessMessageError::Unsupported),
+		Err(ProcessMessageError::Unsupported),
+	);
+
+	// `DenyInstructionsWithXcm`: Top-level=Allow, Nested=Deny, TryAllow=No
+	assert_deny_barrier::<DenyInstructionsWithXcm<Denies>>(
+		Ok(()),
+		Err(ProcessMessageError::Unsupported),
+	);
+
+	// `DenyFirstInstructionsWithXcm`: Top-level=Deny, Nested=Deny, TryAllow=No
+	assert_deny_barrier::<DenyFirstInstructionsWithXcm<Denies>>(
+		Err(ProcessMessageError::Unsupported),
+		Err(ProcessMessageError::Unsupported),
+	);


POC Evaluation

Redefine DenyThenTry as RecursiveDenyThenTry: blocks both top-level and nested instructions, before trying to allow execution.

Create a new DenyFirstInstructionsWithXcm: blocks both top-level and nested instructions.

Establish a helper DenyInstructionsWithXcm, handles nested denies.

Updated:

PoC Top-Level Denial Nested Denial Try Allow Remark

DenyThenTry ✅ ❌ ✅ Blocks only top-level instructions, allowing nested ones unless denied elsewhere.

DenyNestedLocalInstructionsThenTry ✅ ✅ ✅ Blocks both top-level and nested local instructions, then applies the allow condition.

DenyNestedXcmInstructions ❌ ✅ ❌ Internal helper; focuses only on nested instructions, requiring additional checks for top-level denial.

DenyNestedLocalInstructions ✅ ✅ ❌ Blocks both top-level and nested local instructions, without attempting to allow execution.

raymondkfcheung · 2025-02-03T14:37:53Z

/cmd prdoc --audience runtime_user --bump minor

github-actions · 2025-02-03T14:40:03Z

Command "prdoc --audience runtime_user --bump minor" has failed ❌! See logs here

raymondkfcheung · 2025-02-03T14:47:50Z

/cmd fmt

raymondkfcheung · 2025-02-03T14:56:21Z

/cmd prdoc --audience runtime_user --bump minor

…_user --bump minor'

raymondkfcheung · 2025-02-03T16:22:47Z

/cmd prdoc --audience runtime_user --bump minor --force true

…_user --bump minor --force true'

paritytech-workflow-stopper · 2025-02-04T09:58:55Z

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13132547786
Failed job name: cargo-clippy

bkontur · 2025-02-05T09:58:15Z

polkadot/xcm/xcm-executor/src/lib.rs

@@ -60,7 +60,7 @@ pub struct FeesMode {
 	pub jit_withdraw: bool,
 }

-const RECURSION_LIMIT: u8 = 10;
+pub const RECURSION_LIMIT: u8 = 10;


since it is public now, we should add here some description, when it is used

bkontur · 2025-02-05T10:02:20Z

polkadot/xcm/xcm-builder/src/tests/mock.rs

+
+// Dummy Barriers
+// Dummy filter to allow all
+pub struct AllowAll;
+impl ShouldExecute for AllowAll {
+	fn should_execute<RuntimeCall>(
+		_: &Location,
+		_: &mut [Instruction<RuntimeCall>],
+		_: Weight,
+		_: &mut Properties,
+	) -> Result<(), ProcessMessageError> {
+		Ok(())
+	}
+}
+
+// Dummy filter which denies `ClearOrigin`
+pub struct DenyClearOrigin;
+impl DenyExecution for DenyClearOrigin {
+	fn deny_execution<RuntimeCall>(
+		_: &Location,
+		instructions: &mut [Instruction<RuntimeCall>],
+		_: Weight,
+		_: &mut Properties,
+	) -> Result<(), ProcessMessageError> {
+		instructions.matcher().match_next_inst_while(
+			|_| true,
+			|inst| match inst {
+				ClearOrigin => Err(ProcessMessageError::Unsupported),
+				_ => Ok(ControlFlow::Continue(())),
+			},
+		)?;
+		Ok(())
+	}
+}
+
+// Dummy filter which wraps `DenyExecution` on `ShouldExecution`
+pub struct DenyWrapper<Deny: ShouldExecute>(PhantomData<Deny>);
+impl<Deny: ShouldExecute> DenyExecution for DenyWrapper<Deny> {
+	fn deny_execution<RuntimeCall>(
+		origin: &Location,
+		instructions: &mut [Instruction<RuntimeCall>],
+		max_weight: Weight,
+		properties: &mut Properties,
+	) -> Result<(), ProcessMessageError> {
+		Deny::should_execute(origin, instructions, max_weight, properties)
+	}
+}


let's better not expose all of these as pub and move them directly where needed to the tests/barriers.rs, similar as struct DenyClearTransactStatusAsYield;, we don't need them elsewhere

bkontur · 2025-02-05T10:19:34Z

polkadot/xcm/xcm-builder/src/barriers.rs

+pub struct DenyNestedLocalInstructions<Inner>(PhantomData<Inner>);
+
+impl<Inner: DenyExecution> DenyExecution for DenyNestedLocalInstructions<Inner> {
+	/// Denies execution of restricted local nested XCM instructions.
+	///
+	/// This checks for `SetAppendix`, `SetErrorHandler`, and `ExecuteWithOrigin` instruction
+	/// applying the deny filter **recursively** to any nested XCMs found.
+	fn deny_execution<RuntimeCall>(


I would rename DenyNestedLocalInstructions -> DenyLocalInstructions, because it does top-level + nested

Suggested change

pub struct DenyNestedLocalInstructions<Inner>(PhantomData<Inner>);

impl<Inner: DenyExecution> DenyExecution for DenyNestedLocalInstructions<Inner> {

/// Denies execution of restricted local nested XCM instructions.

///

/// This checks for `SetAppendix`, `SetErrorHandler`, and `ExecuteWithOrigin` instruction

/// applying the deny filter **recursively** to any nested XCMs found.

fn deny_execution<RuntimeCall>(

pub struct DenyLocalInstructions<Inner>(PhantomData<Inner>);

impl<Inner: DenyExecution> DenyExecution for DenyLocalInstructions<Inner> {

/// Denies execution of restricted local XCM instructions, including nested XCM within the `SetAppendix`, `SetErrorHandler`, and `ExecuteWithOrigin` instructions. Applies the `Inner` deny filter **recursively** to any nested XCMs found.

fn deny_execution<RuntimeCall>(

bkontur · 2025-02-05T10:30:04Z

polkadot/xcm/xcm-builder/src/barriers.rs

+/// Denies execution if the XCM contains any of the denied **local** instructions, even if nested
+/// within `SetAppendix(xcm)`, `SetErrorHandler(xcm)`, or `ExecuteWithOrigin { xcm, ... }`.
+///
+/// This check is applied **recursively** using `DenyNestedLocalInstructions`, ensuring that
+/// instructions do not execute on the local chain at any depth.
+///
+/// If the message passes the deny filters, it is then evaluated against the allow condition.
+///
+/// Note: This applies only to locally executed instructions. Remote parts of the XCM are expected
+/// to be validated by the destination chain's barrier.
+pub type DenyNestedLocalInstructionsThenTry<Deny, Allow> =
+	DenyThenTry<DenyNestedLocalInstructions<Deny>, Allow>;
+


Suggested change

/// Denies execution if the XCM contains any of the denied **local** instructions, even if nested

/// within `SetAppendix(xcm)`, `SetErrorHandler(xcm)`, or `ExecuteWithOrigin { xcm, ... }`.

///

/// This check is applied **recursively** using `DenyNestedLocalInstructions`, ensuring that

/// instructions do not execute on the local chain at any depth.

///

/// If the message passes the deny filters, it is then evaluated against the allow condition.

///

/// Note: This applies only to locally executed instructions. Remote parts of the XCM are expected

/// to be validated by the destination chain's barrier.

pub type DenyNestedLocalInstructionsThenTry<Deny, Allow> =

DenyThenTry<DenyNestedLocalInstructions<Deny>, Allow>;

I think we don't need this type alias, just one DenyThenTry is enough.

so instead:

pub type Barrier = TrailingSetTopicAsId< DenyNestedLocalInstructionsThenTry< DenyReserveTransferToRelayChain,

I would prefer this:

pub type Barrier = TrailingSetTopicAsId< DenyThenTry< DenyLocalInstructions< DenyReserveTransferToRelayChain, >, ( // Allow local users to buy weight credit. ...

I think this is more readable and easier to follow. If somebody will need to add another Denies, it will be easier to follow.:

pub type Barrier = TrailingSetTopicAsId< DenyThenTry< DenyLocalInstructions< DenyReserveTransferToRelayChain, + DenyXyz1, >, ( // Allow local users to buy weight credit. ...

or

pub type Barrier = TrailingSetTopicAsId< DenyThenTry< ( DenyLocalInstructions< DenyReserveTransferToRelayChain, + DenyXyz1, >, + DenyWhateverNonNestedInstructions<>, ), ( // Allow local users to buy weight credit. ...

bkontur · 2025-02-05T10:31:54Z

cumulus/parachains/runtimes/coretime/coretime-rococo/src/xcm_config.rs

@@ -144,7 +144,7 @@ impl Contains<Location> for ParentOrParentsPlurality {
 }

 pub type Barrier = TrailingSetTopicAsId<
-	DenyThenTry<
+	DenyNestedLocalInstructionsThenTry<


as I wrote before, we don't need type alias DenyNestedLocalInstructionsThenTry

Suggested change

DenyNestedLocalInstructionsThenTry<

DenyThenTry<

DenyLocalInstructions<

bkontur · 2025-02-05T10:34:15Z

polkadot/xcm/xcm-builder/src/barriers.rs

+	/// It maintains a **recursion counter** to prevent stack overflows due to a deep nesting.
+	fn deny_recursively<RuntimeCall>(
+		origin: &Location,
+		nested_xcm: &mut Xcm<RuntimeCall>,


Suggested change

nested_xcm: &mut Xcm<RuntimeCall>,

xcm: &mut Xcm<RuntimeCall>,

bkontur · 2025-02-05T10:53:55Z

polkadot/xcm/xcm-builder/src/barriers.rs

+				SetAppendix(nested_xcm) |
+				SetErrorHandler(nested_xcm) |
+				ExecuteWithOrigin { xcm: nested_xcm, .. } =>
+					DenyNestedXcmInstructions::<Self, Inner>::deny_recursively::<RuntimeCall>(


hmm, I think that DenyNestedXcmInstructions is kind of unnecessary (and for me little bit hard to follow with this Outer/Inner stuff :) )

DenyNestedXcmInstructions is private, so I think it would be enough just to have some private helper function:

fn deny_recursively<Deny: DenyExecution>(xcm: Xcm) { recursion_count::using_once( // TODO: all that recursion stuff // here just apply recursively Deny::deny_execution(xcm, ...) ) }

and then use here:

Suggested change

DenyNestedXcmInstructions::<Self, Inner>::deny_recursively::<RuntimeCall>(

// apply `Self` to the `nested_xcm`

deny_recursively::<Self>::deny_recursively(nested_xcm, ...)

Could this be easier? Could this work?

bkontur added T6-XCM This PR/Issue is related to XCM. C1-mentor A task where a mentor is available. Please indicate in the issue who the mentor could be. labels Jan 16, 2025

bkontur mentioned this pull request Jan 21, 2025

[Snowbridge]: Ensure source always from AH for exported message #6838

Draft

3 tasks

bkontur linked an issue Jan 21, 2025 that may be closed by this pull request

[XCM] Investigate better support for filtering XCM programs with Barrier #7148

Open

PoC: DenyInstructionsWithXcm for validating nested XCM instructions

9c80770

bkontur force-pushed the bko-deny-nested-xcm-barrier branch from 2c6325f to 9c80770 Compare January 22, 2025 09:31

bkontur added the C2-good-first-issue A task for a first time contributor to become familiar with the Polkadot-SDK. label Jan 22, 2025

bkontur assigned bkontur and unassigned bkontur Jan 22, 2025

raymondkfcheung self-assigned this Jan 23, 2025

raymondkfcheung mentioned this pull request Jan 27, 2025

poc(XCM): Deny Nested XCM Barriers #7351

Merged

2 tasks

bkontur and others added 4 commits January 28, 2025 09:35

PoC: DenyInstructionsWithXcm for validating nested XCM instructions

6c79a06

Merge branch 'bko-deny-nested-xcm-barrier' of https://github.com/pari…

a98fc0d

…tytech/polkadot-sdk into bko-deny-nested-xcm-barrier

Merge branch 'master' into bko-deny-nested-xcm-barrier

a70881e

Fix merge conflicts

72bec5b

raymondkfcheung reviewed Jan 29, 2025

View reviewed changes

Merge branch 'master' into bko-deny-nested-xcm-barrier

7aec7fe

github-actions bot and others added 3 commits January 29, 2025 10:46

Update from raymondkfcheung running command 'fmt'

6f60579

Fix merge conflicts

06c7e65

Merge branch 'master' into bko-deny-nested-xcm-barrier

7bd8e10

Update from raymondkfcheung running command 'fmt'

2d3d33d

raymondkfcheung reviewed Jan 29, 2025

View reviewed changes

polkadot/xcm/xcm-builder/src/tests/barriers.rs Outdated Show resolved Hide resolved

raymondkfcheung and others added 2 commits January 31, 2025 13:41

Merge branch 'master' into bko-deny-nested-xcm-barrier

797f868

raymondkfcheung reviewed Jan 31, 2025

View reviewed changes

raymondkfcheung added 3 commits January 31, 2025 16:59

Refactor DenyInstructionsWithXcm with new NestedXcmType

72f8fe4

Rename to DenyNestedLocalInstructions

5fe41bc

Remove NestedXcmType

95ce08d

raymondkfcheung added 3 commits February 3, 2025 14:01

Move deny_execution logic to DenyNestedLocalInstructions

2a48a71

Merge branch 'master' into bko-deny-nested-xcm-barrier

c6a363d

Update config

9ca64e7

github-actions bot and others added 2 commits February 3, 2025 14:50

Update from raymondkfcheung running command 'fmt'

9601ee0

Remove for regenerating

f2ff48d

github-actions bot and others added 4 commits February 3, 2025 14:58

Update from raymondkfcheung running command 'prdoc --audience runtime…

b75c40f

…_user --bump minor'

Update prdoc

a663b43

Update prdoc

19e0b6f

Update prdoc

9f4048d

raymondkfcheung marked this pull request as ready for review February 3, 2025 16:02

raymondkfcheung requested a review from a team as a code owner February 3, 2025 16:02

Update prdoc

211c0d8

github-actions bot and others added 6 commits February 3, 2025 16:25

Update from raymondkfcheung running command 'prdoc --audience runtime…

f4662da

…_user --bump minor --force true'

Update prdoc

1951b39

Merge branch 'master' into bko-deny-nested-xcm-barrier

f8009f1

Update prdoc

c69d6c5

Refactor DenyNestedXcmInstructions

fb948e4

Add more tests

f84b50a

raymondkfcheung added 5 commits February 4, 2025 10:00

Remove mut

936e56e

Update comment for DenyNestedXcmInstructions

2994fe2

Merge branch 'master' into bko-deny-nested-xcm-barrier

85a36a2

Merge branch 'master' into bko-deny-nested-xcm-barrier

5443750

Merge branch 'master' into bko-deny-nested-xcm-barrier

f3bf860

bkontur commented Feb 5, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

bkontur commented Jan 16, 2025 •

edited by raymondkfcheung

Loading

raymondkfcheung Jan 29, 2025 •

edited

Loading

bkontur Jan 31, 2025

raymondkfcheung Jan 31, 2025

acatangiu Jan 31, 2025

raymondkfcheung Jan 31, 2025

acatangiu Feb 3, 2025

bkontur Feb 3, 2025

raymondkfcheung Feb 3, 2025

raymondkfcheung commented Jan 29, 2025

raymondkfcheung commented Jan 29, 2025

raymondkfcheung Jan 31, 2025

raymondkfcheung Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

github-actions bot commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

paritytech-workflow-stopper bot commented Feb 4, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

bkontur Feb 5, 2025

PoC	Top-Level Denial	Nested Denial	Try Allow	Remark
DenyThenTry	✅	❌	✅	Blocks only top-level instructions, allowing nested ones unless denied elsewhere.
DenyNestedLocalInstructionsThenTry	✅	✅	✅	Blocks both top-level and nested local instructions, then applies the allow condition.
DenyNestedXcmInstructions	❌	✅	❌	Internal helper; focuses only on nested instructions, requiring additional checks for top-level denial.
DenyNestedLocalInstructions	✅	✅	❌	Blocks both top-level and nested local instructions, without attempting to allow execution.

	DenyNestedLocalInstructionsThenTry<
	DenyThenTry<
	DenyLocalInstructions<

	nested_xcm: &mut Xcm<RuntimeCall>,
	xcm: &mut Xcm<RuntimeCall>,

	DenyNestedXcmInstructions::<Self, Inner>::deny_recursively::<RuntimeCall>(
	// apply `Self` to the `nested_xcm`
	deny_recursively::<Self>::deny_recursively(nested_xcm, ...)

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

Are you sure you want to change the base?

XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain #7200

Conversation

bkontur commented Jan 16, 2025 • edited by raymondkfcheung Loading

Description

TODO

raymondkfcheung Jan 29, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raymondkfcheung commented Jan 29, 2025

raymondkfcheung commented Jan 29, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raymondkfcheung commented Feb 3, 2025

github-actions bot commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

raymondkfcheung commented Feb 3, 2025

paritytech-workflow-stopper bot commented Feb 4, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bkontur commented Jan 16, 2025 •

edited by raymondkfcheung

Loading

raymondkfcheung Jan 29, 2025 •

edited

Loading