Reward Details

To understand rewarding system, let's first understand how reward emission works in the Spheron Protocol.

Reward Emission

Providers are incentivized with liveness rewards based on tiers and multipliers to ensure they remain active within the network. This approach prevents potential exits due to insufficient returns on investment (ROI) or the inability to cover operational expenses (OpEx).

• The liveness rewards are currently issued in a points system until the launch of the $SPHN token. These points are non-transferable.
• The liveness reward is issued every ERA (which is 24 hours) and will be accumulated in the provider's wallet.

Liveness rewards are determined based on several factors:

Resource Rewards

Providers earn rewards based on the GPU and compute resources they provide to the network. The higher the quality of the resource, the better the reward multiplier. Different resource categories will be introduced, each with different base rewards and multipliers based on tiering (e.g., CPU tiering, Storage tiering, and Connectivity tiering). Currently, only GPU tiering with 10 tiers has been introduced.

How are resource rewards calculated?

Let's say you have x units of GPU A, which falls in Medium Tier 1 with a multiplier of 1x, and y units of GPU B, which falls in High Tier 2 with a multiplier of 6x. The base reward for GPU Tier is k. The resource reward calculation will be:

(x * 1 + y * 6) * k

Trust Reward Booster

Providers must maintain a specific uptime based on their current tier requirement to receive ERA liveness rewards. Failure to maintain the required uptime within an ERA will results in a 100% slashing of rewards for that ERA.

Uptime in the Spheron network is calculated based on challenges performed by the Slark node (currently maintained by Spheron). At a random time, the Slark node will challenge the provider to perform a Proof of Compute challenge. If the challenge is successful, it will be recorded, and after 24 hours, all challenges are evaluated. If the uptime is below than required, a slashing transaction will be made on-chain to slash the provider's reward.

However, if the provider performs well for three consecutive Eras, they will be promoted to the next higher Tier, resulting in a higher booster on their liveness rewards. Conversely, if the provider underperforms for five consecutive Eras, they will be demoted to a lower Tier and receive a lower booster on their liveness rewards.

Each Tier has an associated booster. The higher the Tier, the greater the booster on the rewards. For more information about the Tier Boosters, refer to the Trust & Performance Tier section.

Trust & Performance Tier

Provider Nodes are categorized into 7 tiers, with each tier representing a higher level of service quality and reliability. The Trust and Performance Tiers classify providers based on their reliability, performance, and trustworthiness. Higher tiers indicate greater trust and performance, leading to higher prioritization and rewards.

The table below categorizes providers into different tiers based on their performance metrics. Each tier represents a level of trust and performance, with higher tiers earning greater rewards.

Understanding Uptime

Uptime is a critical metric used to evaluate a provider's performance. It measures the percentage of time a provider is operational and able to handle tasks within an ERA (24 hours). The uptime requirement varies by tier:

• Tier 1 (Most Trusted Providers): Requires more than 99% uptime.
• Tier 2 (Highly Trusted Providers): Requires more than 98% uptime.
• Tier 3 (Trusted Providers): Requires more than 97% uptime.
• Tier 4 (Somewhat Trusted Providers): Requires more than 95% uptime.
• Tier 5 (Less Trusted Providers): Requires more than 90% uptime.
• Tier 6 (Untrusted Providers): Requires more than 85% uptime.
• Tier 7 (Most Untrusted Providers): Requires more than 75% uptime.

Purpose of Uptime: Uptime is used to determine if a provider is performing well. Providers that meet or exceed the uptime requirements for their tier can be promoted to a higher tier, resulting in increased rewards. Conversely, failing to meet the uptime requirements can lead to demotion to a lower tier.

Slashing Requirement

The Slashing Requirement is the minimum performance threshold that providers must meet to avoid having their rewards slashed. If a provider's performance falls below this threshold, they will not receive any rewards for that ERA.

• Tier 1: Rewards are slashed if uptime falls below 85%.
• Tier 2: Rewards are slashed if uptime falls below 80%.
• Tier 3: Rewards are slashed if uptime falls below 75%.
• Tier 4: Rewards are slashed if uptime falls below 70%.
• Tier 5: Rewards are slashed if uptime falls below 65%.
• Tier 6: Rewards are slashed if uptime falls below 60%.
• Tier 7: Does not have a slashing requirement because providers in this tier do not receive any rewards.

Tier 7 - Most Untrusted Providers

Providers in Tier 7 are considered the least trusted and do not accrue any rewards. To start earning rewards, they must improve their performance and move up to at least Tier 6 by meeting the required uptime metrics.

How Metrics Are Calculated

The metrics for uptime and slashing are calculated based on challenges performed by the Slark node. This node challenges providers at random times, requiring them to complete a Proof of Compute task. Successful completion of these tasks is recorded, and after 24 hours, the Slark node evaluates the provider's performance.

• Uptime Calculation: The Slark node calculates uptime based on two types of challenges: GPU and CPU. The total uptime is determined by the success rate of both challenge types. For providers with GPUs, the calculation uses a weighted approach:
  • 80% weightage is given to GPU challenge successes
  • 20% weightage is given to CPU challenge successes
  This weighted calculation ensures that GPU performance, which is typically more critical for compute-intensive tasks, has a greater impact on the overall uptime score. For providers without GPUs, the uptime is calculated solely based on CPU challenge successes.
• Slashing Decision: If a provider's uptime falls below the slashing requirement, the Slark node initiates a slashing transaction on-chain, causing the provider to lose their rewards for that Era.
• Promotion and Demotion: The Slark node evaluates provider performance over multiple Eras to determine tier changes. Consistent high performance leads to promotion, while sustained poor performance results in demotion. The "Upgrade Era Requirements" and "Downgrade Era Requirements" columns in the table above indicate the number of consecutive Eras a provider must meet or fail to meet their tier's criteria for promotion or demotion, respectively. This system encourages providers to maintain consistent high-quality service while allowing for occasional fluctuations in performance.

By understanding and meeting these metrics, providers can maximize their rewards and achieve higher tiers within the Spheron network.