Thank you for this proposal!
I am very excited to see a professional, well thought out proposal, so fast after the sunsetting of NDC (and the resulting burnout in community governance it left in most of us.)
Here is a detailed breakdown:
Acknowledgments
I believe that anyone contributing feedback to governance should acknowledge the following:
- Conflict of Interest: I was a member of the Transparency Commission within the previous NDC structure. I was very vocal about the shortcomings of that structure before, during and after its implementation and I saw first hand from within the many ways in which it was exploited and how it failed.
- Conflict of Interests (Others) Other people participating in this thread were also part of NDC, either at the pre-conception stage or as elected members. Some were oblivious to the obvious and defended it til the end, some were grossly negligent or outright corrupt, the rest tried their best to make it work and are also well versed into the ecosystem dynamics and challenges. The outcome is the same and one must understand where the outcome is coming from as they now try to shape new forms of governance.
As far as acknowledgments go, I am very happy to see Gauntlet acknowledging the NDC shortcomings. We must learn form past experiments in order to progress.
Challenges of NDC Framework
The proposal has a very brief and eloquently put summary of some of the shortcomings of NDC. I’d like to add a little extra flavour which I believe is necessary to truly appreciate the proposed structure:
-
The NDC was unaligned by design. Early drafts were permeated with UBI and other forms of social utopianism which aimed to use NEAR treasury for great things, except actually help NEAR ecosystem grow. It is hard to believe I was involved in very intense power struggles to include NEAR ALIGNMENT into the Charters of some DAOs. Deliberate steps were taken to onboard people only for the purposes of voting to the extent that a real ‘election issue’ was voters having so little involvement with NEAR they didn’t even have enough to cover gas fees to vote (and txs on NEAR are cheap asf).
-
Lack of Merit or Authority: we had a Transparency Commission with people who did not have any background in dispute resolution and that even when explained basic legal concepts and processes decided to use their power to override common sense and advice (incl. from Foundation, Trustees, etc.). A house of merit where members with less merit and more free time overloaded and undermined more senior members, which grew quickly frustrated and stopped engaging.
-
Faux screening: the NDC did have some screening, implementing basic ‘OG’ status to be able to run. This was an acknowledgement as to the need for some standards, but as the rest of the framework, it was very poorly implemented, keeping an extremely low bar. Justifications ranged at time from lack of time for a more complex technical implementation to ‘fairness’ concerns. Even if both were valid at the time, this seems like a relevant precedent in the consideration of current committees.
Functional Bodies
Screening Committee
I 100% support the implementation of a Screening Committee. While it is true that the committee will only be as good as the people that sit in it, it is also true that there are people who have built one of the most advanced blockchains out there (technical, operational accomplishments) and that unburdened by group think and mobs masquerading as ‘community’, have been able to procure this proposal.
I trust the NEAR Foundation, under Illia’s leadership, and other early core contributors and founders, to use their best judgment and either be in screening committee directly or appoint people who they deem will be able to perform these duties as laid out in proposed gov framework.
Once again, a lot of us have PTSD from the NDC. But we must use the NDC as an example of what does not work, move past it, and implement a proper Screening Committee to ensure we never have such challenges again.
Beware of those who call for the elimination of checks and balances such as Screening Committees…
Endorsed Delegates
I am eagerly looking forward for more information being provided regarding endorsed delegates. In particular, I would like to know:
- Application Template: what information will be required of Delegates to be provided?
In the past we struggled with NDC elected members:
- Presenting pro-active disclosures of conflict of interest
- Adhering to basic conflict of interest procedures (like voting on your own proposals)
- Passing KYC
- Complying with basic KYC processes (incl. taking deliberate measures to bypass KYC requirements)
- Identifying and acknowledging people’s experience, subject matter expertise, interests.
I am open to working with the team looking into the application template to ensure we strike the right balance between privacy and due diligence.
- Delegates need to submit their rationale for their votes
This is perhaps the most important thing in the entire proposal. While I have personally always provided LENGHTY explanations to my decision from MDAO to Transparency Commission (if you are super bored go check out all my Marketing DAO decision dating back to 2021). Sadly, I was one of the few. Attempts to ask others to do the same were ignored, or outright opposed. (incl. making the rationale public).
Here I am interested in:
-
The systems built to enable these deliberations and final decision to be made. Specifically, I’d love to see an AI interface that can serve as a ‘Case Manager’, assisting delegates work their way through pending proposal, documenting all their reasoning, translating content to/from the language that would allow delegates to perform their best work, among other potential use cases.
-
What happens if delegates fail to submit their reasoning?
In general, I believe that this framework where: a) there is a higher bar for delegates to join b) there are clear expectations on performance (beyond the pathetically mediocre standard adopted by NDC of simply showing up to meetings even without uttering a word), and perhaps most importantly, it allows community to delegate tokens to their preferred Delegate ensuring all communities are represented.
Security Council
I believe the Security Council body needs some revision. My main concern is that it is being tasked with two very different sets of responsibilities. At first, it would appear as through Security Council is a technical body in charge of security breaches, protocol upgrades, etc. But then they are also granted dispute resolution powers that need to be thought out carefully:
- What would be the process for ‘Community Members’ to raise concerns about a delegate?
- What is the definition of ‘harming the community’? As it stands, it is extremely open ended.
- Clarify who participates in the on-chain vote? Is it only Security Council members that vote or is the removal also open to all stake-weighted participants?
- Review and state explicitly the reasoning for maintaining the Quorum for the Screening Committee the same, even if the number reduces in size. (This was also a heavily contentious issue in NDC, albeit by design to kill a body if it became inoperable)
I already experienced through the short-lived Transparency Commission how anon ‘community members’ targeted sitting members of NDC with poorly drafted, baseless claims that were extremely time consuming to address.
As it stands, the highly technical group of people that would be well suited for dealing with core infrastructure security and upgrades, et al. are probably THE WORST suited people to deal with community claims and dispute resolution (very public facing, social skills, legal reasoning).
Use of NEAR, stNEAR, Linear
I’ve been reading the comments from several community members and the update from Gauntlet regarding allowing locking NEAR for veNEAR directly with validators.
- It is important to note that these concerns and suggestions are coming from OG community members who are also running validators. Long term commitment and quality. However, I do not think we can make the same assertion about every validator on the network, specially four years into the future.
- I believe that the risk of any given validator going offline (leaving the active validator set) is significantly higher than the risk of two OG, NEAR-native liquid staking solutions somehow stopping operations.
- As I understand it; if a user locks stNEAR or Linear for four years to receive veNEAR. And one or more validators go offline, Meta Pool and Linear are still able to withdraw assets from validator (non-custodial) and redistribute.
- The risk of an individual validator going permanently offline is the most severe one. We also need to consider the risks of a validator having very poor performance (and users being locked with them for four years), or, most concerningly, a validator raising the fees significantly after securing a lot of veNEAR delegation.
- Once again, the risk of any individual validator abusing fees due to lockups is significantly higher than the risk of our only two OG, NEAR native operators (who both have fees on NEAR that are considerably Lower than standard LST fees elsewhere.
Ultimately, we have to decide whether we want a system that places the onus of choosing a good long term validator on the user (assuming that is possible to do so). I would do an actual consultation of stakers, not current validator operators, and present them with both alternatives and both set of risks. Would you rather lock an LST, and them automatically delegate your NEAR over the lockup period to best performing validators, or to trust ONE validator to be there long term and not change fees.
Codify expectations with LSTs
I have a strong preference for LSTs. However, in the interest of addressing the valid concerns raised, I propose the following:
- Enable more LSTs to join the proposed governance framework over time. This would ensure that the landscape stays competitive over time. (i.e. is X operator joins NEAR 18 months after governance framework goes live, the contract can be upgraded accordingly to allows their LST to be locked for veNEAR).
- Set a maximum fee from LSTs in order to be eligible for Governance Framework. In the same way that LSTs currently require individual validators to set their fees at 10% or lower in order to allocate delegation to them, the governance framework can set a maximum amount of fee that LSTs are allowed to implement in order to be part of framework. Rather than imposing limitations on LST providers, the idea is to provide long term reassurance that fees won’t exceed (whatever the highest acceptable threshold is for the industry).
- LSTs to create ways to allow stakers who migrate in order to participate in governance to signal which validator they want their stake to be delegated to. Currently Meta Pool allocates a % of all their stake to validators that their community votes for (with their token). I believe a similar, simpler model can be implemented where, if someone locks stNEAR or Linear, they also get to tell the LST provider where to delegate the equivalent amount of NEAR (everything else remains the same, if validator goes offline or performs poorly, the delegation can be reassigned to other operators).
At the moment, a TINY amount of NEAR is liquid staked. And, to be brutally honest, a significant amount of it comes from NEAR Foundation in efforts to decentralise the network and support small operators. I would personally welcome community governance as an opportunity to increase the share of LSTs and in turn, spread out the NEAR more widely. However, I would also support people being able to choose their validator via LSTs.
Incentives to veNEAR Holders
Allowing users to stake NEAR directly with validators would also require us to review the Incentives to veNEAR holders.
- The incentives for veNEAR have been calculated based on the opportunity cost of LSTs
- If a user stakes NEAR directly with a validator and then locks the stake to obtain veNEAR, there is no opportunity cost.
- Interestingly, the proposal also acknowledges the risk of veNEAR APY being higher than staking, if too many people deposit ‘naked NEAR’ for governance then the network security may suffer if there aren’t enough stakers. In this case, allowing for direct delegation to validators and locking would actually mitigate this risk. (Would it replace ‘naked NEAR locking’? Or we just have the additional option?)
- With the estimates provided, with a meagre 10m NEAR locked for governance, we would require 580,000 NEAR for veNEAR APY. This is over 10% of the 0.5% inflation rewards allocated to Treasury (~5m per year). I believe 10m is a low estimate considering the 500m+ currently staked, which means cost of running program could easily exceed the amount of funds allocated to it.
- Does it make sense to offer veNEAR rewards to people who stake directly with validators and do not incur any opportunity cost? Obviously not, but then we are facing a new set of issues around potential ‘discrimination’.
As shown in the table above, as the total NEAR locked in veNEAR contracts increase, the minimum required annual NEAR rewards paid to veNEAR holders will also increase to maintain parity with other on-chain sources of yield. It is important to note that as veNEAR gets fully adopted, budget constraints will be a challenge the community must address in the future. As the veNEAR supply grows, the required annual spend to fund veNEAR rewards will also increase.
Incentives for Delegates
In general, I like setting a minimum % of delegation for Delegates to be eligible for incentives. I also like that it is based on participation, which perhaps could be more explicit in it requiring Delegates to always share their reasoning. I do have some questions;
- Who determines the total amount of rewards to be distributed to Delegates?
- Is there any modelling or examples from other ecosystems with a similar framework where we can see the distribution of delegation across Delegates?
2.1 Assuming a standard 80/20 distribution, I am worried that determining the Total Amount of Delegation to be distributed to Delegates will be very hard as, assuming they all have roughly the same participation (Voting), 20% of delegates are likely to receive 80% of rewards (upper echelon may seem to be earning A LOT, while the rest and lower echelons may seem insufficient). I understand the market forces in people determining who they want to delegate to (no issue with that). My issue is in reverse engineering the total size of the pool based on what any given individual receives and the perceived notion of ‘fairness’).
- To tackle this I would consider having predictable formulas to set delegate rewards (before Delegates are appointed and delegation distributed to them).
3.1 This could include setting a fixes % of the total funds available to Delegates.
3.2 Calculating how much would be the bare minimum for a delegate with 0.5% of delegation and 80% voting participation, then calculating the rest from there.
3.3. Open to suggestions.
Conclusion
I really like the proposal. There are some areas to clarify and improve upon. Grateful to have the opportunity to comment on it as a general member of the community.
[If you read this far. Thank you. Satoshi would be proud. LFG]
