The `xcm` crate was renamed to `staging-xcm` to be able to publish it to crates.io as someone as squatted `xcm`. The problem with this rename is that the `TypeInfo` includes the crate name which ultimately lands in the metadata. The metadata is consumed by downstream users like `polkadot-js` or people building on top of `polkadot-js`. These people are using the entire `path` to find the type in the type registry. Thus, their code would break as the type path would now be [`staging_xcm`, `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request fixes this by renaming the path segment `staging_xcm` to `xcm`. This requires: https://github.com/paritytech/scale-info/pull/197 --------- Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Bridge Relayers Pallet
The pallet serves as a storage for pending bridge relayer rewards. Any runtime component may register reward
to some relayer for doing some useful job at some messages lane. Later, the relayer may claim its rewards
using the claim_rewards call.
The reward payment procedure is abstracted from the pallet code. One of possible implementations, is the
PayLaneRewardFromAccount, which just does a Currency::transfer
call to relayer account from the relayer-rewards account, determined by the message lane id.
We have two examples of how this pallet is used in production. Rewards are registered at the target chain to compensate fees of message delivery transactions (and linked finality delivery calls). At the source chain, rewards are registered during delivery confirmation transactions. You may find more information about that in the Kusama <> Polkadot bridge documentation.