• English
  • Russian
Mina Overview

Guidelines for Participation in Foundation Delegation Program

Check out the Foundation delegation policy. This document has details on exactly what you need to do to pay back rewards if you are receiving a delegation and how to send your uptime data so you can become or remain eligible for recieiving these rewards.

Fill out this form if you want to be eligible for future delegation .

O(1) Labs has separately adopted this guideline in consultation with the Foundation.

This should include all details that a block producer receiving such a delegation (let's call it the "token provider") delegations needs to understand to be compliant and maintain themselves as eligible for this delegation.

Installing and running the uptime sidecar

When participating in the Foundation Delegation Program you will also need to run the uptime sidecar, so please following these instructions and set it up alongside your block producer daemon.

Measuring uptime performance

The uptime sidecar sends recent blockchain data (from your bloc producer node's perspective) to a service that verifies that this recent data is indeed synced with the chain. Specifically, if you have any block producer nodes online at all within any given 10minute window (ie. both your node is synced and the uptime sidecar is sending the data) then you will be marked as online for that 10minute window. Note: You may run more than one node with the same block producer key if you want to increase your chances of remaining up.

Your uptime is measured as a percentage of all possible 10minute windows over a 60-day period. Uptime performance is only looked at over the last 60-days -- the sooner you fix issues with your nodes and uptime sidecar then the sooner you'll be rewarded with a better uptime and a higher position on the leaderboard.

See the uptime leaderboard for the latest realtime performance under these conditions.

Your position on this leaderboard is an important factor in your public key being selected to receive delegation from a token provider.

Payout Addresses

You must send computed rewards as described below to the token provider addresses that delegate to you. If the Foundation is delegating to you, the Foundation will pick two addresses from the Foundation address list at the bottom of the page that will appear as delegations to you. You should distribute the rewards to both those addresses. If O(1) Labs is delegating to you, O(1) Labs will pick two addresses from the O(1) Labs address list at the bottom of the page that will appear as delegations to you. You must distribute the rewards to both addresses that are delegating to you.

Payout Frequency

Rewards must be distributed at least once for a given epoch (but you can also send them more frequently), all the rewards for epoch N must be delivered (ie. accepted in a block, not just sent) no later than slot number 3,500 of the next epoch. This gives you about a week to sort out these payments.

Payout Attribution

In order for the token provider to associate the transaction with your delegation please do one of the following in the transaction(s) where you pay back rewards: (a) send the transaction from the hot wallet that the token provider is delegating to, (b) send the transaction from the coinbase-receiver account that was specified in any of the blocks that your account has created, (c) put the discord id that you signed up for the program with in the memo (d) put the sha256 of your discord id in the memo (e) put the sha256 of your hot wallet address in the memo.

Reward Specifications

You must send back at least the amount specified by this mechanism. If you send back more tokens, you will still be regarded as eligible — but you will not be refunded anything.

At the end of each epoch, do the following:

  1. Compute the total stake delegated to your account for the epoch
  2. Compute the share of stake from the token provider (from both accounts) by dividing the token provider delegation by the total stake. (i.e. provider_share = provider_delegation / total_stake). The resulting share should be between 0 and 1.
  3. For each block produced on the canonical chain calculate the payout by multiplying the non-supercharged coinbase reward (equal to 720 MINA at Mainnet launch) by the provider share calculated in the previous step minus a 5% percent fee. (i.e. payout = (provider_share * 0.95) * coinbase)
  4. Send a transaction to the token provider accounts with the appropriate payout -- please follow the rules in the "Payout Attribution" section with your transaction.

The canonical chain will be calculated as 12 blocks behind any tip at slot 3,500 of the next epoch.

The block producer can keep all of the transaction fees or divide them equally amongst the other members of the pool. Note also, the token provider, Foundation or O(1), only expects to receive the pro-rated share of the coinbase as if it were not super-charged. If the block created was super charged, the extra coinbase can be distributed among the rest of the pool as you see fit. See for details on the tooling and the terms used here for this approach.

Example Reward Payout

Consider the following:

  • Account A has 2 million locked MINA
  • Account B and C are controlled by the Mina Foundation and have 3 million locked MINA each. Both accounts are delegating to Account A.
  • Account D is a controlled by a third party and has 2 million MINA fully unlocked. This account also delegates to Account A.

In this example, the total amount of stake for Account A is 10 million calculated by adding up the balances from all the accounts. Note that since Account D has all its tokens unlocked, any block rewards won when winnerAccount equals Account D will be super-charged.

Now let's consider Epoch 5. The share of the stake from the Foundation is 6 million MINA / 10 million MINA = 0.6 or 60%. Three blocks are produced this epoch that end up on the canonical chain.

The first block has a winnerAccount equal to Account A. The total Foundation payout for this block is calculated as (0.6 * 0.95) * 720 MINA = 410.4 MINA. In the second block the winnerAccount is Account B — the total Foundation payout is again calculated as (0.6 * 0.95) * 720 MINA = 410.4 MINA. The third and final block has the winnerAccount as Account D. Now the actual coinbase is super-charged for this block and will be 1440 MINA, but despite this the Foundation rewards are still 410.4 MINA since they are calculated using the non-supercharged coinbase. Thus the total payout to the Foundation from all blocks is 410.4 MINA * 3 blocks = 1,231.2 MINA .

Finally, before slot 3,500 of the next epoch, two payments are made from any account that this block producer controls to each of the Foundation accounts — remember to follow the rules outlined in the "Payout Attribution" section above -- in this case we will send the transaction from Account A's coinbase receiver. Each payment is 1231.2 MINA / 2 = 615.6 MINA tokens. Note that the transaction fees for these two transactions are paid for by the block producer.

The token provider, either the Foundation or O(1) Labs respectively, will check to see that you have sent back with this mechanism by the middle of the next epoch as described above. Failing to do so, can result in ineligibility for receiving delegations.

Avoiding Rounding Issues

If you have computed a reward that has an odd number of nanomina and need to divide it between the two accounts it is okay to round down and keep the extra 1 nanomina.

If you are computing the share of the stake from the foundation you can calculate the fraction of stake up to 5 decimal places and then truncate afterwards (ie. always round down).

Example1: If the Foundation share is 1 million MINA and the total stake is 3 million MINA, you can use 0.33333 as the stake share fraction.

Example2: If the Foundation share is 2 million MINA and the total stake is 3 million MINA, you can use 0.66666 as the stake share fraction.

Addresses for token providers