Copying this thread from Telegram to have a more open conversation here on our gov forum: …
One idea that I shared with @spepe was using NEAR’s unique smart contract based delegation to create something like an index fund/basket of pools that would dynamically and fairly reallocate to the pools that are a member of that alliance.
Let’s say 5 pools align on certain incentives/strategies and join together. Users delegated to ONE top of funnel meta-pool that then automatically and dynamically reallocates to all member pools.
For example Open Shards alliance could say we are pushing for earlier rollout of sharded network and will push/lobby for that. Anyone who supports this delegates to this meta pool of pro sharding validators!
That will only make staking looks like decentralized. the meta pool is actually one big pool, right? And a real big pool can also make itself a lot of small pools. that is my concern.
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: deposit_and_stake , unstake_all, withdraw_all.
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.
I’m already doing something similar. Diversified-Staking-pool is what I’m doing. I’ve started mixing the lockup-contract and the staking-pool. It’s selling point is to users to reduce risk: “Don’t put your all the eggs in the same basket”, although “let’s make staking more diversified” is also the result.
When you use the diversified-staking-pool you are covered from the risk of the validator going offline for a few epochs. (“Things” happens). Also the fees are an average of the selected pools fees, based on my last evaluation with the 10 lower-fee+good-uptime-pools you reduce risk from outage to 10% and the averaged staking pool fee would be between 0.5% and 1.25%
The design is simpler, no governance token, just 10/15 pools periodically reevaluated by the SC owner, ordered by a factor of lower-fees + uptime. When you “stake” you stake on the pool that will fix unbalances, the same for unstaking, so no “rebalance” needed (Also the users will complain, they don’t want to lose 4 epochs of benefits because the SC is rebalancing staking pools)
Users have “shares” of the pool (same as the staking-pool does).
Since this is a simpler design, I guess this could be the V1 of the vision you’re stating.
Another thing I’m planning to do (for V3 maybe) is to create a market for “fast unstakes”. That is, if you agree to pay a discount-fee, some LP can “purchase” your staked near and then you get your tokens immediately. Is a mechanism to “instant unstake & withdraw” instead of having to wait 36-48hs
There’s another thing to consider. Every time you ask a staking-pool to unstake it resets the counter account.unstaked_available_epoch_height, so the wait period starts again.
That’s a problem if the staker is the metapool. We might need to block users from unstaking when all the pools have pending unstakes.
I think I’m gonna have to provide from V1 the uniswap-like staked/available swap (“instant unstake & withdraw”) to remedy the unstake limitation.