Was asked to start this topic by Christine.
I am one of the GFMs that chose to run my own hardware and not to delegate to a pool in the spirit of making the network as decentralized as possible, however this came at the cost of me only hitting a single canonical block (has several orphans) about 7 months ago. According to Gareth I am 1 of 6 GFMs who have not met the requirements: Discord
Does this mean that we are SOL no matter what we do?
Hey, welcome to the forum!
I am 1 of 6 GFMs who have not met the requirements: Discord
Could you eleborate on that as we, none GFM, can not access that Discord channel and the coresponding messages?
Does this mean that we are SOL
Do you mean by “being SOL” that the network is (highly) centeralized, or rather not as decentralized as we would want it to be?
He’s referring to the T&C of the Genesis Program, see entry 12 on https://minaprotocol.com/tcGenesis. The requirement is that you need to get block rewards equivalent to at least one block within a year, be it from staking or from BP-ing. The probability of satisfying the requirement was calculated to be 99.98% I think, but it does a bit of room for edge cases.
Mind you the calculation was based on random block selections. I must also say, as an observation, that the VRF used by Mina is not very random, the spread of the Top 120 BPs with almost the same stakes are quite large after a few months.
Hi Mate,
As soon as i failed producing my first 1 block i decided to delegate(1st epoch). now a few months later, i have 9.x points and im running my own node again.
talking about your situation , i think if you delegate now (maybe you did already) in 2-3 epoch you will meet the requirements.
I think the VRF is random, what is not random is the performance of the block producers (failing to produce, producing too late etc…).
More generally, here is the script I ran and the results which left just 6 GFM members failing to reach the threshold - 5 had not produced at all, and 1 only started producing late in the year as part of a delegation so hasn’t yet fully met it.
I know of at least 3 of these remaining 5 who either generated their keys with the outdated keygen tool and were unable to access their funds or can not otherwise access their keys. So with goldebrot that would leave just 1…
In my opinion, the intention of the programme has been met, with the vast, vast majority staking. It seems unwise to dedicate additional resources to this “enforcement” when given the huge incentives to stake via block rewards, it seems most likely those who have not are simply unable to do so, or very unlucky. Additionally, there were already many opposing views to the potential of a hard fork to confiscate funds.
The terms were for 4 years staking (other than an unintentional quirk with the initial cohort who are only required to stake for a year), so this does leave open the issue for the remaining years. However, due to the incentives of the block rewards (the median reward for a GFM through epoch 17, just staking the locked 66k was ~5760 MINA), the simplicity of delegation and the already high rate of staking by GFMs I’d be in favour of doing nothing more on this.
My 2 cents………there’s plenty of time to delegate for a few epochs to meet the requirement. I purposely started as a delegation from launch to ensure meeting the obligation I agreed to at the issuance of the grant. For me it was more “I don’t trust my tech abilities” than anything else. Given that you have time to satisfy the staking requirement, I’m not one in favor of moving the goalposts. I would delegate, meet your requirements and then redelegste to yourself to continue tuning your node. It really is the simplest solution.
FWIW I completely agree with this sentiment and anyone who still can certainly should strive to meet it. I guess I was more on the side of efforts could/should be better directed elsewhere than enforcing this given the trivially low number of non-conformists - which I largely put down to them not being able to stake (given the rewards they are passing up) rather than not being willing.
I agree with Gareth here.
I came here to share my thoughts on this given that I authored the original GitHub issue on the proposed enforcement system of the grant rule, but I think Gareth did a great job of doing this for me 
.
Yes, even as the author of the original thread, I would love to see the community decide to not enforce this rule.
You can view enforcing staking on the network from a carrot/stick lens. The carrot: Staking rewards are quite high, and the protocol rewards you for producing blocks/delegating your stake. The stick: If you don’t delegate/make blocks, your grant is revoked. Personally, I think leaning on the carrot in situations like these leads to a healthier community. Even if the enforcement action were logistically simple (which it is not), it would in a way be redundant. Those who haven’t gotten the points already missed out on block rewards and thus are already punished.
tl;dr I would love to see the community decide to not revoke the funds of these folks that haven’t met the point threshold and for the community to come up with another proposal for what to do incentive-wise the rest of the four years.
Thanks everyone for the really valuable input, now seems like a good time to take a pool. It’s important that the community comes to a decision and the timelines for doing a HF here are getting tight. I’m going to add some more context below so folks have the right information, and the poll itself below that.
Over 660 Genesis Founding Members (GFM) received a token grant of 66k MINA tokens, and launched Mina’s mainnet as the network’s first block producers. One of the requirements for the GFMs in the terms & conditions, is that they must be participating in the network with their stake (either staking or delegating).
Block Production Rule: At every planned hard fork, which will be at least six months apart for the first four years of the network’s execution (starting 11 months in); we observe archive data specifying the staking ledgers and blocks over the last 11 months (anchored around a block at most 12 blocks back from the tip, for ensuring canonicity). If you are running a block producer, you must have at least one block on the canonical chain over this period.
Delegation Rule: If you are delegating, the account you are delegating towards must produce blocks in proportion to the amount of stake being used. For GFMs who did not meet this requirement, their tokens are due burned in the following manner: The “amount” field will be changed to zero and all vesting-related timing info will be stripped from the account.
Grants unlock over 4 years, with an initial cliff 1 year after Genesis Block. The first unlock is due in March 2022. If the community decides to enforce the rule and burn the tokens assigned to the members who did not fulfil their obligations, then a hard fork must take place prior to this date via a MIP to update the balances in these accounts to zero (i.e. a separateHF if the Snapps HF does not make Q1 .
Only 6 GTMs (<1%) members would be affected by enforcing the rules, and would therefore have their grants revoked.
The change to the ledger would require a MIP and a hard fork.
0 voters
Totally agree, the goal was achieved, and it makes no sense to punish people that actually already lost the most as Gareth stated. The initial rule was a great idea as a carrot, but now we can move on from this topic I believe.
Also more anecdotical but Godelbrot is a great community member and actively participated in building it (as it can be easily checked on Discord) 
Voted!
I guess my thoughts are, how to define “Honest”? is that those that have actively been trying to run their own node? If so, I agree that probably shouldn’t burn their tokens (although by delegating now for a few epochs, they can avoid that issue entirely so they have an opportunity to meet the original requirements…I get the pride of running a node and failing so far…why not just delegate and meet it. Honestly, had that delegation been done when this topic started, they likely would have already met the requirement or been close to it making this poll moot…it is for this point that I voted to enforce.). For those that haven’t (either lost their key info or worse have not participated in any way), one could say that they have not done anything to participate so why give a free pass? Of course, how to determine if they have/haven’t. Is there an ability to determine that.
Messing with on-chain balances it tantamount to scarring the blockchain. There is no pressing need to do something so radical. Let the people keep their funds.
In case of the possibility of canceling the grants of these accounts, first of all, the node activity should be examined. For example, although my node has high uptime, I was able to get my first block reward in the 7th month. There may also be some unlucky ones among them.
I believe that the main goal of the original conditions of the GFM grants has been fulfilled and there is no point in punishing 6 people who do not meet the requirements. In extreme cases, their shares are diluted due to inflation and they punished themselves
I can completely see your perspective Mike and appreciate you being honest with your opinion.
For me this is more about how we want Mina to be seen by the wider world (eg as fair, honest and democratic). If there is no real way to determine where the issues were for this small minority then by acknowledging their efforts we can share those values and use the experience as a learning exercise.
Will this rule stays the same for the 3rd and 4th years?
Once there will be 1/2 or 1/4 left on some GFM accounts, the likelihood to produce no block over will increase by a lot…
Then getting staking rewards will prove that GFMs are delegating. It should be enough.
I voted for Not Enforcing the Mechanism because I believe that the first year there may be some misunderstandings about the rules. Besides that, it doesn`t look like a punishment; it is a death penalty. I am against such tough measures.
As for research lab, we need active validator on chain, and so we running 66k + 2k ( 68k ) weighted single unit since genesis, for the same reason we didn’t apply for Foundation Delegation.
Passing trough many codebase problems and random factor our success can be observed here: Mina Block Explorer
This unit carefully controlled by 1000 lines shell script for the liveness porpoise.
We vote “NOT ENFORCE”, but it will be very interesting to gather more information from this six participants who is affected, for the sake of science purely. It is not clear, is it weak hardware behind or absolute bad luck and dark magic or is it case of actual protocol issue which is maybe so far unknown and deserves investigation.
Currently, to include block in to canonical chain become harder and harder and by our observation in upcoming years “decentralization supporters” will be left without any valid blocks ( aka profit ), numbers will increase from 6 to many and so centralization accordingly.
that 6 peoples should share their VRF outputs for each epoch. if they really not earned any slot. thats fine. should not be enforced.
if they earned slots but not produced block due to like not running node etc, policy should be enforced.
I agree partially with this view. I don’t think a all or none (6 or zero) view is appropriate. I still say those 6, if they choose, have ample time to meet the requirement through delegation. If you were to know that one of the six had MF/o1 delegation from genesis and was not participating (returned zero block rewards)due to issues that have nothing to technology, do you think they deserve to not have the enforcement. Maybe since I’m the old man of Mina, my dad skills come out. If I have 2 kids and I tell them both that to go get an ice cream, they both need to clean their rooms by a certain timeframe. One puts the effort in and the other sits and plays video games instead. I have 3 choices: No ice cream for either (frankly my choice since tasks weren’t completed), ice cream for the one that put the effort in (sets example for the one that didn’t put effort in) or ice cream for both despite not producing the required result. This pool seems to be trending towards #3………which to me rewards lack of accountability.