Points (or credits) are the primary measure of how much computing power members have contributed to World Community Grid. The other measures of contributions (results and runtime) are not suitable for comparison because there is considerable variation in result size, and runtime treats fast and slow computers equally.

Over the years, World Community Grid have tried various improvements to the credit system, attempting to make it fairer, and discourage cheating.

Since points are perceived as having value, it is an emotive subject.

United Devices credit system

Main article: United Devices credit system

The discontinued United Devices agent used a weighting system that scored different components of each computer system. The system had some major limitations, and was discontinued at the same time as the United Devices agent.

Normalisation based on quorum claims

Classic BOINC algorithm

The standard method used by BOINC projects is to discard the highest and lowest claims and average the rest. This average is then granted to every valid result. World Community Grid used this method until inaccurate benchmarks introduced an unacceptable bias.


To compensate for inaccurate benchmarks (both accidental and deliberately inflated) World Community Grid developed a method for discarding only statistical outliers. Claims that were slightly anomalous were simply excluded from the average, and extreme outliers were not only excluded, the result was granted half credit in an attempt to discourage the use of clients with grossly inflated benchmarks.

This method is no longer used.

Normalisation based on past performance

This method was developed to allow quorums to be reduced to 2. With only two claims to consider, there is insufficient information to choose which claim is most accurate, and simply averaging the two claims leads to a sizeable distortion in granted credit if a computer consistently over claims or under claims.

The way that credit is awarded in a quorum of two is that the two claimed credits are compared and if they are within 30% of each other, then they are averaged and the average value is granted. Over 85% of workunits have the granted credit determined this way.

If the two claimed credit values are further then 30% apart, then the code looks at a field in the database which stores the recent average credit granted per second for each computer. Whichever computer's claimed credit per second for the workunit is closer to their recent average credit granted per second has its claimed credit used as the credit granted for the workunit.

What we found was that there were a few computers that were extremely consistent about claiming very low so they always caused the workunit to check the recent average history. Because they were consistently claiming low and it was matching their average granted credit they were being selected as the credit to use for the granted credit. We determined that these computers were claiming low by looking at the history of computers they were paired with and seeing their history - and indeed those other computers had a much lower grant when paired with one of these computers.

As a result, we are going to change how the 2nd part of the process works. Instead of selecting the credit that is closest to its history, we will average the recent average histories for the two computers. We have been simulating the impact of this for the past couple of days and it turns out that in a strong majority of cases the result cpu time * host recent average credit per cpu second is actually quite consistent between different computers even if their claimed credit are further apart. This is what we had hoped to see and as a result we will start to use this policy in the near future.

Credit for zero redundancy projects

Related topics


To return to the Frequently Asked Questions index choose link below or top left margin!