J) Reputation Score

The network scores users based on their success rate and past performance that is used to coordinate activity on the network. When users submit or process jobs to the network, they will either incur a positive or negative reputational result depending on whether they met the conditions of the smart contract. If artists reject work that is properly rendered, their reputation score is reduced, while if node operators do not successfully process work, they will see a downgrade of their reputation. These combinations of fraud prevention make up something that we refer to as “proof-of-render” - where human job confirmation and algorithmic rendering checks are used to confirm work. Reputation scores help advance proof-of-render.

‌

Reputation scores incentivize good behavior on the network, enabling Artists and Operators to generate more productivity from the network. For Artists, reputation scores are used to determine the amount of concurrent mining nodes a user can access at any given time. Thus, artists with higher reputation scores are able to process work faster, incentivizing them to build a positive success rate that often come from thoroughly checking scenes prior to uploading them to the network. Artist side reputation scores also ensure that requestors without positive histories do not clog up the network with work that needs to be re-rendered, creating disruptions in job allocation. Similarly, Node Operators will only be able to process higher tier work - which provides increased token rewards per compute cycle - by meeting the reputation score requirements. Additionally, node operators with higher reputation scores are assigned work faster than other users with lower reputation scores, incentivizing them to maintain high success rates. Through this process, reputation scores are both used as a coordination and an incentive mechanism.

‌

In allocation, although the possibility of a backup on the render queue is low, the user ranking system will serve as a needed tie-breaker in specific situations - further incentivizing consistent positive activity. For example, if there are 20 GPU’s currently available, and two users have a render job that needs to be completed that will require 20 GPU’s. User A is a new user who just joined the network and does not have any history of requesting work; User B is an established user that requests render jobs on the network every day. All other factors being equal in this case, User B would take priority for the render job because they have rank over User A.