First movers advantage for whitelisted Gridcoin projects

When Enigma@home was whitelisted a few weeks ago I noticed in the first days after whitelisting the GRC per 1k RAC was much higher than any other projects. Obviously, this had something to do with a low team RAC and a small number of active users. This made me wonder if there is a first movers advantage when a project gets whitelisted. So when the poll to whitelist DrugDiscovery@home (DD@H) was raised I decided to monitor the effect.

My goal was to test the following:

• Can you gain some extra GRC by changing to the whitelisted project at the start or even before it gets whitelisted?
• What is the impact if you change from a lower earning project vs higher earning project?

On my laptop (Win 10, 8 GB, i5-6200U CPU @ 2.30GHz running 24/7 on 4 cores) I basically know how many GRC I can earn per day for a number of projects. During the tests I used the following 2 projects as reference:

• Theskynet Pogs (POGS): high earner with 2.85 GRC on average per day on my laptop
• Rosetta@home (R@H): medium earner with 1.74 GRC on average per day on my laptop

The maximum theoretical RAC value I can achieve with my laptop is 2828 for DD@H. Based on the first 14 days after whitelisting DD@H, I would be able to achieve the GRC amount per day as highlighted in Table 1.

Table 1: GRC per day based on maximum RAC value

You can notice a substantial difference between DD@H, POGS and R@H in thee first 14 days after whitelisting. Another interesting aspect is how quickly the GRC per day drops for DD@H (from 14.54 to 3.51 after 2 weeks) due to users joining the project but also RAC being build-up by all computers on the project.

The simulation

To obtain a relative accurate result, I created a model based on the RAC build-up presented in chart 2.

Chart 2: RAC build-up in percentage of maximum value

I took the build-up of DD@H and drop-off of POGS/R@H where I calculated the total amount of GRC I could gain over the period 14 days before D-day till 14 days after D-day. The GRC values for DD@H are actual values while the GRC values for POGS and R@H are averages of my system over this period.

In table 3 below you can find the results but first some explanations of the columns in the table:

• On 27-Sept DD@H was whitelisted this means I took the simulation period from 13-Septemer till 11-October
• Column C represent the amount of GRC I would gain if I would move from POGS to DD@H on that specific date
• Column D represent the amount of GRC I would gain if I would keep running POGS without any changes
• Column E is the delta, which means how much more would I have made if I would have moved from POGS to DD@H
• Column F represent the amount of GRC I would gain if I would move from F@H to DD@H on that specific date
• Column G represent the amount of GRC I would gain if I would keep running R@H without any changes
• Column H is the delta, which means how much more would I have made if I would have moved from R@H to DD@H

Table 3: Simulation results

Conclusions:

1. There is a positive first movers advantage when a project gets whitelisted based on the simulation.
   Changing to DD@H at the time of whitelisting provided a 15 GRC advantage for POGS (+18%) and 23 GRC advantage (+47%) for R@H (based on my system and setup)

2. It is even more beneficial to start before projects get whitelisted but there is a peak depending on the project you are currently supporting.
   Changing from POGS to DD@H the peak was 7 days before whitelisting with a 25 GRC advantage (+30%).
   Changing from F@H to DD@H the peak was 11 days before whitelisting with a 42 GRC advantage (+51%)

3. The lower the current project score the bigger the gain you will obtain after the whitelisting.
   After 2 weeks, the first movers advantage is neglectable. At this time, you would only start the project because you support the science behind the project.

Final recommendation

In case you would like to gain some extra GRC based on a to be whitelisted project in the future, I would recommend the following approach:

• Check if and when the project is getting whitelisted
• Start crunching the project 1 week before it is whitelisted (on any system you have available)
• Stop crunching the project 2 weeks after whitelisting
• Move back to your old project

This recommendation is based on the following assumptions:

• DD@H has a common whitelisting start-up with people already crunching for the project, some pre-loaders and people that only start once the project is whitelisted
• DD@H has a normal team RAC build-up pattern once a project is whitelisted, which would apply to future projects as well.

Any feedback is welcome and thank you for reading this article, I hope you found it interesting.