Even thought there is an open proposal Block and chunk producer selection algorithm in simple nightshade to improve block producer selection, it will still take time to make it into MainNet.
At the same time, the staking derivatives are coming as well.
It’s expected that a single staking derivative will span over many validators as well.
Hence, I think combining this meta staking pool and derivatives make sense. There are a number of rules that can be enforced on the contract level to make sure that such meta pool will behave well and don’t lead to centralization / attacks.
Here is high level properties of such pool:
- Follows the same interface as staking pools:
- Has a list of validator pools that it can delegate to. The list is not predetermined, but change would take time for users to withdraw funds.
- Management of the list is done via a DAO of “metapool” token holders. It still enforced that all pools are from “whitelist”. (this is to maintain whitelist transivity)
- “Metapool” tokens are tokens received for staking with the pool over time (e.g. governance token of the pool)
- For deposits not from lockup - allocates user a sNEAR - staked NEAR token. Each sNEAR is a “LP” token of the metapool. It has deposited principle and rewards from staking pools.
- Handles deposits from lockup accounts a bit differently (e.g. if predeccessor_id ends with .lockup.near) - doesn’t provide sNEAR for it but still allows to receive governance token.
It’s important to handle lockup contracts, otherwise sNEAR will be unlocking tokens in a very wrong ways.
Governance token can be launched in the “fair” way while having initial set of validators in the list at the launch. Validators that are interested in participating in this can work together on launching such metapool.
An integrations with (a) explorers (b) wallets is required.
Metapool will follow the interface but will not be visible in default tooling as it’s not an active validator.
It’s important to make sure that all the tools add support for such pools. Also handle displaying them correctly, as the account’s balance will be low - all tokens be delegated to other pools, but at the same time it’s total stake can be substantial.
There is also operational overhead, similar to “ping” in staking pool contracts. E.g. calling the contract to do redistribution of the stake when required. NEAR has an interface to get current stake distribution, which can be used to determine if rebalance needed. This rebalances lead to less rewards for everyone, but are required for keeping pools decentralized.
To also make sure that network can’t be attack via governance of the pool - the pool should implement few rules around not delegating too big % of total stake to a single pool, even if there is only one pool in the list.
Would someone be interested in developing this?