There are some high level issues with the current staking program in their various seasons:
The long timescales over which staking is running is sub-optimal, we have a hard time judging how long it should run (and so far we always thought "3 months is ample time to get whitelist & CT ready")
Deploying another staking season is significant overhead that is sub-optimal (contracts, UI, not even talking of audits thereof)
Airdropping tokens for testnet is overhead (and using prod wxHOPR is a risk)
Rewards from ancient NFTs are largely lost and do not bring value to the HOPR ecosystem
We're limited to our own NFTs. Staking other NFTs could beat significant marketing boost.
The fixed APR leads to large token payouts which start being a problem for the budget. We have budgeted 1.1m bounty tokens per month. At the current 33m xHOPR staked , that stake burns 50% of the bounty allocation even in best case (no boosts) scenario.
Therefore it would be desirable to have a staking implementation with the following properties:
Potentially perpetually running (fixes 1 & 2 from the previous list above) with a 10 day unstaking cooldown period
Can be disable by multisig so that
The payout of a disabled staking contract does not favor the fast who claim until the reward pool is out of money
NFT APR boost factors can be reduced (alternatively: just binary disabled) by type & rank (fixes 4 from above, without a sudden surprise which might anger the community)
Should call a hook in the whitelist contract upon unstaking an NFT so that the whitelist can facilitate un-whitelisting
Owner account can allow staking of arbitrary NFTs (other contracts, not just HoprBoost) and assign them a staking deadline and denominator (boost factor). The boost factor of these NFTs can be decreased (or disabled) in the same fashion as the HoprBoost NFT mentioned in (4) here (fixes (5) from above).
Payout is based on fix amount of rewards tokens per time and not on fix APR (fixes (6) from above).
There are some high level issues with the current staking program in their various seasons:
Therefore it would be desirable to have a staking implementation with the following properties: