Staking Messages #21
Staking Messages #21
Conversation
There was a problem hiding this comment.
I don't want to just mimic the extrinsic of staking pallet and hoping to come out something more friendly in crosschain context. So I have modified the interfaces and dropped the controller concept which I don't think it makes much sense in crosschain staking context.
|
|
||
| ##### `SetPayee` | ||
|
|
||
| - `payee: RewardDestination`: The destination account for payment. |
There was a problem hiding this comment.
How are we going to define RewardDestination? Do we want to mimic the Substrate Staking pallet?
There was a problem hiding this comment.
I am not very familiar with XCM: what are the assumptions? That we have two any arbitrary chains talking to each other, or two substrate based chains, or two FRAME-based chains?
If not the former, then the design of this can be reflected on pallet-staking, and we can make sure that things that are noted here will rarely change in pallet-staking.
Although, my guess is that this is totally generic over chain and we can't make an assumption about the existence of pallet-staking
There was a problem hiding this comment.
Any two arbitrary chains.
|
|
||
| ##### `Nominate` | ||
|
|
||
| - `targets: Vec<MultiLocation>`: Declare the desire to nominate `targets`. |
There was a problem hiding this comment.
This is AccountId on Kusama / Polkadot. Not too sure how we going to define it here. This must be dest chain account type and MultiLocation allow people to enter all kinds of accounts.
There was a problem hiding this comment.
Think of XCM as a language; there's no need for every sentence to be true or even to make sense. XCM just let's you express ideas in an unambiguous way - it's up to the destination chain to decide what those mean in its context.
In this case, it's perfectly reasonable for a substrate chain to require this MultiLocation to be specifically an AccountId32 type, and to bail on anything else.
|
|
||
| Kind: *Instruction*. | ||
|
|
||
| ##### `Rebond` |
There was a problem hiding this comment.
FYI if the goal is to be general: this is assuming the existence of a bonding duration in which you can rebond your tokens. While unlikely, some chains might not have this. Or, if this applies also to the notion of delegators, they usually don't have any bonding duration applied.
There was a problem hiding this comment.
XCM aims to be general, exhaustive and composable.
| - `10`: `HrmpInitOpenChannel` | ||
| - `11`: `HrmpAcceptOpenChannel` | ||
| - `12`: `HrmpCloseChannel` | ||
| - `13`: `Staking` |
There was a problem hiding this comment.
Just put the different message types right in here.
|
This can't be a generic staking format and much more study will be required to build one. Close for now. |
Closes #11
cc @kianenigma