---
# System prepended metadata

title: Staking Parachain - FRAME retreat Malmö
tags: [' polkadot', ' frame', staking, ' substrate']

---


### Main directions (from discussion with Gav)
*(summary, more details in the sections below)*

- **non-fungible on-hold derivative**: Alice requests assets hub to hold funds; a derivative that represents held funds is represented in the XCM message (holding registry), that can be directly used in the staking chain XCM executor. The held funds are never held by the sovereign account. The derivative is in the XCM holding registry that can be used directly in the executor, so no need multiple actions from the user to e.g. `bond`.
    - Note: this approach is fundamentally different from the 2-phase `NoteUnlockable` approach (although we may want to experiment with this approach to start with -- edit: or even go with the "stake hub-centric approach", below).
- Staking hub keeps track locally of the rewards state without having to interact with assets hub for enabling compounding and (partial) slashes. The state is propagated and applied on assets hub when slashing exceeds the local state amount or the user want to withdraw funds.
- Notion of session and eras live solely in the staking hub (although "era points" per era is conveyed by the relay chain). Relay chain's session-lite receives/requests the next set of session keys from the staking hub (also expect a governance-lite on the relay chain).
- Asset hub knows nothing about staking; Relay chain knows nothing about DOT. Staking hub glues both realms together.
- **stake hub-centric approach**: all the staking funds tracking lives in the staking parachain. nearly a lift-and-shift implementation approach from current pallets to the staking parachain, no need for new funky XCM instructions.

---

### Discussion

- Request for the XCM team: `UpdateLock` XCM instruction for `bond_extra`.
- Starting the interaction at the StakingHub has the advantage that the intent is explicit to the staking hub.
	- But it requires the trust assumption between system parachains (which it seems Gav is not happy with)
	- Basically:
		- Advantages: start interaction at StakingHub, intent is known
		- Disadvantages: start interactions at AssetHub, intent is not known (unless `NoteUnlockable` contains a blob intent information from the caller)
- Another (deprecated!) feature request for XCM team: Add a blob to the `NoteUnlockable` to include the intent from the wallet, which is redirected from AssetHub (where the requests start) to the staking hub (where the intent needs to be known)
	- if staking hub does not trust asset hub, intent payload may be signed by Alice
	- this intent can be better set through the note unloackable multilocation or through a multistep transaction (see notes with Gav for more details)
- XCMP benchmark/resources: can XCMP support hundreds of message processing (e.g. for rewards/large slashing). Would these messages (transact and respective `NoteUnlockable` overload the relay chain? 
	- XCM team to figure this out
- Option B. for compound: keep the rewards in the mini balances on staking and allow these to compound. Needs to deal with slashing over staking and asset hub (we'd prefer keeping all the hold on the asset hub as plan A, though)
- fees: we can have either:
	- mini balance teleported and kept in the staking hub to pay for fees
	- free execution on the parachain up to a limit (e.g. 10 transactions per day), controlled by  `SignedExtensions`
**Request Flow**
- Option 1: Staking XCM adapter is a registry storage of `NoteUnlockable`s that users "claim" (on the staking hub) them manually and set the intent of what to do with the locked stake.
- Option 2: bundle the set lock with a transact. the transact will carry over the "intent" into the staking hub, which can be applied once the `NoteUnlockable` arrives to staking hub (important note: we should not assume ordering of execution/message passing when bundling instructions)
- Option 3: add metadata to `NoteUnlockable` -- not a good pattern, Gav is against it (and dialects fwiw)
- Option 4: Another (good) approach is to include the "action" on what to do e.g. `bound` etc as part of the `NoteUnlockable` multilocation. e.g. `nominatio-pools/bound`, which carry over the intent of the lock from the wallet (Gav kinda liked this approach, no need to multistep approach)

### Discussion with Gav
- trust assumptions:
	- Trust 1: should asset hub trust if Alice wants to lock funds?
	- Trust 2: should we trust staking hub when it requests to mint DOT (rewards)?
		- Yes, asset hub can trust staking hub. However, staking hub should tell the asset hub that, from the allowed minting amount, what is the DOT to be minted for rewards. Needs to be parameterised: how much minting is allowed per era.
		- ⭐ North Star: asset hub does not know how to convert era points to DOT (only staking hub does)
		- ⭐ North Star: the relay chain does not know what DOT is
- Allow for rewards to live in the staking hub. Easier for compound and slashing (start slashing on the staking hub).
- Differentiate between cumulative and non-cumulative rewards
	- The staking pallet keep track of the rewards locally, which can be easily compounded and slashed locked without touching the asset hub
- Staking hub's responsibility is to protect the users (e.g. rewards and slashes are correct). The asset hub responsibility is to ensure that the minting is done correctly and as per the inflation expectations
- New XCM instruction: `TransferAndHold` (instead of using a barrier) 
- Gav agrees with flow 1: `NoteUnlockable` without metadata, xcm executor stores the note unlockable until the user claims the note. (the `NoteUnlockable { ..owner }` has the information that will allow staking hub to confirm that the lock has been performed on assets hub)
- Another (good) approach is to include the "action" on what to do e.g. `bound` etc as part of the `NoteUnlockable` multilocation. e.g. `nominatio-pools/bound`, which carry over the intent of the lock from the wallet
- ⭐ North Star: try to avoid fees from being spread across system parachains  
- Staking hub needs to track the held balances locally, but without any of the methods and functionalities of the pallet assets.
- Introduce XCM instruction `NominateValidator` that can operate over the XCM registry. The derivative is held, not part of the sovereign account of the staking chain.
- `DepositOnHold`: new XCM instruction that is required when realizing the compound rewards that are kept on the staking hub. The assets hub will increase the held deposit by X, which map to the realized rewards that were kept in storage in the staking hub.
- Staking hub has a storage map of `{ nominator: AccountId, hold_balance_assets_hub: Balance, hold_balance_locally: Balance }`, which keeps track of all the held balance and slashable by a nominator, across the two system parachains. `hold_balance_assets_hub` can be increased up to `hold_balance_locally` through a XCM message `DepositOnHold` to the assets hub.

### New idea -- Non-Fungible on-hold
- **Liquid-ish staking**: Represent the asset in a registry so that everything can be done in one step, since the asset hub does not have to send a "lock" to staking hub. Instead, it sends a derivative from the locked funds over a registry that can be operated over.
	- Main goal of this idea is that subsequent XCM instructions for the hold can operate over the hold derivative. Thus, XCM can execute in staking what Alice wants to do (e.g. `bond`) in one action alone, and Alice only needs one interaction with assets hub.
	- the asset can be retained by the original owner and the lock is held by the derivative chain
	- rather than the derivative chain controls the asset, the original owner owns the funds
	- key enabler for this: we need the ability to convey that the funds are held in the assets hub (but the sovereign account never gets the locked funds)
	- In this approach, asset hub does not *transfer* the funds to the sovereign account. Instead, it transfers the rights for held assets (derivative of the held asset). The assets sit all the time from Alice's account, not in the sovereign account (until slashes or repatriation of the derivative account)
	- So even though the funds are in the Alice's account in asset hub, the staking hub controls the lock held on the Alice's funds in assets. The lock is a derivative, Alice volunteers to give control of the held funds to staking, in a way that staking may repatriate or slash the funds.
	- Caveat: create XCM for repatriation, which is not trivial. We don't want repatriation to become standard, since it invalidates freezes.
- **Why isn't this liquid staking?** - because the "releaser" is always staking hub and there's no way (we don't want) for the release permissions to be transferred to other entity that may buy the derivative (i.e. the held position). We want to keep it this way to avoid the liquid staking issues. This is a purely functional derivative of a held position that is useful for the staking use case.
- **Simulation (now)**: In order to simulate this now, we need to tweak XCM so that the derivative has a representation of i) the multilocation of Alice and ii) the multilocation of the owner of the owner of the hold (staking hub).
    - Or (even better) let's stick with the 2-phase `NoteUnlockable` approach before for hacking things together

#### Another approach, staking hub-centric
- Keep all the funds accounting in the staking hub (not only the reward compounding); 
- Governance chain will need to go the extra effort to check the funds for voting.
- No need to prioritize the hold instructions for XCM
- Total issuance is kept minted/track is really only performed at the staking hub level. Staking hub can keep track of "minted" balance in the stake hub and then propagated the information to the assets hub when the funds are meant to be minted.
- Easier for staking development -- the current implementation of the staking system can basically be (almost) lifted and shidted to the staking parachain
    - only the interaction with the relay chain (eras, sessions, session keys, etc) needs to change considerably
- Much easier to keep track and reason about minting, inflation and whatnot. More transparent in terms of inflation etc.
    - 8% is minted in the assets hub
    - 28 eras after, the staking hub sends information where those 8% have been distributed to.


---

## Actionable next steps for Staking Parachain after retreat
*Prepare pallet-staking & friends for staking-chain*

- Finish bounding all elections/EPM/etc storage items (PoV)
	- https://github.com/paritytech/substrate/issues/12187
	- especially slashing related storage:
		- `SlashingSpans`
		- `UnappliedSlashes`
		- `OffendingValidators`
		- `Invulnerables`
		- ...
- Keep working on multi-block staking/election
    - multi-block rewards
    - multi-block election, feasibility check, etc (start)
- Improve current slashing documentation (with Fateme)
- New/revisit slashing mechanism (with W3F)
- Revisit EPM and Staking `on_initialize`
    - correct weighting for hooks (benchmarks)
    - `poll` hook
- Write down high level specs for the ~3 designs that we came up with to keep track over time
	- just to make sure we don't forget the details and can keep revisiting them in the future
- Start working on the testing setup 
	- perhaps based on https://github.com/paritytech/trappist
- play with the XCM simulator 