[Passed] Allow for multiple staking vaults with different amounts and expiries

Governance
1

Allow for multiple staking vaults with different amounts and expiries

Author(s): @gxmxni
Related Discussions: N/A
Submission Date: May 27 2024

Simple Summary

This proposal adds the ability to stake different amounts of HFT for different periods of time using the same wallet, thus creating multiple “vaults”. The veHFT (governing power) of the wallet is then calculated as the sum of the veHFT in each vault.

Abstract

Today, every user (denoted by a wallet) is limited to one staking vault. The staked amount can always be increased. The stake duration can also be increased (up to a maximum of 4 years). However, staking different amounts for different periods of time requires the use of multiple wallets.

For example, if DAO member X stakes 1 million HFT for 3 months, they cannot stake another 100,000 HFT for a different period (e.g. 1 year) without switching wallets.

This is untidy for multiple reasons:

  • managing multiple wallets for the purpose of only interacting with one protocol is not friendly UX
  • on-chain credentials usually don’t transfer between wallets (e.g. the boost offered by the Creation’s Coffer)
  • voting on a HIP requires multiple actions (one for each wallet)

Specification

The implementation of this proposal will include multiple (technical) layers, as documented below.

Smart Contract code changes

The StakingVault contract will be modified to support multiple vaults per user. When staking, the user will choose which vault they want to interact with, via a vault index.

Allowing for an arbitrarily large number of vaults could raise DoS / UX concerns, so the number of vaults will be limited to 10 to begin with.

The contract will compute the stake power as an aggregate of the stake power in every vault opened by a user.

Hashflow App changes

The Hashflow Staking UX will be redesigned to display and allow for the creation of multiple vaults.

Snapshot algorithm change

The ABI of the stake power method will be preserved, so the same Snapshot strategy will be used (with a different target contract).

Backward compatibility with current vault

Every vault in the current StakingVault contract will be regarded as an additional vault for each user, and stitching will be done at every layer where necessary:

  • the Hashflow App
  • the Snapshot Governance portal (voting power from both contracts will be added)

Code audits

An audit will be required for the new contracts. This audit will be funded by the Hashflow Foundation.

Benefits

  • users only need to use one wallet in order to stake for different amounts of time

Downside

  • funds and engineering resources need to be allocated

Voting

  • yes - implement the multi-vault structure
  • no - keep the single-vault structure currently in place
4 Likes
2

This proposal seems reasonable
Yes

3

i voted for * yes - implement the multi-vault structure

4

Make sense , I vote for Yes , have to create few wallets myself before, because of this issue .

5

Yes,
This proposal is not systemically risky and is the same as the original ballot proposal

6

Proposal matches the original forum post and does not pose any risk to the protocol.

7

This proposal is not systemically risky and is the same as the original ballot proposal

8

This proposal has passed the final vote with quorum.