search

near / NEPs

The Near Enhancement Proposals repository
https://nomicon.io
208 stars 137 forks source link

[Discussion] Voting criteria for the transition to Phase II #115

Open viktorbunin opened 4 years ago

viktorbunin commented 4 years ago

Validators Vote for the Transition to Phase II

Update 10/5/2020 - NEAR token holders can see which criteria different validators are using to vote Yes to enable transfers here.

The NEAR mainnet launch process is truly unique in seeking to launch in a completely decentralized manner. Starting on September 24th, the NEAR Foundation will no longer be running any validators on NEAR Mainnet, making it a 100% community run network. This is Phase I - the network is functional and decentralized, but does not yet have transfers or inflation. At this point, it is now our shared responsibility, as a community, to carry the network forward and complete the full mainnet launch via decentralized governance.

The full launch process is covered in detail here, but in brief, Phase II will enable token transfers and protocol rewards, and will need validators to accomplish two distinct actions:

Phase II Vote Criteria

The vote is the first step in proceeding to Phase II. The NEAR community are the decision makers, so it’s important that we all work together to make a good one.

What does the community want to see before voting to enable token transfers and begin launching the unrestricted mainnet?

To start the conversation, below is an initial list of criteria. Questions, feedback, and suggestions are welcome. This list is by no means exhaustive, and everyone is welcome to use whatever criteria they want to vote whichever way they want. But if we are able to align on the launch criteria, we hope it will make it easier to have a successful launch of the NEAR unrestricted mainnet.

Infrastructure

Network Stability

Upgrades

Security

Token Holders

Wallets and Stake Management

Foundation

Communications

Next Steps

  1. Provide feedback on the criteria using this github issue
  2. We will work with the NEAR team to schedule two community calls, one on Wednesday the 30th at 9pm ET and one for Friday October 2nd at 12pm ET.

As a reminder, these criteria are not rules or mandatory, and everyone is free to vote as they please. Bison Trails’ involvement here is to help shepherd the process and work alongside the community to collaborate in service of a successful mainnet launch. When the community agrees on criteria and NEAR is meeting the criteria, we will initiate a vote if one has not been initiated, and we will support with a vote in favor to unlock transfers.

This was prepared by Bison Trails for informational purposes only and is not intended to be legal, tax, financial, investment or other advice, nor is it a recommendation or endorsement of any digital asset or network. Bison Trails may have a financial interest in, or receive compensation for services related to, the aforementioned digital assets and networks.

bowenwang1996 commented 4 years ago

There is a plan in place for the upgrade to enable inflation, including a dry run on the testnet. Bonus if rollback plan also exists, but is not a blocker for launch.

Regarding a dry run on testnet: the PR that enables inflation will land on testnet next Monday. However, it will be a no-op for testnet since testnet already has reward enabled. @viktorbunin what do you think?

gaia commented 4 years ago

a) "Security program is in place to report bugs and vulnerabilities" is a bounty program included?

b) "Any ongoing audit is sufficiently completed, and if critical or major bugs are discovered, they are resolved" is this audit being done by an external entity?

A & B are not especially relevant as a launch condition, but would increase assurance that the platform is sound and has obvious ongoing benefits.

c) "A custody provider (e.g., Coinbase Custody) is ready" there is an obvious conflict of interest here, as Bison Trails has a relationship with Coinbase as a service provider. Enabling a Coinbase as "custody provider" is giving a mainnet seat for a Staking as a Service provider that has so far, AFAIK, not contributed to testing, feedback or securing the network. Additionally, having a custody provider at launch is something AFAIK no network has had at launch, and IMHO has no pertinence in a launch criteria set. Lastly, Coinbase in the validator set would surely increase centralization.

adrianbrink commented 4 years ago

There is a sufficient number of nodes (30+) running the network

I think the pure number of nodes is not a very good indicator, since all of those nodes could be run be the same person on a single AWS machine. A better criterion would be "There is a sufficient number of unique (30+) validators running the network.". Here unique is somewhat open-ended and should encompass at least the following meanings: decorrelation, independence, uniqueness, decentralisation. We can probably add more to this list, but I hope that this clarifies what I mean by unique.

adrianbrink commented 4 years ago

All P3 or higher bugs are closed Any ongoing audit is sufficiently completed, and if critical or major bugs are discovered, they are resolved

Is this feasible? How many open bugs are remaining and how many audits are ongoing?

Under the section for Upgrades I would additionally add the following:

This point comes from the experience of the cosmoshub-2 upgrade, which didn't work and at which point it was unclear what validators should do in order to recover. During those 6 hours we as validators effectively came up with an ad-hoc disaster recovery plan and it wasn't the best experience and could have potentially been exploited by an adversary.

Token holders already claimed more than 100 Million tokens

What percentage does this represent and is this condition compatible (or redundant) with this condition under Infrastructure "There is a sufficient amount of stake (200m NEAR, out of 750m available for staking) online"?

The next 4 points from "Wallets and Stake Management", "Foundation", and "Communications" should be optional at most, since otherwise we are blocking the launch of a decentralised network on the actions of a couple of external parties (Coinbase and other custody providers) as well as on internal parties (Near Foundation and Near Inc).

stefanopepe commented 4 years ago

@gaia I want to add some information to the debate:

@adrianbrink

ashertnear commented 4 years ago

There is a sufficient amount of stake (200m NEAR, out of 750m available for staking) online

Contributors are still receiving token claiming information this week (and potentially into next, @ilblackdragon could confirm). It is possible that we could meet this 200m NEAR requirement without all contributors having received their tokens.

I would suggest making it a requirement that all tokens have been distributed by NEAR Foundation + 3 days (at a minimum) to allow time for contributors to claim.

ilblackdragon commented 4 years ago

Want to mention few things on the token distribution.

viktorbunin commented 4 years ago

@gaia I want to add some information to the debate:

@adrianbrink

  • You can find the list of nearcore bugs here. Do you believe we need to include other software to the perimeter?

Thank you @jimmy3dita! Do you have an estimate when the bug bounty program will be live? It would be amazing to have it live before Phase 2, but I do not believe it should be a blocker.

@gaia, on the custodian side, the only bit I’ll add to what Stefano said is that many early investors in NEAR and other token projects are obligated to use a custodian and are otherwise not able to claim their tokens. This is why custodians were included in the proposed criteria.

viktorbunin commented 4 years ago

There is a sufficient number of nodes (30+) running the network

I think the pure number of nodes is not a very good indicator, since all of those nodes could be run be the same person on a single AWS machine. A better criterion would be "There is a sufficient number of unique (30+) validators running the network.". Here unique is somewhat open-ended and should encompass at least the following meanings: decorrelation, independence, uniqueness, decentralisation. We can probably add more to this list, but I hope that this clarifies what I mean by unique.

I think this is a good point @adrianbrink, but how would we check for uniqueness? We can’t require validators to give up their identities if they choose to remain anonymous. I am hoping we can agree on a confluence of factors that will determine sufficient “uniqueness” on the network. In my mind, this comes down to how much stake is online. Right now, with very little stake online, it’s easy to sybil attack the network and get many validators in the active set, but once the amount of stake starts rising, it’ll become increasingly harder for a sybil attack to meet this criteria.

All P3 or higher bugs are closed Any ongoing audit is sufficiently completed, and if critical or major bugs are discovered, they are resolved

Is this feasible? How many open bugs are remaining and how many audits are ongoing?

Great question! @bowenwang1996 or @jimmy3dita is this something you could comment on? I also believe you might not be using the P classification system for bugs - is there a way that you can see this point being adjusted to better match where you are?

Also, I believe you shared earlier that there is no audit ongoing. While I am still comfortable keeping this as a criteria, it appears that it is not directly applicable at this time, meaning it should get a big check!

Under the section for Upgrades I would additionally add the following:

  • [ ] A recovery plan is in-place that describes the process for reverting back to a known good software configuration and network state in case an upgrade fails, either by corrupting state or failing to start.

This point comes from the experience of the cosmoshub-2 upgrade, which didn't work and at which point it was unclear what validators should do in order to recover. During those 6 hours we as validators effectively came up with an ad-hoc disaster recovery plan and it wasn't the best experience and could have potentially been exploited by an adversary.

This is a great point. That was a really painful experience. I was wondering whether this should be a must-have or optional criteria. I can add it to the list. What do other folks from the community think?

Token holders already claimed more than 100 Million tokens

What percentage does this represent and is this condition compatible (or redundant) with this condition under Infrastructure "There is a sufficient amount of stake (200m NEAR, out of 750m available for staking) online"?

Oof great catch. This is (now) redundant since the 200m NEAR staked requirement was added. I’d like to remove the requirement. Does anyone have strong opinions on this point (or edits) before we do so?

The next 4 points from "Wallets and Stake Management", "Foundation", and "Communications" should be optional at most, since otherwise we are blocking the launch of a decentralised network on the actions of a couple of external parties (Coinbase and other custody providers) as well as on internal parties (Near Foundation and Near Inc).

I can see where you’re coming from. To be clear, I think all of the conditions you highlighted are already met, so right now we are mostly talking about what the best possible protocol launch looks like, not what is blocking NEAR.

While I agree these points are optional to do a barebones launch, I believe they are mandatory for a great launch. If folks can’t manage their stakes, token holders and developers don’t know what’s going on, and the governing body that’s meant to control the treasury isn’t established, the mainnet launch can become very messy, and quickly. The exciting thing about seeing so many protocols launch this year is that with every launch, community expectations are raised a bit and the bar is set higher for what everyone expects. This is a good thing! It aligns with NEAR’s standard of excellence.

bowenwang1996 commented 4 years ago

Great question! @bowenwang1996 or @jimmy3dita is this something you could comment on? I also believe you might not be using the P classification system for bugs - is there a way that you can see this point being adjusted to better match where you are?

We do not use the P classification system and yes, that is something that we can improve on. All I can say is that we right now do not have any outstanding issue that would block the launch.

ilblackdragon commented 3 years ago

Just to update here, it's public data but it's hard to query it right now:

astrostakers commented 3 years ago

astro-stakers Near Protocol Phase 2 criteria

Given that:

After careful consideration of the above factors and the feedback received from our delegators, astro-stakers team is voting YES for Near Protocol Phase 2 transition

lootmaster commented 3 years ago

This is literally just to enable transfers and staking rewards.

Let's pass this and get the show on the road.

kucharskim commented 3 years ago

This is list of criteria which are important for Chorus One:

Ordered from most to least important. We hope, all above are met before 9 October 2020. Last bullet point may be difficult to achieve and it's out of control of Chorus One or NEAR team, so we may vote before 105M $NEAR is delegated.

Also created https://github.com/near/phase2-validator-votes/pull/5

EDIT: We voted Yes on October 13 2020

viktorbunin commented 3 years ago

Amazing, thank you for providing your criteria @kucharskim of Chorus One, @astrostakers of Astro-stakers, and @Pete-LunaNova of LunaNova (link here).

As a follow up from last week, I've gone through the list of criteria and updated it based on feedback. Specifically, I added

Lastly, I marked off which criteria I believe are currently met. We're making great progress and I am still looking for community feedback on the criteria. But at this point, we are also looking for when we should vote Yes to enable transfers! The staking rate is still rising rapidly so I'd like to see it hit 200m before voting yes, but if it starts slowing down significantly and unnecessarily delaying the launch, we may have to vote Yes early for the protocol's sake.

As additional stake comes online, I encourage validators to post their criteria / decision making process as a pull request here (and optionally as a comment on this thread). There's still hundreds of millions of NEAR tokens that need to be staked, and this is a great opportunity for NEAR token holders to delegate to mission-aligned validators who share their values.

bowenwang1996 commented 3 years ago

The test we use to test enabling inflation: https://github.com/nearprotocol/nearcore/blob/enable-inflation-dry-run/pytest/tests/sanity/enable_inflation.py

How to run the test

In nearcore repo, do

git checkout enable-inflation-dry-run
cd pytest
pip3 install -r requirements.txt
python3 tests/sanity/enable_inflation.py

How does the test work

The test spins up 4 nodes, 3 with protocol version 35 (without inflation) and one with protocol version 36 (with inflation) and the genesis has inflation disabled. In the test epoch length is set to 20. The test first asserts that, after 2 epochs the total supply doesn't change, meaning that there is no inflation. Then the test stops the nodes with version 35 and upgrade them to 36 and restart. After 3 epochs, it asserts that exactly one epoch worth of reward is minted and that validators, as well as protocol treasury, receive the correct share of the minted tokens.

htafolla commented 3 years ago

Here are the criteria for the Open Shards pool vote:

ilblackdragon commented 3 years ago

@htafolla Only ~200M NEAR was distributed so far.

htafolla commented 3 years ago

@ilblackdragon There was a discussion on MainNet validators a couple of days back that indicated 375M in lockup contracts based on a script. My criteria is updated to 100M.

viktorbunin commented 3 years ago

Hey folks, I love seeing the discussion around the amount of stake the community wants to be delegated before voting yes. I'd love to get a pulse check on how we're feeling about the number.

The thinking behind setting it at 200m was to find a number that was low enough to be reachable in a reasonable amount of time, but high enough that it gave folks sufficient time to claim their tokens and stake, while ensuring the network is decentralized from launch. At the current pace, it seems there's about 10m in new NEAR staked per day, so we're making great progress, but that also has the potential to slow down as folks slow down in their claiming/staking process.

As an informal poll to gauge community sentiment, please emoji-react to this tweet based on what you think this minimum should be. For reference, there's 87m NEAR on active validators and close to 100m when including validators not currently in the active set. 👀 - for 100m NEAR 😄 - for 150m NEAR 🎉. - for 200m NEAR

htafolla commented 3 years ago

@viktorbunin my only concern here is that there are only 200M NEAR distributed. What is the number expected to increase to in the coming weeks? A more fitting question for us to agree upon may be what percentage of distributed NEAR should be delegated to suffice a reasonable amount?

viktorbunin commented 3 years ago

@htafolla the total stakeable tokens on day 1 is 750m among the team, foundation, investors, community, etc. So while I think some number of folks are waiting for custody support, I would imagine more than 200m will be claimed in the coming weeks. Even if no investors claim their tokens, that still leaves more than 500m NEAR that is claimable and stakeable.

Could you help me understand why the percentage of distributed NEAR that is delegated would be a better metric? This seems like either a much easier or much harder target to hit (depending whether we set our sights at a higher or lower ratio than where we are today).

Additionally, I am not sure whether it tracks success well - is a staking ratio of 55% when 55,000 tokens are staked out of 100,000 claimed better than a staking ratio of 50% when it's 500,000 tokens staked out of 1,000,000 claimed? I think the second scenario is healthier for the network since it is objectively more security.

htafolla commented 3 years ago

@viktorbunin I think your feedback is great! The key point for me in having this type of metric is to ensure that a large enough pool of the community has cast their vote by delegating. I also believe that the total number of available NEAR to be staked is an important piece of the equation as it gives validity to the metric itself.

Can you please provide more insight on why 200M NEAR delegated is a good metric? Is it because that will be the amount of NEAR claimed in the short-term? I'm really seeking to understand here, in order to adjust my metric accordingly.

gaia commented 3 years ago

In agreement with the OP as it stands today, I have some suggestions aligned with @htafolla's, but with some modifications

On another note:

It is clear that holding back on the vote is harming our chances at growing our stake. Some validators are taking advantage of this to gather stake. It was a mistake to put the proposal on chain before the criteria was decided and we are seeing, unsurprisingly, game theory at play.

Is there a plan to counter this ongoing effect? Why should we hold back on the vote?

UPDATE: We have voted https://t.me/cryptonear/26830

gvsfans commented 3 years ago

Team. Now that the 2FA issue has been resolved.. Can the validators go ahead and vote. The delay in voting is making people nervous and communication in multiple channels. Discord/Github/Emails/Twitter is not uniform enough and broadly the community wants the P2 to finish as we have more or less finished most of the objectives. @ilblackdragon @htafolla @viktorbunin

cshih1 commented 3 years ago

Hey folks, I think Phase two shouldn't be activated until all custody options listed here support delegation.

Currently, the only supported wallet is Ledger and Near wallet is adding delegation support soon, but it's uncertain when other popular wallets like Trust Wallet (recommended as #1 option for mobile wallet in the official doc) and Math Wallet (widely used in China) are going to support delegation.

The fact that many recommended custody options listed on the official doc possibly won't be able to delegate and receive rewards is insufficiently communicated to holders when they created the wallet. Most NEAR tokens are vesting for 1-3 years so holders are stuck with their initial wallet option.

azhang2013 commented 3 years ago

@cassandrashi based on my understanding, the timeline for other native wallets like Trust and Math to support delegation in app could be as long as several months... so I don't think that should be a hard requirement for Phase 2.

NEAR wallet should be able to support delegation soon tho :)

gvsfans commented 3 years ago

@cassandrashi as @azhang2013 mentioned waiting for support from the native mobile wallets will take several months and this will not be good for community or developers who want to build and the overall ecosystem. This will be extremely counterproductive. Since Bridge is working as intended and Defi/NFT ecosystems are getting bogged by high transaction fees, we should allow NEAR ecosystem to thrive and even in the short term, some of these holders are not able to delegate from their Mobile wallets, since you have enabled transfers, they will transfer it to the web wallets and delegate.

@ilblackdragon @viktorbunin Please input your comments and suggest the best path forward. While we can be idealistic and wait for all wallets to enable delegation/staking, it hampers our ecosystem growth

cshih1 commented 3 years ago

Is there any workaround for holders who claimed tokens on Trust or Math wallet to be able to delegate, participate in governance, and receive staking reward in the short term?

awrelll commented 3 years ago

@cassandrashi Trust wallet seeds can be imported into near wallet and then staked with https://staking.dokia.cloud/staking/near/validators

ilblackdragon commented 3 years ago

Note, that it's only possible to import existing account into NEAR Wallet. If you only create a new wallet in Trust Wallet, but it doesn't have any funds in it - you will not be able to open it in NEAR Wallet.

gavinly commented 3 years ago

Under the section for Upgrades I would additionally add the following:

  • [ ] A recovery plan is in-place that describes the process for reverting back to a known good software configuration and network state in case an upgrade fails, either by corrupting state or failing to start.

This point comes from the experience of the cosmoshub-2 upgrade, which didn't work and at which point it was unclear what validators should do in order to recover. During those 6 hours we as validators effectively came up with an ad-hoc disaster recovery plan and it wasn't the best experience and could have potentially been exploited by an adversary.

This is a great point. That was a really painful experience. I was wondering whether this should be a must-have or optional criteria. I can add it to the list. What do other folks from the community think?

Hey @viktorbunin, echoing @adrianbrink's sentiments--having a recovery plan will also be important to Figment. We used these instructions to migrate from cosmoshub-2 to cosmoshub-3, for example: https://github.com/cosmos/gaia/blob/master/docs/migration/cosmoshub-2.md

Mike-LunaNova commented 3 years ago

LunaNova have built on the great work of the community and added as necessary. Consequently we have established a spreadsheet of around 28 criteria of which around 19 are important in our view. Of these 14 are satisfied at least 6 of which have good available evidence.

Please see the spreadsheet here. It is available to comment but not edit.

In the ideal world we would push for all criteria to be met with objective and ideally independent evidence of this. Furthermore, we would pursue a risk analysis so that we could truly understand the factors affecting this decision.

The pragmatic view is that good progress has been made so far and that we do not want to stifle further progress in any way, however we think it prudent to ensure the following are met before we move to phase 2:

These are crucial to give us the insurance that should we run into problems we can promptly and efficiently remedy the situation. From our perspective all that remains is to agree who will be responsible for delivering these items and when we can expect them.

As soon as we have sufficient clarity on this we will move to vote in favour of making the transition to Phase 2.

ama8999 commented 3 years ago

Community member opinion. Would you consider implementing a max stake cap for validators in future steps, so that decentralization is ensured?

Laricous commented 3 years ago

Here are some issues I see.

1) Requiring 150-200M in delegation before opening the network entrenches the initial validador set against competition. Essentially we must make them mega nodes before they will open the network. This will have centralization effects for years. The core team only requires 74M to vote yes, which is easily achievable today. https://explorer.near.org/

2) There are likely hundreds of validators wanting to come online and compete for delegates but cannot until the above threshold is met. This in practice forces us to delegate initially just to open the network to then undelgate and wait the unbounding period. While also not being able to compete against the initial validator set for delegates. This is bad for decentralization.

3) Having a recovery plan is fine. Initial validators are vetted and could easily coordinate a recovery today. However any plan made today is of little utility without the input for the full validator set which cannot happen until the network is opened up. I think coordinating a recovery in an open system like NEAR will be much different than a closed and vetted validator set like Cosmos. So I recommend spending serious time on the recovery plan once the network is open, so you have community buy in.

4) The only reasons to keep the network closed is for any known bugs, testing, and possibly coin distributions.

My primary concern is forcing many people to delegate only to the initial validator set to meet an arbitrary threshold before they will open the network. This is effectively a ransom which could lead to cartel formation long term because of node size. I realize this is not intended but it is a second order effect.

ilblackdragon commented 3 years ago

Given it's still hard to query this information - want to point ~220M NEAR tokens distributed into lockups. We are working on finishing up indexer to be able to query all *.locker.near accounts so we can surface this in explorer and other tools.

To @ama8999: I don't think max stake makes sense - as it just leads to validators splitting their stake into multiple validators. What make sense is educating community about importance to distribute stake among wider range of validators.

To @Laricous points:

Given vote above, it seems like most people support 100M staked as an amount. I do think some amount staked is important, even for a health of the system, to make sure there is no way that large holders delegating to a single node can accidentally stall the network.

At the same time, I want to make sure it's clear, that there is no restriction on who can start a node / create a pool now by anyone who participated in the stakewars. If you are having trouble setting up - ping accounts@near.org

These pools will have the same issues though - they will need to either have their own capital or attract the delegation from community. Which they can do if they clearly communicate for example how they will contribute to the vote or otherwise propose why community should delegate to them. So if you want to delegate to new validators - please do. You can see all active pools (even the ones that don't have a seat yet) here - https://near.zavodil.ru/?pools=

Going forward there is a proposal to adjust the validator selection https://github.com/nearprotocol/NEPs/pull/83 This would still be stake weighted, just increasing number of unique validators by removing seat price.

Also I would be open to discussing more forms of governance where it's not validators who are representatives. E.g. different forms of liquid democracy. But at this point - we can't really adjust much - it's all encoded in the smart contracts.

I think most of the validators has been postponing due to (4) - making sure it's all tested and also all tools are working for everyone. Which sadly, we had been a bit delayed on all the tooling support - like 2FA accounts working with external staking UIs.

d1miner commented 3 years ago

D1 and some other validators just withdrew our votes for Phase 2. Many people from the community are asking us why we did this and we would like to explain and ask more people to join us.

There are two main reasons for our decision.

One is because there is still issues with the tooling support and staking in NEAR Wallet only got released yesterday. We would like to see more people delegating first and also resolution of issues around creating new accounts inside NEAR Wallet (right now the only way to do this is by using Trust Wallet first and then importing account into NEAR Wallet later).

Given Huobi and OkEx pools have not voted yes yet, it might indicate that they are also not ready for listing yet - so this would give them more time to get ready as well.

The other major reason is that Filecoin is going to launch this week and we feel it would be a bad time for NEAR to get listed around the same time.

Therefore, we hope we could give NEAR a few more days to get ready, and would love to see more other validators joining us to actively vote for the best of NEAR.

loca555 commented 3 years ago

fu

electroxts commented 3 years ago

(d1miner) > sounds like complete nonsense and a set of unrelated factors in favor of justifying their volatile position (what right do you have retroactively to change your decision!) what should the users who delegated to you do? because you signaled YES

all this looks extremely incompetent on the part of the community you large funds attract steak by voting YES (remember these pool names bisontrails, figment, huobipool, chorusone, okexpool and never delegate your funds to them) this else looks like a collusion of whales

why would you play their games?

Take an example from dokiacapital, zavodil.poolv1, erm.poolv1 pools normal people don't change their decisions if it says YES it means YES

everuner commented 3 years ago

D1 and some other validators just withdrew our votes for Phase 2. Many people from the community are asking us why we did this and we would like to explain and ask more people to join us.

There are two main reasons for our decision.

One is because there is still issues with the tooling support and staking in NEAR Wallet only got released yesterday. We would like to see more people delegating first and also resolution of issues around creating new accounts inside NEAR Wallet (right now the only way to do this is by using Trust Wallet first and then importing account into NEAR Wallet later).

Given Huobi and OkEx pools have not voted yes yet, it might indicate that they are also not ready for listing yet - so this would give them more time to get ready as well.

The other major reason is that Filecoin is going to launch this week and we feel it would be a bad time for NEAR to get listed around the same time.

  • Token listing is a perfect marketing opportunity for a layer1 ecosystem, when investors and developers have incentives to learn more about the eco and how to interact with it.
  • The market has limited capital and attention.
  • Filecoin has created so much hype around the world (especially in China). When it gets listed there will be a lot of noise, eg. some people will be making money, some getting scammed by mining machine producers or OTC sellers, etc.
  • A lot of developers/investors who are supposed to pay attention to NEAR will be distracted by all that noise, and NEAR will lose this window to attract more developers and supporters, and token holders may lose the potential high returns when a lot of the capital are FOMOed to Filecoin.

Therefore, we hope we could give NEAR a few more days to get ready, and would love to see more other validators joining us to actively vote for the best of NEAR.

I don't understand if this is filecoin shilling or is it really an act of weak people's 😕😕😕

bryan-excell commented 3 years ago

Have we found an incentive misalignment? D1 can strategize all they want with filecoin launch and, in a certain respect, contribute to holding the chain hostage.

Also, the initial set of validators have every incentive to do what ever they need to, to collect delegators and thus grow to become huge and centralize the network around themselves. Even if it means pushing the vote back.

The formation of mega node cartels has hurt chains in the past.

viktorbunin commented 3 years ago

Hi folks, I love all the great discussion happening here in this thread and other channels. This is how you build a decentralized and active community!!!

Based on our very informal emoji poll and the conversations we’re seeing in other channels such as twitter, telegram chats, and discord, it seems clear the community is overwhelmingly in favor of lowering the staking requirement. Rough consensus is for a target between 100m and 150m NEAR. As such, we’re updating the proposed community criteria from 200m in staked NEAR to 115m NEAR. This means this criteria is now met.

The NEAR team released their recovery plan in case of a failed upgrade last night. This was the last item remaining on the community-define criteria list above. As an added bonus, the document also defines a tagging system for upgrades to help validators react and upgrade at the right pace - give it a read!

Lastly, the token delegation flow also went live on the NEAR wallet, meaning that NEAR token holders have even more options to stake.

Not all custody providers are ready and not all wallets that were expected to support delegation are ready, and a few folks are still having technical issues.

However, it’s safe to say the mainnet launch criteria that we put together with the community are now met. Bison Trails will be voting to enable transfers later today. Everyone is encouraged to continue to monitor the network and vote to enable transfers once they feel ready.

As a NVAB member, I recommend that the NEAR team delay the release of the nearcore upgrade to enable inflation by a few days (instead of releasing right after the vote passes). This should give folks a final reminder to claim their tokens and stake before inflation turns on!

viktorbunin commented 3 years ago

Hi folks, everyones likely following along, but just wanted to mention here that the vote passed last week and today the NEAR team released the nearcore upgrade to enable inflation. We already upgraded and encourage other folks to take a look at the new release and upgrade when they feel comfortable. Excited to finish the launch!