Remote stake any asset on Asset Hub

Ecosystem
, ,
1

This idea came up while brainstorming for the new Staking Chain that has been in discussions (see this and this). While we may not pursue this in the short term with staking chain (not in V1 atleast), I am hoping to develop this proposal further on the side with feedback from the ecosystem. If this resonates well enough with others, this could even be worked in parallel and proposed as an XCM RFC.

What is Remote Staking?

Remote Staking is the ability to lock funds in one chain (such as Asset Hub) and stake on another (such as Staking chain or Moonbeam). As long as there is a parachain that supports staking of a particular asset, an asset can be remote staked via Asset Hub.

Why do we need it?

Any dapp/custodians that want to support staking of polkadot ecosystem tokens, need to integrate with each corresponding parachain in order to do it. Having the ability to remote stake via Asset Hub would mean these applications need to only integrate with one chain (Asset Hub) and support staking for almost all the assets.

Note: Remote Staking is a minimal staking functionality and won’t support all the implementation specific features. The goal is to provide a minimal general way to stake and earn rewards but not replace every implementation specific details. Users/applications needing more advanced features would still integrate directly with the parachain to natively stake.

How would it work?

Following describes an opinionated example of handling these new xcm instruction by a DOT Staking Chain (does not exist today). Another chain can handle it in a completely different manner.

  • XCM::StakeAsset(asset: MultiAsset, chain: MultiLocation, nominations: Multilocation)

where

  • asset could be DOT or GLMR.
  • chain is a multilocation where you want these assets to be staked (the chain should support staking of these assets). In our example, it would be Staking Chain or Moonbeam Chain.
  • nominations is a multilocation that represents your nominations. For Staking Chain, it could be a nomination pool address, or another direct staker’s address allowing you to follow their nominations. It could also be a single validator address. We thought of making it a boundedVec of Multilocations but since we already accept that this is minimal staking and NPoS is very specific to relay chain’s way of electing validators where you can specify upto 16 validators, just one MultiLocation is probably enough to represent a minimal staking intent. For other chains like Moonbeam, this should nicely play where you can send the same instruction multiple time to say, stake 10 GLMR to collator 1 and 25 GLMR to collator 2. Ultimately every chain can decide how to interpret these instruction.

When this instruction is issued to AssetHub, funds are locked in user’s account in Asset Hub and a NoteStaked instruction is passed on to the Staking Chain. On Staking Chain, a keyless account (will need to be funded in a previous instruction for paying transaction fees) derived from user’s account in Asset Hub is used to do the actual staking. The rewards would be paid out to this account as free balance. To move balance back to asset hub and restake these rewards, user need to withdraw these assets back to Asset Hub account.

We could also allow compounding of rewards that are paid out in the staking chain, but then we will probably need another xcm instruction that allows withdraw of a locked asset back to user’s Asset Hub account so their balance is locked/represented in only once place. The above is simpler so sticking to it for now but keen to get more ideas and improvements to this flow.

  • XCM::UnstakeAsset(asset: MultiAsset, chain: MultiLocation, nominations: Multilocation)
    Unstake asset is pretty symmetrical to Stake Asset instruction. In Staking Chain implementation, this would start the unbonding period of asset.

  • XCM::UnlockAsset { asset: MultiAsset, target: MultiLocation }
    This is an existing instruction that can be used to unlock the assets in AssetHub once the unstaked assets has gone through the unbonding period and is ready to be unlocked.

Is this flow general enough to work with a variety of staking implementations?

That’s the answer I am trying to figure out with you. Would this flow work with your favourite parachain asset? Is there some improvement that can be made to this flow? Or may be there is a detail I am overlooking that makes this proposal a trash? Happy to hear and engage if you have some opinions. :slight_smile:

5 Likes
2

We’ll need this paired account pattern where users lock on chain A to create an account on chain B for staking, obviously.

As a rule, we should worry about the paired account pattern though, because we end up having accounts on both chains. We’ll often have more efficient usage if instead users lock on chain A, so that they could act on chain B using the state proof into A, and then unlock from B. It’d cost us way too much functionality to do state proofs pattern in staking, but maybe elsewhere this model works.

In particular, I’d think nomination pools could work by the state proofs pattern, aka users lock on chain A to join the pool on chain B using their state proof into A, and then later unlock by leaving the nomination pool on B using another state proof into A. In fact, I’d think all remote staking could be done by joining nomination pools, given the operations sound exactly the same.

1 Like
3

Interesting. Are we using this state proof pattern somewhere else? I am wondering how fee payments would work on the Stake Chain without an account. May be the chains don’t need to charge any fees at all for specific xcm instructions but still keen to learn more on how you are thinking about it? Also, if I understand correctly, in this case as well, all user interactions only happen via Asset Hub.

4

It’s broadly how polkadot works. Async backing means parachains provide state proofs of recent relay chain state, instead of being in sync with the relay chain.

It’s often how cross chain things should be done, unless some other constraint prevents doing so.

Right, this is one of three-ish reasons why I say the state proofs patter cannot work for staking per se, with nominations/npos being another reason.

It’s likely the state proofs pattern works for delegation to a nomination pool though. In fact, I think delegation to a nomination pool looks almost exactly like your proposal, so maybe all cross chain staking can go via nomination pools.

A priori, there are no XCM messages or fees when a remote user joins or leaves a nomination pool per se, but the user or nomination pool pays fees on both chains, and the nomination pool or someone pays XCM fees when distributing rewards.

Also, the state proofs pattern risks poor ux, like if a user winds up locked on AssetHub but never successfully joins the nomination pool on the staking chain, and thus cannot unlock on AssetHub. We need a second set of off-chain locks in polkadot.js or maybe to persist the messages inside the account, not necessarily free either. It maybe simpler to send pff-chain XCMP messages than to solve the ux problems, once reliable XCMP exists.