deploy: 5710c49

print.html

@@ -886,11 +886,10 @@ <h2 id="motivation-4"><a class="header" href="#motivation-4">Motivation</a></h2>
 types of transfers and reduce complexity.</p>
 <p>Bridge asset transfers greatly benefit from this change by allowing building XCM programs to transfer multiple
 assets across multiple hops in a single pseudo-atomic action.<br />
-For example, allows single XCM program execution to transfer multiple assets from <code>ParaK</code> on Kusama, through Kusama
-Asset Hub, over the bridge through Polkadot Asset Hub with final destination <code>ParaP</code> on Polkadot.</p>
+For example, allows single XCM program execution to transfer multiple assets from <code>ParaK</code> on Kusama, through
+Kusama Asset Hub, over the bridge through Polkadot Asset Hub with final destination <code>ParaP</code> on Polkadot.</p>
 <p>With current XCM, we are limited to doing multiple independent transfers for each individual hop in order to
 move both &quot;interesting&quot; assets, but also &quot;supporting&quot; assets (used to pay fees).</p>
-<p><strong>Note:</strong> Transferring assets that require different paths (chains along the way) is <em>not supported within same XCM</em> because of the async nature of cross chain messages. This new instruction, however, enables initiating transfers for multiple assets that take the same path even if they require different transfer types along that path.</p>
 <h2 id="stakeholders-4"><a class="header" href="#stakeholders-4">Stakeholders</a></h2>
 <ul>
 <li>Runtime users</li>
@@ -899,6 +898,21 @@ <h2 id="stakeholders-4"><a class="header" href="#stakeholders-4">Stakeholders</a
 <li>dApps devs</li>
 </ul>
 <h2 id="explanation-3"><a class="header" href="#explanation-3">Explanation</a></h2>
+<p>A new instruction <code>InitiateAssetsTransfer</code> is introduced that initiates an assets transfer from the
+chain it is executed on, to another chain. The executed transfer is point-to-point (chain-to-chain)
+with all of the transfer properties specified in the instruction parameters. The instruction also
+allows specifying another XCM program to be executed on the remote chain.
+If a transfer requires going through multiple hops, an XCM program can compose this instruction
+to be used at every chain along the path, on each hop describing that specific leg of the transfer.</p>
+<p><strong>Note:</strong> Transferring assets that require different paths (chains along the way) is <em>not supported
+within same XCM</em> because of the async nature of cross chain messages. This new instruction, however,
+enables initiating transfers for multiple assets that take the same path even if they require
+different transfer types along that path.</p>
+<p>The usage and composition model of <code>InitiateAssetsTransfer</code> is the same as with existing
+<code>DepositReserveAsset</code>, <code>InitiateReserveWithdraw</code> and <code>InitiateTeleport</code> instructions. The main
+difference comes from the ability to handle assets that have different point-to-point transfer type
+between A and B. The other benefit is that it also allows specifying remote fee payment and
+transparently appends the required remote fees logic to the remote XCM.</p>
 <p>We can specify the desired transfer type for some asset(s) using:</p>
 <pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
 </span><span class="boring">fn main() {
@@ -936,8 +950,11 @@ <h2 id="explanation-3"><a class="header" href="#explanation-3">Explanation</a></
 /// The onward XCM also potentially contains a `BuyExecution` instruction based on the presence
 /// of the `remote_fees` parameter (see below).
 ///
+/// If a transfer requires going through multiple hops, an XCM program can compose this instruction
+/// to be used at every chain along the path, describing that specific leg of the transfer.
+///
 /// Parameters:
-/// - `dest`: The location of the transfer destination.
+/// - `dest`: The location of the transfer next hop.
 /// - `remote_fees`: If set to `Some(asset_xfer_filter)`, the single asset matching
 ///   `asset_xfer_filter` in the holding register will be transferred first in the remote XCM
 ///   program, followed by a `BuyExecution(fee)`, then rest of transfers follow.

proposed/0100-xcm-multi-type-asset-transfer.html

@@ -234,11 +234,10 @@ <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
 types of transfers and reduce complexity.</p>
 <p>Bridge asset transfers greatly benefit from this change by allowing building XCM programs to transfer multiple
 assets across multiple hops in a single pseudo-atomic action.<br />
-For example, allows single XCM program execution to transfer multiple assets from <code>ParaK</code> on Kusama, through Kusama
-Asset Hub, over the bridge through Polkadot Asset Hub with final destination <code>ParaP</code> on Polkadot.</p>
+For example, allows single XCM program execution to transfer multiple assets from <code>ParaK</code> on Kusama, through
+Kusama Asset Hub, over the bridge through Polkadot Asset Hub with final destination <code>ParaP</code> on Polkadot.</p>
 <p>With current XCM, we are limited to doing multiple independent transfers for each individual hop in order to
 move both &quot;interesting&quot; assets, but also &quot;supporting&quot; assets (used to pay fees).</p>
-<p><strong>Note:</strong> Transferring assets that require different paths (chains along the way) is <em>not supported within same XCM</em> because of the async nature of cross chain messages. This new instruction, however, enables initiating transfers for multiple assets that take the same path even if they require different transfer types along that path.</p>
 <h2 id="stakeholders"><a class="header" href="#stakeholders">Stakeholders</a></h2>
 <ul>
 <li>Runtime users</li>
@@ -247,6 +246,21 @@ <h2 id="stakeholders"><a class="header" href="#stakeholders">Stakeholders</a></h
 <li>dApps devs</li>
 </ul>
 <h2 id="explanation"><a class="header" href="#explanation">Explanation</a></h2>
+<p>A new instruction <code>InitiateAssetsTransfer</code> is introduced that initiates an assets transfer from the
+chain it is executed on, to another chain. The executed transfer is point-to-point (chain-to-chain)
+with all of the transfer properties specified in the instruction parameters. The instruction also
+allows specifying another XCM program to be executed on the remote chain.
+If a transfer requires going through multiple hops, an XCM program can compose this instruction
+to be used at every chain along the path, on each hop describing that specific leg of the transfer.</p>
+<p><strong>Note:</strong> Transferring assets that require different paths (chains along the way) is <em>not supported
+within same XCM</em> because of the async nature of cross chain messages. This new instruction, however,
+enables initiating transfers for multiple assets that take the same path even if they require
+different transfer types along that path.</p>
+<p>The usage and composition model of <code>InitiateAssetsTransfer</code> is the same as with existing
+<code>DepositReserveAsset</code>, <code>InitiateReserveWithdraw</code> and <code>InitiateTeleport</code> instructions. The main
+difference comes from the ability to handle assets that have different point-to-point transfer type
+between A and B. The other benefit is that it also allows specifying remote fee payment and
+transparently appends the required remote fees logic to the remote XCM.</p>
 <p>We can specify the desired transfer type for some asset(s) using:</p>
 <pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
 </span><span class="boring">fn main() {
@@ -284,8 +298,11 @@ <h2 id="explanation"><a class="header" href="#explanation">Explanation</a></h2>
 /// The onward XCM also potentially contains a `BuyExecution` instruction based on the presence
 /// of the `remote_fees` parameter (see below).
 ///
+/// If a transfer requires going through multiple hops, an XCM program can compose this instruction
+/// to be used at every chain along the path, describing that specific leg of the transfer.
+///
 /// Parameters:
-/// - `dest`: The location of the transfer destination.
+/// - `dest`: The location of the transfer next hop.
 /// - `remote_fees`: If set to `Some(asset_xfer_filter)`, the single asset matching
 ///   `asset_xfer_filter` in the holding register will be transferred first in the remote XCM
 ///   program, followed by a `BuyExecution(fee)`, then rest of transfers follow.