Participation of Genesis Founding Members

The content of this blog post was emailed to all Genesis Founding Members on March 16, 2021.

Mina is powered by participants. 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. They are members who are devoted to the project, built alongside the core team when the project was still in its early stages, and made significant contributions in the last years. 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). But how is this participation enforced?

In February, we conducted an open consultation with the community regarding the tracking of GFM participation. After careful consideration, we have agreed on the following mechanism to ensuring participation from GFMs:

Spirit

The spirit of this mechanism of enforcement is to incentivize GFMs to participate in order to help the network stay decentralized. We do not want GFMs to lose unvested assets unfairly. As such, we choose to be careful with the threshold for getting their tokens revoked. It is also very important we don’t disincentivize GFMs to run their own block producing nodes.

We also strongly recommend GFMs who are producing blocks to opt-in to the foundation delegation program. See this link for more details. 

Process

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 the GFM is running a block producer, they must have at least one block on the canonical chain over this period. If they are delegating, the account to which they are delegating must produce blocks in proportion to the amount of stake being used. Those who are at risk of not meeting this requirement will be warned at least every month (after at least 6 months of data) via an email from the O(1) Labs.

If a GFM does not meet this requirement, their tokens will be 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. This is a good mechanism because it makes consensus slightly more efficient by removing these non-participatory tokens from circulation entirely.

The rest of this document describes why one block in 11 months is a good, safe, fair metric for block producers and provides more detail around the delegation rules. In addition, we mention tooling that will be built to support this process.

The Block Production Rule

Block production is probabilistic. We don’t know for sure who will win which slots or whose blocks will make it on the canonical chain. The probabilistic nature means choosing the “average” as a cut-off point is not ideal; this means around half of block producers won’t meet the cut-off, even if they were performing perfectly.

Since there are more than 600 Genesis Founding Members, we want to be as confident as possible that we won’t have any unfair forfeitures. See some computations below (note: 12 months Math is shown in the screenshot):

via https://keisan.casio.com/exec/system/1180573198

With 66k MINA tokens, over 11 months of data at the current network protocol constants, there is a 99.98% probability that someone operating their node properly will produce a block on the canonical chain. This means that there is an overwhelming probability that a GFM will create a block in that time. This also means that the longer your node is offline, the higher the likelihood the GFM’s tokens will be forfeited.

The delegation rule

Many GFMs are choosing to delegate rather than produce blocks themselves. In order to ensure the network remains decentralized (ie. we don’t want to incentivize all GFMs to delegate to the same account), we want to avoid scenarios such as a flat rate for delegations, as more stake delegated means more blocks.

The metric is instead the following:

For every slot a GFM is delegating to an account, each GFM receives (their stake / total stake) points. Over 11 months, the points must sum over 1 to prevent forfeiture. This also applies to GFMs who are being delegated to by other accounts — you’ll note that this is the same as the block production rule if there is only one account delegating (aka a GFM has a self Hot/Cold setup)

Here are a few examples:

1. A GFM has 66k tokens on their hot wallet. There is 100k stake delegated to the GFM for 6 months and 500k stake delegated for another 5 months. During the first 6 months the GFM produces 1 block: so they receive (66k / 166k)*1 = 0.39759036144 points. During the second fork: the GFM produces 11 more blocks: so they receive (66k / 566k)*11 = 1.39929328622 points. In total, they have ~1.797 points which is greater than 1 so they meet the requirement
2. A GFM has 0 tokens in their hot wallet, but they have a cold wallet that has their 66k tokens in it. Additionally, the GFM has 1 million tokens delegated to them for the whole time period. During the 11 months the GFM produces 50 blocks. (66k / 1066k)*50 = 3.3 points. This is more than 1 point so they pass the requirement

Why is this a good metric: It scales with participation fairly. For example, if two GFMs pool their stake, then they need to make two blocks. It also scales with time delegated; if someone only delegates for a bit, but not when a block is produced, then the scaling factor makes sure that their stake didn’t count and everyone gets more points. Delegation smooths out the variance so they pay a fee for the privilege of less variance.

Note 1: We cannot use the winnerAccount field to fairly measure this metric as when there is more than one winner, it would be economically disadvantageous for a block producer to select the resulting one randomly. They should pick the “better” VRF result. (The current implementation just does “first winner”).

Tooling

O(1) Labs will provide tooling that consumes a PostgreSQL archive database and staking ledger JSON dump files over a time period of 11 months (or fewer for warning purposes). It will implement the logic stated above and can be used for warning and at the official hardforks.

Thank you for reading this documentation. If you are a GFM and have any questions related to this topic, please ask in the #genesis-founding-members channel on Discord.