A Proposal for Introducing Governance Lock to Poolv1 contract
The purpose of starting this thread is not so much to present a proposal as-is, but more to detail a problem and raise a possible solution for community discussion. For clarity, this is also NOT an HSP or a proposal for one, although it may or may not take that form in the future.
The solution I’ll propose here is probably not the only solution, others might have other thoughts. Still, it’s the most elegant solution I could personally come up with, and I think this is an important topic- probably THE most important topic- for HoS to tackle if it’s to have any chance of longer term success.
Background & Problem Statement
Currently, the House of Stake contract operates in more-or-less the following way:
- User w/ liquid NEAR or common LST tokens (LiNEAR, stNEAR, rNEAR) wants to vote in House of Stake and/or get governance rewards etc
- User goes to HoS website and interacts with interface
- User’s account registers with veNEAR token contract
- User’s account deploys lockup from veNEAR contract (and register name)
- User’s account moves NEAR/LST* to lockup account
- Lockup account locks NEAR on it’s balance, minting veNEAR to user’s main account
- stake locked NEAR in lockup contract to pool contract
(*this is not recommended, because LSTs cannot be withdrawn, raising the question of why this function exists at all)
There are a number of issues with this structure imo, but the biggest problem with the structure as it exists is that users with native staked NEAR cannot participate without unstaking from their existing staking positions on standard whitelisted poolv1 contracts.
For many users, moving NEAR out of a staking pool presents major headaches. These are often a holder’s larger positions and therefore more likely to be secured/difficult to access, so there is some justified reluctance to move that NEAR, let alone put all of it into the system above; and that’s before we consider possible tax consequences.
Furthermore, if we consider that ~47% of all NEAR is native staked and that NEAR staked in this fashion is likely the most common holding for those who hold NEAR long term, this is also undoubtedly the largest constituency of potential governance participants.
However, simply building functionality to allow currently staked NEAR to participate cannot work given the current parameters of the poolv1 contract. The reason for this is that the staking pool contract treats the delegator’s rights to withdraw as sacred, and even if we built functionality to externally check the user’s staked balance and mint veNEAR, we cannot prevent the user from withdrawing, making a lock-up impossible. See here: core-contracts/staking-pool at master · near/core-contracts · GitHub
Therefore, in order to have native staked users participate in veNEAR, there are two solutions I can see:
- one, build a tool that causes a given account to remove access keys (incl. full), deploys a new contract to that account, and essentially makes the native staking user’s account into a multisig or
- two, implement a protocol-wide update to the standard pool contract enabling delegates to the pool contract to choose to lock their staked NEAR.
I think #2 is the better solution, and I’ll explain why.
TL;DR: HoS contracts are janky right now (imo) and native stakers cannot participate. I want to upgrade the standard staking-pool contract.
Rationale
I can understand feeling iffy about this. For one thing, the standard staking-pool contract secures 527.9 million NEAR(!), and hasn’t been touched in 6 years(!). So upgrading it may seem a pretty big, kinda risky move.
However, I think this makes sense to do for a variety of reasons, both practical and philosophical.
Part of the reason for staking pools, and of proof of stake at the higher level, is to “secure the network” by having the total weight of the stake “decide” the canonical network. This is the basic, no-frills “governance” of any proof-of-stake chain, existing at the most fundamental level. The core contracts even make this arguably explicit by including a “voting” contract whose function allows the pool owner to “vote” on behalf of their staking pool.
But as we learned from the emissions reduction proposal, not every validator wants to participate in governance of the chain. In fact, a sizable plurality of node runners want to remain extremely neutral on protocol changes.
Upgrading the pool contract allows us to circumvent this cleanly and canonically by separating the responsibility for decentralized governance from the responsibility of network security. It also codifies stakeholder governance explicitly at the protocol level.
It’s also considerably better UX than what HoS has now. Already staked your NEAR? Put a lock on it and you’re all set to mint veNEAR to vote on governance and/or get extra rewards.
Finally, I think this would make it fairly lightweight/convenient to incorporate into any interface that’s already indexing pool contracts for managing account staking (wallets, mostly). I think added visibility this way could really contribute to helping grow participation levels, as it may be more passive holders could discover NEAR governance this way as opposed to standard marketing streams.
Solution
Now, I am not a battle-hardened NEAR contract developer, so details here may not be entirely correct. Bear with me if I make any architectural mistakes and please correct me if any of this doesn’t work:
The changes to the staking-pool contract I’m imagining are relatively straightforward:
- Add a “stake-lock” function to the staking pool contract. Delegator passes args for amount of stake to lock (max being their total stake) and the duration. This does not change the stake shares amount.
- Add a “stake-unlock” function, which sets “unlocking=true” until a future date defined by the lock duration at which point it sets “stake_locked” to 0
- Add restrictions to the “unstake” function that prevent the user from unstaking more than “stake” - “stake_locked” unless unlock timer is 0
- Add a “view-lock” function so that users and other contracts can easily check the amounts and durations of the lock for each user, as well as whether the account’s unlock function has been triggered or not
You’ll notice none of these functions make any presumptions about veNEAR, which is intentional to preserve future versatility.
Still this would also allow the veNEAR contract to mint/adjust veNEAR balances for accounts based on their stake locked, lock duration, and unlock status via viewing the staking pools the user specifies.
Although, I am not actually sure how lightweight it is to check whether or not a user has unlocked, which may in some cases cause a user to have “ghost veNEAR” while unlocking until the contract next checks their pool lock. Thoughts welcome here.
Implementation
Open to debate on this, but my gut sense is that this is not really a proposal for HoS, but moreso for the Protocol working group (eg. this would probably take the form of a NEP).
If we do want to go this direction, I would want to at least see support among the community here and particularly among the class of respected NEAR developers (Bowen, Eugene, Frol, Slime, etc).
If we discuss this and decide it’s a good approach, I’m happy to work on pushing this forward personally. Interested to get people’s thoughts, thanks much for the read.
