# Expose era point-based rewards and slashes to priviledged origins

Issue: https://github.com/paritytech/polkadot-sdk/issues/1481

**1. Staking on relay chain with 1) external rewards and 2) restaking completely integrated in the staking logic**

- Staking pallet exposes 3 new extrinsics (xcm) to system parachains:

- **`fn register_restaking(AccountId, contract, validator_signature)`**: registers a "restaking contract" with a signed contract. The contract specifies the restaking contract TTL and max slashing. The validator signature is the signed contract with the validator's acocunt key (in the staking chain).
- **`fn add_points(BoundedVec<AccountId>, points)`**: adds points from validators that are registered as restakers for system parachain
- **`fn slash(AccountId, Balance)`**: slashes validators and all the nominators exposed to the validator.
- slash validator
- slash all nominators that have been exposed to the restaking (expensive to check exposures?)
- there is a mechanism that allows the staking parachains to query the approval voting of the validator in the staking chain and use it in the collator selection.
- assuming that the staking approvals are used for collation selection
- rewards for system parachain are taken from the inflation's budget converted into balance at `Call::payout_staker()` (all in the context of staking).

If the system parachain rewards and slashes validators on the relay chain (restaking), we probably should *reward and slash* nominators too in the correct *exposed eras* (i.e. it requires restaking exposures);

Is the collator selection based on the validator staked funds during the era it is exposed to slashes? Yes, otherwise restaking doesn't make much sense. How does the the parachain queries the list of e.g. 10 validators by stake that are exposed to its restaking? how to scale this in the staking side?

- How does this work dovetail with https://github.com/polkadot-fellows/RFCs/blob/main/text/0007-system-collator-selection.md?
---

-- Another option, when staking is on a parachain:

## A. Expose era points/reward allocation to priviledged origins

Currently, the staking pallet [keeps track](https://github.com/paritytech/polkadot-sdk/blob/b09ab37119acf0f3c4c8b9e3662255afd6d0ae53/substrate/frame/staking/src/pallet/mod.rs#L473) of the era points for each previously active validator for a limited period of time. Block producers and corresponding nominators earn points, which can be redeemed as rewards by calling the `payout_stakers` extrinsic.

Each era is assigned with a validator reward payout, depending on the [inflation calculation for the era](https://github.com/paritytech/polkadot-sdk/blob/9375478/substrate/frame/staking/src/pallet/impls.rs#L453). The era points for each era are stored in the [`ErasRewardPoints`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/staking/src/pallet/mod.rs#L473) storage map.

When the `payout_stakers` extrinsic is called, the era points for the validator and corresponding nominators are distributed based on:
1. the total era points;
2. the individual (validator) era points, compared to the era points earned by other active validators in that era;
3. the comission of the validator;
4. the nominators exposed to the validator in that era.

### Goal
Refactor out the tracking of era points logic and reward minting from staking and expose that functionality to other parachains. This way, collation could be rewarded directly based on the inflation, similarly to validators.

### How
- Each priviledged chain has a pot/sovereign account where part of the era inflation is directly minted into.
- Mint era inflation to pot accounts of priviledged accounts that can reward accounts directly from era inflation;
- Each chain implements a `pallet-rewards` (or trait) resposible for keeping track of the total of era points per account; The era point are converted to rewards by transfering the funds from the pot account into the accounts that accumulated era points. The logic of when to reward account and how to convert from era points to DOT is defined by the `pallet-rewards` (or trait) implementation.

### Inflation

Currently, the caller of [`EraPayout::era_payout()`](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/common/src/impls.rs#L62) uses the returned balances `staking_payout` and `remaining_payout` to learn how much balance should be minted to the stakers and sent to the tresury per era. With this new design, the caller (potentially staking or assets hub) will breakdown and mint `staking_payout` into the multiple pots of the sovereign accounts that will tap into the inflation to reward accounts.

pub enum InflationDestination<AccountId> {
    Staking,
    Others(AccountId),
    Rest,
}

trait EraPayout<AccountId, Balance> {
    fn era_payout(
        total_staked: Balance,
        total_issuance: Balance,
        reward_breakdow: BoundedVec<(InflationDestination<AccountId>, Balance), MaxPayoutsPerEra>,
        era_duration_millis: u64,
    ) -> BoundedVec<(InflationDestination<AccountId>, Balance), MaxPayoutsPerEra> 
}

At the end of each era, the pots are topped up with minted funds from the era inflation that can be used by the sovereign accounts to reward their accounts at will.

The breakdown of `staking_payout` (now `rewards_payout` to be general enough for this new design) should be defined by governance. An hypothetical breakdown could be:

5% AssetHub
5% ParachainA
5% ParachainB
85% Staking/staking parachain