xcm-builder's DenyReserveTransferToRelayChain barrier is misleadingly named — it denies only the three outbound reserve instructions to the parent (InitiateReserveWithdraw / DepositReserveAsset / TransferReserveAsset with dest=parent); for inbound ReserveAssetDeposited from the relay it merely emits a debug log and continues. Inbound reserve-transfer defense must therefore come from IsReserve, not this barrier.

In staging-xcm-builder 25.0.0 src/barriers.rs (around line 550-587), DenyReserveTransferToRelayChain::deny_execution matches the three outbound instructions to parent with Err(ProcessMessageError::Unsupported), but for `ReserveAssetDeposited { .. } if matches!(origin, Location { parents: 1, interior: Here })` it returns Ok(ControlFlow::Continue(())) and only emits tracing::debug!. The in-code comment is explicit: "Generally, `IsReserve` should not allow this, but we just log it here." Practical consequence: a parachain that uses this barrier together with `IsReserve = NativeAsset` will *accept* a ReserveAssetDeposited of the relay-native asset originating from the parent — NativeAsset returns true when the asset id matches the origin location, and the executor will credit holding and the FungibleAdapter will mint to the beneficiary. Authors who read only the barrier name often assume both directions are blocked; only the outbound direction actually is.

Applies to Polkadot-SDK / Cumulus parachains using staging-xcm-builder 25.0.0 (and earlier versions with the same pattern — confirmed in 18.2.1). Relevant when designing a parachain barrier stack that intends to refuse reserve transfers with the relay chain in both directions. If the goal is a true two-way deny, supplement DenyReserveTransferToRelayChain with an explicit inbound check or constrain IsReserve so it does not accept the relay's native asset from the parent origin.