|
1 | 1 | # Polkadot Cross-Consensus Message (XCM) Format |
2 | 2 |
|
3 | | -**Version 4.** |
| 3 | +**Version 5.** |
4 | 4 | **Authors: Gavin Wood.** |
5 | 5 |
|
6 | 6 | This document details the message format for Polkadot-based message passing between chains. It describes the formal data format, any environmental data which may be additionally required and the corresponding meaning of the datagrams. |
@@ -107,6 +107,7 @@ The registers are named: |
107 | 107 | - *Refunded Weight* |
108 | 108 | - *Transact Status* |
109 | 109 | - *Topic* |
| 110 | +- *Fees* |
110 | 111 |
|
111 | 112 | ### **3.1** Programme |
112 | 113 |
|
@@ -174,6 +175,11 @@ Of type `Option<[u8; 32]>`, initialized to `None`. |
174 | 175 |
|
175 | 176 | Expresses an arbitrary topic of an XCM. This value can be set to anything, and is used as part of `XcmContext`. |
176 | 177 |
|
| 178 | +### **3.12** Fees |
| 179 | + |
| 180 | +Of type `Assets`, initialized to an empty set (i.e. no assets). |
| 181 | + |
| 182 | +Similar to the holding register, but containing only assets destined for fee payment in their entirety. |
177 | 183 |
|
178 | 184 | ## **4** Basic XCVM Operation |
179 | 185 |
|
@@ -212,7 +218,7 @@ The instructions, in order, are: |
212 | 218 | - `QueryResponse = 3 {query_id: Compact<QueryId>, response: Response, max_weight: Weight, querier: Option<Location> }` |
213 | 219 | - `TransferAsset = 4 { assets: Assets, beneficiary: Location }` |
214 | 220 | - `TransferReserveAsset = 5 { assets: Assets, dest: Location, xcm: Xcm<()> }` |
215 | | -- `Transact = 6 { origin_kind: OriginKind, require_weight_at_most: Weight, call: DoubleEncoded<Call> }` |
| 221 | +- `Transact = 6 { origin_kind: OriginKind, fallback_max_weight: Option<Weight>, call: DoubleEncoded<Call> }` |
216 | 222 | - `HrmpNewChannelOpenRequest = 7 { sender: Compact<u32>, max_message_size: Compact<u32>, max_capacity: Compact<u32> }` |
217 | 223 | - `HrmpChannelAccepted = 8 { recipient: Compact<u32> }` |
218 | 224 | - `HrmpChannelClosing = 9 { initiator: Compact<u32>, sender: Compact<u32>, recipient: Compact<u32> }` |
@@ -254,6 +260,22 @@ The instructions, in order, are: |
254 | 260 | - `ClearTopic = 45` |
255 | 261 | - `AliasOrigin = 46 (Location)` |
256 | 262 | - `UnpaidExecution = 47 { weight_limit: WeightLimit, check_origin: Option<Location> }` |
| 263 | +- `PayFees = 48 { asset: Asset }` |
| 264 | +- `InitiateTransfer = 49 { destination: Location, remote_fees: Option<AssetTransferFilter>, preserve_origin: bool, assets: BoundedVec<AssetTransferFilter, MaxAssetTransferFilters>, remote_xcm: Xcm<()> }` |
| 265 | +- `ExecuteWithOrigin = 50 { descendant_origin: Option<InteriorLocation>, xcm: Xcm<Call> }` |
| 266 | +- `SetHints = 51 { hints: BoundedVec<Hint, NumHints> }` |
| 267 | + |
| 268 | +`AssetTransferFilter` is a type that can be one of the following: |
| 269 | + |
| 270 | +- `Teleport = 0 (AssetFilter)` |
| 271 | +- `ReserveDeposit = 1 (AssetFilter)` |
| 272 | +- `ReserveWithdraw = 2 (AssetFilter)` |
| 273 | + |
| 274 | +The hints mentioned in `SetHints` are: |
| 275 | + |
| 276 | +- `AssetClaimer = 0 { location: Location }` |
| 277 | + |
| 278 | +Therefore `NumHints` is 1. |
257 | 279 |
|
258 | 280 | ### Notes on terminology |
259 | 281 |
|
@@ -398,7 +420,7 @@ The Transact Status Register is set according to the result of dispatching the c |
398 | 420 | Operands: |
399 | 421 |
|
400 | 422 | - `origin_kind: OriginKind`: The means of expressing the message origin as a dispatch origin. |
401 | | -- `require_weight_at_most: Weight`: The weight of `call`; this should be at least the chain's calculated weight and will be used in the weight determination arithmetic. |
| 423 | +- `fallback_max_weight: Option<Weight>`: An optional max weight the `call` can have; this should be at least the chain's calculated weight and will be used in the weight determination arithmetic. It's optional for backwards compatibility. Not needed most of the time since the destination can get the weight for the call. |
402 | 424 | - `call: DoubleEncoded<Call>`: The encoded transaction to be applied. |
403 | 425 |
|
404 | 426 | Kind: *Command*. |
@@ -1050,6 +1072,105 @@ Kind: *Indication* |
1050 | 1072 | Errors: |
1051 | 1073 | - `BadOrigin` |
1052 | 1074 |
|
| 1075 | +### [`PayFees`](https://github.com/paritytech/polkadot-sdk/blob/7304295748b1d85eb9fc2b598eba43d9f7971f22/polkadot/xcm/src/v5/mod.rs#L1058) |
| 1076 | + |
| 1077 | +Takes an asset, uses it to pay for execution and puts the rest in the fees register. |
| 1078 | + |
| 1079 | +The successor to `BuyExecution`. |
| 1080 | +Defined in [Fellowship RFC 105](https://github.com/polkadot-fellows/RFCs/pull/105). |
| 1081 | +Subsequent `PayFees` after the first one are noops. |
| 1082 | + |
| 1083 | +Operands: |
| 1084 | + |
| 1085 | +- `asset: Asset`: The asset used to pay for fees. |
| 1086 | + |
| 1087 | +Kind: *Command*. |
| 1088 | + |
| 1089 | +### [`InitiateTransfer`](https://github.com/paritytech/polkadot-sdk/blob/7304295748b1d85eb9fc2b598eba43d9f7971f22/polkadot/xcm/src/v5/mod.rs#L1106) |
| 1090 | + |
| 1091 | +Initiates cross-chain transfer as follows: |
| 1092 | + |
| 1093 | +Assets in the holding register are matched using the given list of `AssetTransferFilter`s, they are then transferred based on their specified transfer type: |
| 1094 | + |
| 1095 | +- teleport: burn local assets and append a `ReceiveTeleportedAsset` XCM instruction to the |
| 1096 | + XCM program to be sent onward to the `destination` location, |
| 1097 | +- reserve deposit: place assets under the ownership of `destination` within this consensus |
| 1098 | + system (i.e. its sovereign account), and append a `ReserveAssetDeposited` XCM instruction |
| 1099 | + to the XCM program to be sent onward to the `destination` location, |
| 1100 | +- reserve withdraw: burn local assets and append a `WithdrawAsset` XCM instruction to the |
| 1101 | + XCM program to be sent onward to the `destination` location, |
| 1102 | + |
| 1103 | +The onward XCM is then appended a `ClearOrigin` to allow safe execution of any following |
| 1104 | +custom XCM instructions provided in `remote_xcm`. |
| 1105 | +The onward XCM also contains either a `PayFees` or `UnpaidExecution` instruction based |
| 1106 | +on the presence of the `remote_fees` parameter (see below). |
| 1107 | +If an XCM program requires going through multiple hops, it can compose this instruction to |
| 1108 | +be used at every chain along the path, describing that specific leg of the flow. |
| 1109 | + |
| 1110 | +Operands: |
| 1111 | + |
| 1112 | +- `destination`: The location of the program next hop. |
| 1113 | +- `remote_fees`: If set to `Some(asset_xfer_filter)`, the single asset matching |
| 1114 | + `asset_xfer_filter` in the holding register will be transferred first in the remote XCM |
| 1115 | + program, followed by a `PayFees(fee)`, then rest of transfers follow. This guarantees |
| 1116 | + `remote_xcm` will successfully pass a `AllowTopLevelPaidExecutionFrom` barrier. If set to |
| 1117 | + `None`, a `UnpaidExecution` instruction is appended instead. Please note that these |
| 1118 | + assets are **reserved** for fees, they are sent to the fees register rather than holding. |
| 1119 | + Best practice is to only add here enough to cover fees, and transfer the rest through the |
| 1120 | + `assets` parameter. |
| 1121 | +- `preserve_origin`: Specifies whether the original origin should be preserved or cleared, |
| 1122 | + using the instructions `AliasOrigin` or `ClearOrigin` respectively. |
| 1123 | +- `assets`: List of asset filters matched against existing assets in holding. These are |
| 1124 | + transferred over to `destination` using the specified transfer type, and deposited to |
| 1125 | + holding on `destination`. |
| 1126 | +- `remote_xcm`: Custom instructions that will be executed on the `destination` chain. Note |
| 1127 | + that these instructions will be executed after a `ClearOrigin` so their origin will be |
| 1128 | + `None`. |
| 1129 | + |
| 1130 | +Safety: No concerns. |
| 1131 | + |
| 1132 | +Kind: *Command*. |
| 1133 | + |
| 1134 | +Errors: |
| 1135 | + |
| 1136 | +- `UntrustedTeleportLocation` |
| 1137 | +- `UntrustedReserveLocation` |
| 1138 | +- `FailedToTransactAsset` |
| 1139 | + |
| 1140 | +### [`ExecuteWithOrigin`](https://github.com/paritytech/polkadot-sdk/blob/7304295748b1d85eb9fc2b598eba43d9f7971f22/polkadot/xcm/src/v5/mod.rs#L1131) |
| 1141 | + |
| 1142 | +Executes inner `xcm` with origin set to the provided `descendant_origin`. Once the inner |
| 1143 | +`xcm` is executed, the original origin (the one active for this instruction) is restored. |
| 1144 | + |
| 1145 | +Operands: |
| 1146 | + |
| 1147 | +- `descendant_origin`: The origin that will be used during the execution of the inner |
| 1148 | + `xcm`. If set to `None`, the inner `xcm` is executed with no origin. If set to `Some(o)`, |
| 1149 | + the inner `xcm` is executed as if there was a `DescendOrigin(o)` executed before it, and |
| 1150 | + runs the inner xcm with origin: `original_origin.append_with(o)`. |
| 1151 | +- `xcm`: Inner instructions that will be executed with the origin modified according to |
| 1152 | + `descendant_origin`. |
| 1153 | + |
| 1154 | +Kind: *Command*. |
| 1155 | + |
| 1156 | +Errors: |
| 1157 | +- `BadOrigin` |
| 1158 | + |
| 1159 | +### [`SetHints`](https://github.com/paritytech/polkadot-sdk/blob/7304295748b1d85eb9fc2b598eba43d9f7971f22/polkadot/xcm/src/v5/mod.rs#L1141) |
| 1160 | + |
| 1161 | +Set hints for XCM execution. |
| 1162 | + |
| 1163 | +These hints change the behaviour of the XCM program they are present in. |
| 1164 | + |
| 1165 | +Operands: |
| 1166 | + |
| 1167 | +- `hints`: A bounded vector of `ExecutionHint`, specifying the different hints that will |
| 1168 | +be activated. |
| 1169 | + |
| 1170 | +Safety: No concerns. |
| 1171 | + |
| 1172 | +Kind: *Command*. |
| 1173 | + |
1053 | 1174 | ## **6** Universal Asset Identifiers |
1054 | 1175 |
|
1055 | 1176 | *Note on versioning:* This describes the `Asset` (and associates) as used in XCM version of this document, and its version is strictly implied by the XCM it is used within. If it is necessary to form a `Asset` value that is used _outside_ of an XCM (where its version cannot be inferred) then the version-aware `VersionedAsset` should be used instead, exactly analogous to how `Xcm` relates to `VersionedXcm`. |
@@ -1222,12 +1343,10 @@ Encoded as the tagged union of: |
1222 | 1343 | - `ByFork = 1 { block_number: u64, block_hash: [u8; 32] }`: Network defined by the first 32-bytes of the hash and number of some block it contains. |
1223 | 1344 | - `Polkadot = 2`: The Polkadot mainnet Relay-chain |
1224 | 1345 | - `Kusama = 3`: The Kusama canary-net Relay-chain. |
1225 | | -- `Westend = 4`: The Westend testnet Relay-chain. |
1226 | | -- `Rococo = 5`: The Rococo testnet Relay-chain. |
1227 | | -- `Wococo = 6`: The Wococo testnet Relay-chain. |
1228 | 1346 | - `Ethereum = 7 { chain_id: Compact<u64> }`: An Ethereum network specified by its EIP-155 chain ID. |
1229 | 1347 | - `BitcoinCore = 8`: The Bitcoin network, including hard-forks supported by Bitcoin Core development team. |
1230 | 1348 | - `BitcoinCash = 9`: The Bitcoin network, including hard-forks supported by Bitcoin Cash developers. |
| 1349 | +- `PolkadotBulletin = 10`: The Polkadot Bulletin chain. |
1231 | 1350 |
|
1232 | 1351 | #### BodyId |
1233 | 1352 | An identifier of a pluralistic body. |
|
0 commit comments